[zomart9th]

I have been getting used to Spotlight and I love it. So fast to get access to programs and files, it's barely worth organizing stuff anymore.

The problem is, I store all my iTunes music and personal files on mounted SMB shares from a Linux server. Spotlight doesn't index these networked volumes.

I have the volumes set to statically mount in /Network/volumename . So, the first thing I tried was:

mdutil -i on /Network/volumename

But unfortunately it refuses as such:

/Network/volumename/:
Could not set indexing status for volume.

It seems like since network volumes are actually symlinked from the filesystem at:

/private/var/automount/Network/volumename

you might be able to force it to index by somehow removing whatever filters this path from the indexing of the main volume. However, I have been unable to find the file that limits the paths that Spotlight searches. On the page on Apple's sight, it says that it's possile to do Spotlight searches of NFS home directories, so there must be some sort of facility for this. Has anyone had any luck indexing network drives? If I have to switch from SMB to NFS to get it to work it's no big deal since the server is Linux.

Thanks!

[CaptainHaddock]

Even if you could get Spotlight to index network volumes, I doubt it would work out well.

Spotlight is updated on-the-fly whenever a file IO command is sent to the OS X kernel. Network volumes not controlled by your own machine will quickly get out of sync with Spotlight. Maybe in 10.5, Apple will add robust client-server Spotlight networking.

[zomart9th]

I agree with the problems you described. But somehow they are allowing indexing of NFS home directories, so they must have some sort of support for filesystems that aren't owned by the computer. Periodic reindexing, something. Largely these filesystems don't change anyway, so if there were some way I could force it to index once just to get it in there I wouldn't mind manually updating it later.

[mitchell_pgh]

Originally Posted by zomart9th

I agree with the problems you described. But somehow they are allowing indexing of NFS home directories, so they must have some sort of support for filesystems that aren't owned by the computer. Periodic reindexing, something. Largely these filesystems don't change anyway, so if there were some way I could force it to index once just to get it in there I wouldn't mind manually updating it later.

I don't know... the thought of my Mac trying to keep up with our Windows network drive... there are constant changes. It would have to be constantly indexing... I think it can only index local drives.

[CaptainHaddock]

Yeah, now that I think about it, it would be sweet if 10.5 introduced a Rendezvous (ahem, I mean Bonjour)-enabled Spotlight server that would run on a network file server (presumably running OS X), and which could be included in your local search results.

[C.J. Moof]

Yes, that's my biggest dissapointment with spotlight. It would be a GREAT benefit for the ad agency that I work at if we could use spotlight searches and smart folders on the Xserve that stores everything.

Seems to me, all it would take is the ability to ask the Xserve's spotlight index what it has for a search query....

[THE MAC GOD]

What should happen in a mac-centric environment (not sure cross platfrom) is that when you connect to a Mac, YOUR Mac connects to it's (remote) spotlight DB... seamlessly and in the background... It uses both the local and remote instantly and since it's just connect to it, the remote Mac handles all the tracking. Your Mac is just using it.

[GaelDesign]

That's strange that the command line thing you tried didn't work. I also connect to a Linux server for a lot of my personal files, and I got Spotlight to work on it, but it mounts in the usual /Volumes spot so maybe that's why. The annoying thing is that Spotlight doesn't "turn on" its indexing feature for the volumes when it mounts. So I made an Automator workflow (heh heh) that will mount the volume and run a shell command that does that mdutil thing (I had to find a workaround for sudo, which is that you do "echo *yourpassword* | sudo -S mdutil "...etc.). That seems to work, except the Spotlight index seems to be loosing some of its content since it first indexed the volume. Some searches work, others don't. Hmm....

Methinks I may just move all of my active project folders onto my local drive and do a sync with the Linux server with ChronoSync. Best of both worlds?

Jared

[zomart9th]

So, are they SMB shares? did you specify where to mount them using the Netinfo Manager? It never occurred to me that I could mount them elsewhere than volumes...

Originally Posted by GaelDesign

That's strange that the command line thing you tried didn't work. I also connect to a Linux server for a lot of my personal files, and I got Spotlight to work on it, but it mounts in the usual /Volumes spot so maybe that's why. The annoying thing is that Spotlight doesn't "turn on" its indexing feature for the volumes when it mounts. So I made an Automator workflow (heh heh) that will mount the volume and run a shell command that does that mdutil thing (I had to find a workaround for sudo, which is that you do "echo *yourpassword* | sudo -S mdutil "...etc.). That seems to work, except the Spotlight index seems to be loosing some of its content since it first indexed the volume. Some searches work, others don't. Hmm....

Methinks I may just move all of my active project folders onto my local drive and do a sync with the Linux server with ChronoSync. Best of both worlds?

Jared

[zomart9th]

So I've been playing with this a bit more looking for possible solutions. I switched all the file shares from SMB to NFS hoping that Spotlight would be willing to index those, but no dice.

If I mount a volume using the Finder (Go->Connect to Server) then the volume shows up in /Volumes/servername, and although I can set the indexing status using mdutil -i on, even when I follow that up with an mdutil -E /Volumes/servername, it doesn't seem to show the volume contents in the search results. The little spotlight icon does do its glowing thing for a second, then it seems to stop.

I have also checked the root of the volume, and it lacks the magic ".Spotlight-V100" file that seems to be where the index is stored.

