AFP Mount Point Permissions (Solved)

The same things happens if I try the mount via automount in fstab. /Network/path has correct permissions before the actual mount, but after that the permissions are rwx------.

Here's some additional troubleshooting information:

The share in question is a standard share (not a user's private share.) It has "User" (as shown above) listed as a write-enabled user. What I noticed is that if I change the "Share folder everyone rights" under "Advanced Options" to "read-only", the mount point - when mounted as "User" - will have a r-x------ permission instead of rwx------. This seems to indicate that the user-side permissions on the Mac are mapped from the "everyone/other/world" permissions on the ReadyNAS. This would also indicate that the permissioning for the mount point is coming from ReadyNAS.

So the question remains, how do I create a share and mount that share over AFP, so that the mount point (root) has rwxr-xr-x permissions?

Well, I found a work-around... In my case, the directory which the web server needed to access was "Pictures." Since the mount point permissions were always "rwx------/700" I needed a way to mount this share as the web server user.

My fix was to create a StartupItem (loaded during boot) that would make this all happen. The StartupItem creates a directory called "Pictures" in /Library/WebServer, chowns it to "_www", and then mounts the share using sudo -u _www, using a ReadyNAS user account that has only read permissions to the share.

It's not the most elegant thing, but it works. I hope this can help someone else. I can't believe nobody has run into this problem before; maybe everyone is running web servers on Linux only (I noticed the permissions for the mount point under Linux - Ubuntu - show up as rwxrwxrwx/777.)

Hi John,

I tried reproducing what you are seeing but have been unable to.

As a quick test I did the following on a file on my Mac:

chmod og + x <file>

Then transfer it to a share from the NAS mounted over AFP the file still retains the same permissions. I understand you came up with a work-around but I am wondering why this happened to you in the first place.

The problem is not with the files inside the share, but the mount-point itself. If you look a the first example, you'll see that the mount-point I'm using is "a" and starts out with 755. Once I mount afp://readynas/Share over it, the permission on "a" becomes 700 and there's no way to change it. The files inside the share (and inside the mount point) continue to have the correct permissions and work as expected. The problem seems to be with the mount point itself. I PM-ed you...

jszatmary wrote:

The problem is not with the files inside the share, but the mount-point itself. If you look a the first example, you'll see that the mount-point I'm using is "a" and starts out with 755. Once I mount afp://readynas/Share over it, the permission on "a" becomes 700 and there's no way to change it. The files inside the share (and inside the mount point) continue to have the correct permissions and work as expected. The problem seems to be with the mount point itself. I PM-ed you...

It is my understanding this is the correct behavior when doing a mount. When a file system is mounted over a directory, the permissions of the root directory of the mounted file system take precedence over the permissions of the mount point.

I tried this with two mac machines and the behavior with Mac machines running 10.5.5 is the same as you describe above.

I agree that this should be the correct behavior... however this is not what happens under Linux (Ubuntu.) Under that environment, when tested a mount of an SMB share to the ReadyNAS, the permissions became 777.

Anyway back to the correct behavior... If this is correct, as it should be according to spec, how can I modify the permission on the ReadyNAS share (the source of the permissions that cover the mount-point) so that they are reflected as 755.

What I noticed is that if i modify the "everyone" permission under Advanced Options, it actually maps to the user bits at the mount-point level. That is, if on the ReadyNAS share settings I change the everyone permissions to "read" (from the default read/write) and then mount the share, the mount-point permissions become 500, instead of 700. This would indicate that there is some mapping of permissions taking place between the ReadyNAS and the host system.

By default the group/everyone perms under Advanced are read/write for both. This is obviously not refelcted on the mount point, and is confusing. Why would the ReadyNAS interface show read/write for all three sets of perms under Advanced, but when mounted, would show only 700?

So the questions remains, can I create/configure a share on the ReadyNAS that will mount as 755 via AFP?

jszatmary wrote:

I agree that this should be the correct behavior... however this is not what happens under Linux (Ubuntu.) Under that environment, when tested a mount of an SMB share to the ReadyNAS, the permissions became 777. Anyway back to the correct behavior... If this is correct, as it should be according to spec, how can I modify the permission on the ReadyNAS share (the source of the permissions that cover the mount-point) so that they are reflected as 755. What I noticed is that if i modify the "everyone" permission under Advanced Options, it actually maps to the user bits at the mount-point level. That is, if on the ReadyNAS share settings I change the everyone permissions to "read" (from the default read/write) and then mount the share, the mount-point permissions become 500, instead of 700. This would indicate that there is some mapping of permissions taking place between the ReadyNAS and the host system. By default the group/everyone perms under Advanced are read/write for both. This is obviously not refelcted on the mount point, and is confusing. Why would the ReadyNAS interface show read/write for all three sets of perms under Advanced, but when mounted, would show only 700? So the questions remains, can I create/configure a share on the ReadyNAS that will mount as 755 via AFP?

I honestly don't know how you would set this on our NAS or a Mac client. Like you have already seen in Frontview there are two places to change permissions. One in the Advanced tab that modifies folders on the NAS and another on in the AFP section that you have to scroll down to see that allows changing of file permissions. This however does not help with the executable bit you want to set. I will look around and see what I can find out.

It seems to me that there is a permission shift going instead of "mapping" just a user name from the ReadyNAS to the Mac (I am mounting as user "root" and providing the user "John" to the ReadyNAS.) Something like:

              U   G   O       
NAS   John   RWX RWX RWX   (share root owner/permissions)
        |    ?   ?  /
        |         /
        |       /
Mac   root   RWX --- ---   (mount point owner/permissions after mount)
      root   RWX R-X R-X   (mount point owner/permissions before mount)

The user name mapping is obviously a side-effect of a network based file system so it's irrelevent to this problem. But the fact that the permissions shift from "other" on the NAS to "user" on the host seems to be an issue. I don't know whether this is because OS X behaves per spec and Linux does not, but it is curious, and I still wonder if there is a correct fix.

I'm assuming the ReadyNAS is running netatalk... I haven't dove into that yet to see how it could possibly be configured to reproduce this behavior. Perhaps you guys can add this "feature" to the FAQ.

did anyone ever solve this? driving me crazy...

jszatmary wrote:

It seems to me that there is a permission shift going instead of "mapping" just a user name from the ReadyNAS to the Mac (I am mounting as user "root" and providing the user "John" to the ReadyNAS.) Something like: U G O NAS John RWX RWX RWX (share root owner/permissions) | ? ? / | / | / Mac root RWX --- --- (mount point owner/permissions after mount) root RWX R-X R-X (mount point owner/permissions before mount) The user name mapping is obviously a side-effect of a network based file system so it's irrelevent to this problem. But the fact that the permissions shift from "other" on the NAS to "user" on the host seems to be an issue. I don't know whether this is because OS X behaves per spec and Linux does not, but it is curious, and I still wonder if there is a correct fix. I'm assuming the ReadyNAS is running netatalk... I haven't dove into that yet to see how it could possibly be configured to reproduce this behavior. Perhaps you guys can add this "feature" to the FAQ.