Permission denied: access [...] failed because search permissions missing

Question

Level 2

166 points

Permission denied: access [...] failed because search permissions missing

Has anyone ever run across this?

I've got an Xsan setup with 2 Xserves and 2 G5 clients.

The home directories are served out of AFP from the Open Directory master server:

/Network/Servers/ssv1.my.do.main/Users/me/Sites/

in other words.

A user complained that after I moved his home directory to this same tree (he'd created a local home directory on one of the G5's, unbeknownst to me) that his Personal Web Sharing stopped working.

Sure enough, it had.

So, technically, I'm running the Web server on a regular G5 client and not on Mac OS X Server; but at the same time, I think the problem is due to the network home directory.

The error I get is

[Tue Jul 25 16:21:40 2006] [error] [client N.N.N.N] (13)Permission denied: access to /~me failed because search permissions are missing on a component of the path

Answer's obvious, right? Make sure to chmod go+x to all path elements on down from "/" to the ~/Sites folder, right?

Been there, done that - no effect.

Even tried changing ~/Sites to be group-owned by the "www" group.

If I slap a ktrace(1) onto the Apache server, I get

13402 httpd CALL stat(0x1868c10,0x1866f00)
13402 httpd NAMI "/Network/Servers/ssv1.my.do.main/Users/me/Sites"
13402 httpd RET stat -1 errno 13 Permission denied
13402 httpd CALL ppc_gettimeofday(0xbfffb5a8,0)
13402 httpd RET ppc_gettimeofday 1153867740/0x44c69fdc
13402 httpd CALL write(0xf,0x183d200,0xac)
13402 httpd GIO fd 15 wrote 172 bytes
"[Tue Jul 25 15:49:00 2006] [error] [client N.N.N.N] (13)Permission denied: access to /~me/ failed because search permissions are missing on a component of the path

I should make an important note. There is one remaining "local" user/home directory on the machines in question; accessing their Personal Home Page continues to work just fine. It's only these ones served from the Xserve via AFP that have this permissions issue.

I have absolutely no clue why user "www" would not be able to stat() that directory path. Every element - and I even followed symbolic links - is at least r-xr-x for g+o permissions. Is there a possibility there's some normally-hidden ACL sort of access problem going on here?

(A Google search turned up 1 hit on this problem with remote users. That person was mounting a SAMBA share to get at the Personal Web Sharing directory.)

2 x Xserve G5, 3 x Xserve RAID, 2 x G5 clients, Mac OS X (10.4.7)

Posted on Jul 25, 2006 5:30 PM

Reply

Answer 1

Greg Earle Author

Level 2

166 points

Jul 25, 2006 5:46 PM in response to Greg Earle

Has anyone ever run across this?

I've got an Xsan setup with 2 Xserves and 2 G5
clients.

The home directories are served out of AFP from the
Open Directory master server:

/Network/Servers/ssv1.my.do.main/Users/me/Sites/

in other words.

A user complained that after I moved his home
directory to this same tree (he'd created a local
home directory on one of the G5's, unbeknownst to me)
that his Personal Web Sharing stopped working.

Sure enough, it had.

So, technically, I'm running the Web server on a
regular G5 client and not on Mac OS X Server; but at
the same time, I think the problem is due to the
network home directory.

The error I get is

[Tue Jul 25 16:21:40 2006] [error] [client N.N.N.N]
(13)Permission denied: access to /~me failed because
search permissions are missing on a component of the
path

Answer's obvious, right? Make sure to chmod go+x to
all path elements on down from "/" to the ~/Sites
folder, right?

Been there, done that - no effect.

Even tried changing ~/Sites to be group-owned by the
"www" group.

If I slap a ktrace(1) onto the Apache server, I get

13402 httpd CALL stat(0x1868c10,0x1866f00)
13402 httpd NAMI
"/Network/Servers/ssv1.my.do.main/Users/me/Sites"
13402 httpd RET stat -1 errno 13 Permission
denied
13402 httpd CALL ppc_gettimeofday(0xbfffb5a8,0)
13402 httpd RET ppc_gettimeofday
1153867740/0x44c69fdc
13402 httpd CALL write(0xf,0x183d200,0xac)
13402 httpd GIO fd 15 wrote 172 bytes
"[Tue Jul 25 15:49:00 2006] [error] [client
N.N.N.N] (13)Permission denied: access to /~me/
failed because search permissions are missing on a
component of the path

I should make an important note. There is one
remaining "local" user/home directory on the machines
in question; accessing their Personal Home Page
continues to work just fine. It's only these ones
served from the Xserve via AFP that have this
permissions issue.

I have absolutely no clue why user "www" would not be
able to stat() that directory path. Every element -
and I even followed symbolic links - is at least
r-xr-x for g+o permissions. Is there a possibility
there's some normally-hidden ACL sort of access
problem going on here?

Update: If I run the Mac OS X Server Apache server on the host where the networked home directories are actually physically located ("ssv1" in my example), it works. It does not work on the G5 client, as stated; it also does not work on the other Xserve G5 running Mac OS X Server as well (it's the Xsan metadata/journaling controller) which further indicates that it's an issue with the networked home directories (since that's not a factor when accessed from the physical home directories server).

Reply

Answer 2

Greg Earle Author

Level 2

166 points

Jul 25, 2006 8:45 PM in response to Greg Earle

"Solved" it myself, through a bit of sleuthing:

When you log in on a machine with automounted AFP mounts and networked home directories, the "mount" is essentially done as you ... so your own user id can see anything under the mount point (that's publically visible), but other users can't.

Since Apache runs as user "www", it can't see those users' "Sites" folders, 'cos it can't see into any of the users' home folders in the remotely-mounted "/Users" directory ... thus you get the Permission Denied error.

I'm not sure how your setup is done, but if you do a "mount" command on the Web server host, it should show you who mounted it - "mounted by NiBo", perhaps.

If you go into httpd.conf and change things such that the Web server is run as the same user who mounted the AFP share, and then restart the Apache server, then everything should work with the AFP WebRoot because then, the uid of the running Apache server will then match the uid of the owner of the AFP mount.

Of course, running the Apache server in this way isn't very practical 🙂

AFP automounts - which is what we're using for networked home directories here where I work - are weird. I guess having someone be the "owner" of a mount is kinda cool, security-wise; but having that act as a "funnel" through which things get security checked kinda *****.

In other words, I don't care if it was user "luser" logged in and caused the automount of the AFP volume from the networked home directory server - if I'm the owner of a file that's now accessible via that mount because it's been mounted, I should be able to access it, and not be rebuffed with a "Permission Denied" error. To me, that goes against
The Principle Of Least Surprise.

Apple didn't think this out terribly well. This AFP automounting stuff with the built-in security of "ownership" of the mount may seem nifty, but it brings about a lot of problems in a networked, multi-user environment.

Reply