Ideally, i'd like to index volumes that are statically mounted on startup using automount (i.e. the ones in /Network), but I guess getting this to work is the first step.

Anyone else wrestling with this?

[piracy]

man mdimport

You're perhaps most interested in mdimport -f

Code:
mdimport(1)               BSD General Commands Manual              mdimport(1)

NAME
     mdimport -- import file hierarchies into the metadata datastore.

SYNOPSIS
     mdimport [-VfXLr] [-d level | category] [-w delay] file | directory

DESCRIPTION
     mdimport can be used to import metadata from files or file system hierar-
     chies.

     The following options are available:

     -V          Print timing information for this run of mdimport.

     -A          Print out the list of all of the attributes and their local-
                 izations in the current language and exit.

     -f          Force mdimport to scan the files, bypassing path filtering
                 rules.

     -X          Print the schema file and exit

     -r          Ask the server to reimport files for UTIs claimed by the
                 listed plugin.  For example, the following would cause all of
                 the chat files on the system to be reimported:

                       mdimport -r /System/Library/Spotlight/Chat.mdimporter

     -p          Print out performance information gathered during the run.

     -L          Print the list of installed importers and exit.

     -d level | category
                 Print debugging information.  Level can be 1-4, available
                 categories are import-terse, import-input, import-output,
                 import-warnings, import-verbose, and plugin-loading.  This
                 flag can be specified multiple times, and is always additive.

     -n          Don't actually set the attributes on the file.  Useful for
                 debugging.

     -w msecs    Wait for the specified interval between scanning files.

SEE ALSO
     mdcheckschema(1), mdfind(1), mdutil(1), mdls(1)

Mac OS X                         Oct 27, 2004                         Mac OS X

[OreoCookie]

I think the server is supposed to index the volume, don't know that for sure, though.

[zomart9th]

Originally Posted by piracy

man mdimport

You're perhaps most interested in mdimport -f

I actually have tried mdimport -f, which does cause it to add all the metadata to files, but doesn't seem to add them to whatever index spotlight is using. I have tried running mdimport -f on individual files on network volumes just to see if I could get it to add something to the index, but it hasn't seemed to work. Have you had luck with mdimport -f?

I've tried the following now:

Mount using Go->Connect to server (volume is now mounted in /Volumes/servername
at terminal:

Code:
mdutil -s /Volumes/servername
server/:
        Status: Indexing Disabled

mdutil -i on server/
server/:
        Indexing enabled for volume.

mdutil -E server/
server/:
        Volume index removed.  Index will be rebuilt automatically.

(At this point, spotlight spends about 2-3 minutes telling me it's indexing "servername")

Now, I attempt a search using Spotlight for any file in the volume 'servername' and it falis. So then I try:

Code:
mdimport -fVp /Volumes/servername

It crunches for a while, ultimately showing that it indexed all the files. Again I attempt a search using Spotlight, no luck finding anything.

To test whether the metadata was actually added to the file, I pick a file in the network volume and use mdls:

Code:
mdls North\ by\ North\ Quahog.avi 
North by North Quahog.avi -------------
kMDItemAttributeChangeDate     = 2005-05-02 10:42:40 -0700
kMDItemContentCreationDate     = 1903-12-31 16:00:00 -0800
kMDItemContentModificationDate = 2005-04-30 19:07:24 -0700
kMDItemContentType             = "public.avi"
kMDItemContentTypeTree         = (
    "public.avi", 
    "public.movie", 
    "public.audiovisual-content", 
    "public.data", 
    "public.item", 
    "public.content"
)
kMDItemDisplayName             = "North by North Quahog.avi"
kMDItemFSContentChangeDate     = 2005-04-30 19:07:24 -0700
kMDItemFSCreationDate          = 2005-04-30 19:07:24 -0700
kMDItemFSCreatorCode           = 0
kMDItemFSFinderFlags           = 0
kMDItemFSInvisible             = 0
kMDItemFSLabel                 = 0
kMDItemFSName                  = "North by North Quahog.avi"
kMDItemFSNodeCount             = 0
kMDItemFSOwnerGroupID          = 1000
kMDItemFSOwnerUserID           = 501
kMDItemFSSize                  = 286944256
kMDItemFSTypeCode              = 0
kMDItemID                      = 301
kMDItemKind                    = "AVI Movie"
kMDItemLastUsedDate            = 2005-04-30 19:07:24 -0700
kMDItemUsedDates               = (2005-04-30 19:07:24 -0700)

So it seems that the metadata was added to the files at least. Finally, I tried a command-line search using;

Code:
mdfind Quahog

And still nothing.

Maybe it's the fact that they are network volumes, or maybe I'm just not using these md* utilities correctly. I'd love to read some more extensive documentation on the subject than the man pages provide... it's got to be out there somewhere!

Thanks for the ideas.

[zomart9th]

I've been searching and working on this, but I still haven't found any way to make spotlight index anything on a network drive. Anyone else having any luck?

[TimmyDee51]

I think this is all because Spotlight probably uses the HFSX system to do its metadata indexing. On non HFSX disks, each file "foo" gets a "._foo" associated with it to store the extended attributes. Spotlight may not index these files at the current time. Also, it may not create these files on a network server until a more suitable solution is found (imagine how pissed a sysadmin would be upon finding ._foo files for everything on the networked drive).

This is my speculation. However, I am basing it on the info in Jon Siracusa's review over at Ars. It's chalk full of good info.