Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Mojave and File Servers

189 views
Skip to first unread message

David B.

unread,
Jan 18, 2019, 9:11:17 AM1/18/19
to
On 18/01/2019 14:00, Ed Norton wrote:
> On Thu, 17 Jan 2019 16:56:49 -0500, Jolly Roger wrote
> (in article <gacc11...@mid.individual.net>):
>
>> On 2019-01-16, Ed Norton <nor...@nowhere.com> wrote:
>>> On Wed, 16 Jan 2019 14:45:48 -0500, Jolly Roger wrote
>>> (in article <ga9fvc...@mid.individual.net>):
>>>> On 2019-01-16, Ed Norton <nor...@nowhere.com> wrote:
>>>>
>>>>> but it doesn't work for High Sierra since there is no longer a
>>>>>
>>>>> /private/var/db/Spotlight-V100/Volumes/ folder. It has been changed to
>>>>> some name which concatenates the names of all remote volumes.
>>>>
>>>> I don't see any concatenated name of all volumes here:
>>>>
>>>> # mdutil -s /Volumes/Files
>>>> /Volumes/Files:
>>>> Indexing enabled.
>>>>
>>>> # pwd
>>>> /Volumes/Files/.Spotlight-V100
>>>>
>>>> # ls -al
>>>> total 128
>>>> drwx------ 5 root admin 170 May 18 2018 .
>>>> drwxr-xr-x+ 21 root staff 782 Jan 10 07:16 ..
>>>> drwx------ 3 root admin 102 May 18 2018 Store-V1
>>>> drwx------ 3 root admin 102 May 18 2018 Store-V2
>>>> -rw------- 1 root admin 4115 May 18 2018 VolumeConfiguration.plist
>>>
>>> That's from Mojave, right?
>>
>> Actually, that's looking at the source file system on my Mac mini server
>> running High Sierra. This volume is being shared to other computers on
>> the network.
>>
>>>>> Perhaps if the remote server is also running High Sierra that makes a
>>>>> difference. In my case the server is an old Mac Mini running Snow
>>>>> Leopard. All the files are visible, they are just not able to be
>>>>> searched.
>>>>
>>>> I have a machine running Snow Leopard, and Spotlight works fine on its
>>>> shared volumes from a Mac Pro running Mojave and a MacBook Pro running
>>>> High Sierra..
>>>>
>>>> Has it occurred to you that the problem may be with the machine running
>>>> Snow Leopard?
>>>
>>> Very curious. I have tried with several different Macs running Snow
>>> Leopard and get the same result. I also formatted a USB Drive on the
>>> High Sierra machine and then moved it to a Snow Leopard machine. Same
>>> result.
>>
>> Very interesting. I have two machines running Snow Leopard here at the
>> moment. I'm able to do Finder Spotlight searches on their mounted
>> volumes from my Mac Pro running 10.14 and my MacBook Pro running 10.13.
>>
>>> I have tried mdutil to force indexing on a test drive (Untitled) but
>>> get the error message:
>>>
>>> $ mdutil -s /Volumes/Untitled
>>> /Volumes/Untitled:
>>> Server search enabled.
>>>
>>> $ mdutil -i on /Volumes/Untitled
>>> /Volumes/Untitled:
>>> Error: unable to perform operation. (-403)
>>> Server search enabled.
>>>
>>> The High Sierra is a clean install on a MacBook Pro Early 2011.
>>
>> Do you have any other machines you can mount the shared volume on to see
>> if Spotlight searches work there?
>>
>>
>
> Well, I have made _some_ progress. First of all I went back and
> noticed you listed /Volumes/Files/.Spotlight-V100. That is the
> directory for the local volumes. The directory for remote volumes is
> /private/var/db/Spotlight-VT100/Volumes. That's the directory I found
> the concatenated volume names in. I'd be interested to see what you
> find there.
>
> I have another machine with Sierra (as opposed to High Sierra) running
> and it does manage to do a "Finder Search" of the remote volume.
> That's apparently what mdutil means when it reports "Search Enabled"
> (as opposed to "indexing enabled") for a volume. Both Sierra and High
> Sierra report Search Enabled for the remote volume but only Sierra
> performs the search.
>
> On both machines mdutil -i on <volume name> refuses to turn indexing on
> reporting an error and consoling me with a "Search enabled" message.It
> also suggests I can turn indexing on if I run as root (I am using
> sudo). It has been suggested in some of the research I have done that
> Apple doesn't want you indexing remote volumes because it would take
> too long and clog up the network. Sounds about right. But apparently
> a Finder search is less efficient than a Spotlight index. There is a
> way to force Spotlight to load a Spotlight index found on the remote
> volume and use that but I haven't tried it.
>
> I removed the concatenated volume directory on HS but I still can't
> Finder search any remote volume in High Sierra. Since it is a clean
> install I don't see much of a point in installing it again but I guess
> I'll try that as a last resort. A pain in the ass since the computer
> won't boot off a USB disk. Something about the EFI. I remember I had
> trouble setting it up initially.
>
> I always assumed the "Finder Search" used the same database as
> Spotlight but I guess not. Seems like it would take a long time to
> crawl all the directories.

Hi Ed

I'm no 'techie' but have found from personal experience that there's a
very good facility available from the App store called 'Easy Find'.

It's not difficult to use - quite fun in fact! :-)

Perhaps you'll install it and report if you find it helpful (pun
intended! ;-) )

--
David B.

b...@ripco.com

unread,
Jan 19, 2019, 8:19:28 AM1/19/19
to
Ed Norton <nor...@nowhere.com> wrote:

> I use the same user name and password on all my machines and I am the
> only user.

Yeah but that never meant dick on unix machines, the user id and group is
the basis for file permissions.

