Home › Forums › OS X Server and Client Discussion › Questions and Answers › Spotlight Server not working in 10.5.2?
- This topic has 3 replies, 4 voices, and was last updated 16 years, 6 months ago by
mm2270.
-
AuthorPosts
-
April 16, 2008 at 6:55 pm #372285
jaduke
ParticipantI’ve been testing Leopard Server (.0, .1, .2) and haven’t been able to get Spotlight server to work with Leopard client.
I have documents with words that should be found on a network search (they are found on local search), but are not.
I’ve toggled it off and on several times on each sharepoint but nothing seems to change.
What voodoo am I missing here to get it working?
I’ve watched the processes spawn to build the index for the sharepoint.
I’ve verified the permissions for all the accounts and have tried logging in as every account on the server, but no dice.
Does anyone have it working?
I’m running server on a Dual 867 w/2G RAM; Data volume is a SoftRAID mirror.
Test clients are iMacs-G4, G5, Intel.
Thanks.
Cheers,
JonApril 16, 2008 at 9:00 pm #372288zeph
ParticipantSame problem, same bunch of testing and certainty that the shared volume is indexed. I did find one hint just now that I probably won’t be able to test for a few days – somebody claims to have gotten it working by removing spaces from his volume name. My volume does have spaces in it, so what the hell, I’ll try it. Would be interested to know if this makes a difference for you – or if anything else does!
Good luck,
zJune 4, 2008 at 4:00 pm #373009bb
ParticipantHas anyone succeeded in getting this running?
October 8, 2008 at 8:39 pm #374404mm2270
ParticipantI have the same problem with my Leopard server and I know almost exactly why this is happening. Sadly I can think of NO way to fix this in my own. The fix MUST come from Apple, as AFP sharing under Leopard server has some serious bugs that they need to address.
The problem has to do with incorrect POSIX permissions being applied to files copied to the shares from client systems, or modified by client systems. Here’s an example:
Say you have a share we’ll call it Share 1. Your ACLs are set the way you want them on this share, and you have basic POSIX permissions set to something like admin for owner and staff for group. The actual permissions for each don’t seem to matter much from what I can tell.
User A copies a folder of files to your share, which is spotlight enabled. If you were to do a Get Info on the folder or files in that folder immediately after it was copied in you’d see that the owner is set to the users login name with Read/Write privs, and group would likely be set to Staff – Read Only. If you keep that Get Info window open you will see something that will make you think you’re losing your mind. The owner and group will both suddenly change to “_unknown” With those POSIX permissions in place the folder or files in that folder will [b]NOT[/b] show up in Spotlight searches from a client machine.
Now, there is a quick temporary fix, and I strongly emphasize “temporary” here, which is to use the Propagate Permissions control in Server Admin’s Sharing tab to propagate down the folder structure, making sure to check the “owner name” box when doing so. Yes, you read correctly. Just propagating the ACLs will NOT work in my experience. You need to fix that _unknown for the owner for it to ever show up in Spotlight. The craziest part of this is that as soon as a client opens any file that was fixed this way and saves changes, it reverts back to _unknown for the owner and that file is no longer searchable with spotlight. Doh!
So in essence, spotlight server works fine as long as no-one touches any files 😯 (!) Nice job Apple! Now how about fixing this ridiculous bug?
I welcome anyone out there to verify my findings by doing what I outlined above and posting results. One thing to note, this does not seem to affect shares coming straight off the server HD, only from shares on an external system, such as a RAID chassis. I haven’t figured out what the difference is there, but I’ve never had the issue with a folder shared out from Server HD. YMMV.
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed