The following example details how to index a share point named "share" for Spotlight searching.
1. Log in to a client computer as a local administrator.
2. Mount share via Connect to Server by a user who has read & write access to the share point.
3. Open Terminal and issue
sudo -s then the following commands as root:
a. Create the index for the share point:
mdutil -i on /Volumes/share
b. Publish that index so that it resides on the share point:
mdutil -p /Volumes/share
4. Unmount share. Then ssh into your server as root and switch to the path for share. Use chmod and chown to set the permissions of the .Spotlight-V100 folder accordingly:
chown -R root:admin /<path to>/share/.Spotlight-V100 chmod -R 755 /<path to>/share/.Spotlight-V100
5. Now remount the share and test a Spotlight search.
Note that this procedure does not work for static network automounts (to /private/var/automount/Network, the Network globe in the Finder) with Mac OS X 10.4 and 10.4.1.
--Gerrit DeWitt
Apple Certified System Administrator
I'm a more than a bit skeptical that indexing on the server can be accessed from 10.4 clients. For good reason the ownership of any .SpotlightV-100 folder should be 700. If its a .SpotlightV-100 folder on a volume it should be owned by root if its a .SpotlightV-100 folder in a homedirectory it should be owned by the user.
If root owns the .SpotlightV-100 at the root of an AFP share there is no way for a client to see the Spotlight files within the folder and consequently the client does not search with the index on the server.
UNLESS there is some sort of network protocol that only spotlight speaks, but if that's the case where does the authentication happen?
The process you've described most definitely enables indexing on an AFP volume from a specific client, but it seems the client does the indexing. i.e. No .SpotlightV-100 directory is created until you do a
sudo mdutil -p /Volumes/ShareName
-p "Publishes the local copies of the metadata stores for the volumes indicated to their real drives."
Please, prove me wrong as my main home directory server is brought to it's knees anytime I allow more than a few spotlight enabled clients to login and/search. If I could offload the indexing to the server, it would be a great help to the AFP network load.
1. The .Spotlight-V100 folders need only be accessible by root, with the exception of the user's home. (Please see my reply to my own post that mentions that root:admin 700 permissions are adequate. Using root:admin 755 won't hurt anything, though.)
2. You must "publish" the index with mdutil -p before the server will maintain its index. Otherwise, each client will keep a local copy of its index locally.
Now, depending on the number of files to be indexed, you may want to schedule your initial share point index publication at a time when nobody else will be using your server. Typically, though, the mds server processes will only consume up to 60% of the CPU load, and I've actually tested this with a blue & white G3 computer acting as a server. Your results with even an Xserve G4 should be better.
As far as I can tell, the client/server Spotlight search interaction works like this:
1. Spotlight does not utilize a separate network protocol or authentication mechanism.
2. When a client performs a search on an indexed and published AFP share point, the Finder passes the search query to the AFP server via AFP. Internally, the server-side AFP server interacts with the server-side mds process to gather a list of results, which are then returned to the client via AFP. Previous versions of AFP supported a similar searching mechanism that simply did not rely on Spotlight.
I can promise you that this indexing procedure does work without generating unnecessary network overload. I've used it with several client setups and continue to maintain it appropriately.
I will mention that if you're experiencing problems with Spotlight searching of AFP volumes like slowdowns, stalls, or AFP disconnections, look at your network topology. I guarantee that you'll find something wrong. I've seen where just having one miswired Ethernet cable on the same network (not on the server or any of its clients) caused random AFP disconnections. It took me two days to track that down, so be ready to do some careful trobuleshooting!