Just to double check, on each machine, open a terminal window and type the
letters id.

This is on El Capitan but should be similar...

newmini:~ bje$ id uid=501(bje) gid=20(staff),
groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),
81(_appserveradm),98(_lpadmin),33(_appstore),100(_lpoperator),204(_developer),
395(com.apple.access_ftp),398(com.apple.access_screensharing),
399(com.apple.access_ssh)

The first two are the important ones (uid and gid). Off hand I don't
remember apple ever using anything else besides uid=501 for the primary user
account, but worth checking.

My question is how is the remote volume (or drive) being mounted?

For some reason I remember there is a difference between opening a finder
window, under "Shared" on the left side of the panel and mounting there
and using the menu bar and Finder -> Go -> Connect to server.

If the remote is password protected, I beleive you need to use the finder
window to "Connect As...". You used to be able to use the "Connect to
server" from the menu bar via something like:

afp://username:pass...@192.168.1.100/VolumeName

but they broke something (I think) using afp. It still works fine using smb
or nfs though. Using the finder window, I beleive it only supports mounts
from afp.

But why I'm asking is after looking at the back-and-forth with this thread,
I don't see anything about if the remote drive is being mounted on the
client where you can see it on the desktop, if it can be opened and if the
files are visible in it?

Also if you still have that terminal window open, try this:

mdutil -as

that should show all the mounted volumes and their status for indexing.

Beleive it or not, a remote volume doesn't need to be enabled. Searching for
a filename is just slower but it will eventually find it. Enabling it makes
it's quicker (file name search) but I have no idea how Spotlight handles it
because I really don't use it. It doesn't seem like Spotlight looks at
remote volumes and there doesn't seem to be a way to force it.

But like I said, I'm more interested in if the remote volume is actually
mounting, is visible on the desktop, can be opened and rummaged around.

One test I do from the terminal window (again) when having permissions
problems is cd into the volume/directory of the remote from the client and
do a "touch zzz" and see if a file is created. Then try to "rm zzz".

Apple does weird things with that 501 uid and it's possible it's not being
mounted correctly (depending on how it's mounted).

-bruce
b...@ripco.com

David B.

unread,
Jan 19, 2019, 8:49:28 AM1/19/19
to
On 19/01/2019 13:19, b...@ripco.com wrote:
> Ed Norton <nor...@nowhere.com> wrote:
>
>> I use the same user name and password on all my machines and I am the
>> only user.
>
> Yeah but that never meant dick on unix machines, the user id and group is
> the basis for file permissions.
>
> Just to double check, on each machine, open a terminal window and type the
> letters id.
>
> This is on El Capitan but should be similar...
>
> newmini:~ bje$ id uid=501(bje) gid=20(staff),
> groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),
> 81(_appserveradm),98(_lpadmin),33(_appstore),100(_lpoperator),204(_developer),
> 395(com.apple.access_ftp),398(com.apple.access_screensharing),
> 399(com.apple.access_ssh)
>
> The first two are the important ones (uid and gid). Off hand I don't
> remember apple ever using anything else besides uid=501 for the primary user
> account, but worth checking.
[....]


Interesting! Thanks.

I see this:-

uid=501(davidb) gid=20(staff)
groups=20(staff),701(com.apple.sharepoint.group.1),12(everyone),61(localaccounts),
79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),
398(com.apple.access_screensharing),33(_appstore),100(_lpoperator),204(_developer),
250(_analyticsusers),395(com.apple.access_ftp),399(com.apple.access_ssh),
702(com.apple.sharepoint.group.2)

A little different to you, Bruce. Do I need to take any action?
--
David B.

b...@ripco.com

unread,
Jan 20, 2019, 7:47:53 AM1/20/19
to
Ed Norton <nor...@nowhere.com> wrote:

> I don't follow you. What is the difference between a correct and an
> incorrect mount?

At some point in time (remember this was all pre sierra/high sierra) I
mounted a drive from another machine (the usual way I did it) and on the
client, the Finder worked fine (opening the drive, seeing files, copy or
delete, adding files to it) but in terminal, the file permissions were all
screwed up. They were shown with a uid of 1000 or 1001, some directories
were 700 permissions which I couldn't cd into from terminal, but like I
said, on finder, everything worked as it was supposed to.

What was more odd, if you jumped on terminal from the machine exporting the
drive (or file system), everything looked normal there. This could of been
when apple was screwing around with that SMBX, not sure.

I just came up with a theory the finder does some auto-magic behind the
scene stuff with that uid 501 that isn't in terminal.

Not even sure what I did to fix it, I mostly use nfs for file sharing now
because it always seem to behave itself no matter what apple does with their
afp/smb/smbx/cifs crap. And nfs seems faster than any of them.

Anyway, I don't have any suggestions with your problem at this point, I
stuck with El Capitan because it's doing everything I need it to do and
until "no longer supported" starts popping up, I'm staying here.

All I can tell you is that the Finder search should work, currently I have 8
volumes mounted from a linux server (which knows nothing about Spotlight) on
my desktop and searching for a filename is a few seconds at most.

What I'm getting confused about is the relationship between Finder search
and Spotlight. I mean if you look at the man page for mdutil, right at the
top is this:

mdutil -- manage the metadata stores used by Spotlight

If I disable indexing for a remote volume you can still use finder to search
for a filename on it, but is painfully slow. Similar performance to that
Easy Find application mentioned on here (if it works at all).

I do have one thing that'll probably be a time waster, I always had a
question mark next to the -p option with mdutil...

-p Spotlight caches indexes of some network devices locally. This
option requests that a local caches be flushed to the appropriate
network device.

All I every saw with that is "Error: datastore publishing not implemented.".

Other than that, good luck.

-bruce
b...@ripco.com

0 new messages