AFP Permission issues after new FW update

planetaaron wrote:
I believe the uid is set by the client (aka your computer, not the readyNAS)

Unfortunately that is not correct - AFP access is more like CIFS than NFS in this regard

To enable AFP access you must create an account on the NAS. When you then connect via AFP as that created user, all files/folders assume the UID and GID of the NAS account, not the client

WIth NFS the access to the "share" is controlled by the NFS settings on the ReadyNAS but permissions on the objects them selvs is based on the standard User, Group and other permissions and the ownership of the object. If you have the NFS setting on the ReadyNAS to override the UID/GID of the client as well as the ACLs then you can get it to work just fine. But if you allow the uid/gid f the client and their umask determine the permissions then you can have issues.

WIth NetATalk to be allowed to access to a share you have to authenticate and be authorized for access. When you authenticate you do so via a user name. On the ReadyNAS/netatalk side of things the authenticated user name is mapped to a UID and this UID is used to determine access to objects on the ReadyNAS file system. From the OS X side all of the files on the AFP sure are seen as being owned by the UID of the local user. For some reason if the UID on both OS X and the ReadyNAS there is an bug in the code that causes access to fail.

So in my case where I allow the client to set the UID and permissions via NFS and also us AFP it can cause an issue since I have a number of OS X, Linux/Unix and Windows systems having to change the UID/GID of a user across all of the non Windows boxes to make things work is a hassle.

sphardy wrote:
planetaaron wrote: I believe the uid is set by the client (aka your computer, not the readyNAS) Unfortunately that is not correct - AFP access is more like CIFS than NFS in this regard To enable AFP access you must create an account on the NAS. When you then connect via AFP as that created user, all files/folders assume the UID and GID of the NAS account, not the client

Ok, I'll take your word for it. :)

I have to say this whole experience has been a bit of a disappointment. In addition to the issues already outlined, I had a ton of problems copying files from/back to the ReadyNAS when I was backing up my 1TB iTunes library. The whole point of using AFP was to ensure that I didn't have filesystem incompatibilities between my local and remote drives, however when trying to copy in both directions, it was not a simple drag & drop. I was getting all kinds of errors like "File has illegal characters", "File name too long", and "A file/directory with that name already exists" (this one due to being able to create case sensitive directories & files on the readyNAS that were not allowed locally).

It's possible that the AFP spec has changed and this is more of a protocol issue than a ReadyNAS problem, but the end result was a frustrating user experience. I ended up having to just do an rsync and then reconcile the colliding file names manually. I haven't even tried yet to start up my iTunes library now that I've copied it back to the readyNAS. I have a sneaking suspicion it won't be seamless.

I don't know if this points at a hint, but I am having the exact same problem from a Snow Leopard and Lion client after upgrading to my Ultra 6 to .18. I think the upgrade botched some permissions permissions file because one of my shares had the group permission set to something like perm = "users

I tried to delete the group permission and add my user back, the ReadyNAS responded with removed uknown group perm = "users but that did not resolve the problem.

My netatalk.log is filled with getnamefromuuid failures.

I see 4.2.18 has been pulled now. I did not do thorough testing on the permissions issue when I upgraded my first Mac to Lion and upgraded my ReadyNAS to 4.2.18. All I did was acess my existing shares. I should have known better. I always wait for a few months before upgrading my ReadyNAS to a new code release. This time around, the temptation to upgrade all of my Macs to Lion was too much to bear, so I went ahead and upgraded all of them. My bad.

I have a question about the issue of Guest access to shares being enabled after the upgrade to 4.2.18, which is the reason why it has been pulled. I see that the "Allow guest acess" checkbox is ticked on every one of my AFP shares. It's also grayed out, so I cannot untick it. It's not a major concern to me, but I can see why this is a major security hole. So, how do I untick the "Allow guest acess" checkbox?

Additionally, I have these two questions:
1. What is "guest acess" in the first place? How is it provided by AFP? What is the mechanism behind it? How is Guest different from "everyone"?
2. What is the mechanism that "grants rename and delete privileges to non-owner of files"? How is it done using the read/write/execute permissions on the local (to ReadyNAS) file system?

I have had these questions for years now. Unfortunately, the ReadyNAS manual does not get into detail on file access permissions, and all of my appeals to the ReadyNAS team over the years to create a separate document on permissions resulted in nothing.

Thanks!

Can't answer your question re. the guest access option being greyed out, but your 2 specific questions I can:

sirozha wrote:
1. What is "guest acess" in the first place? How is it provided by AFP? What is the mechanism behind it? How is Guest different from "everyone"?

You connect to your share as the actual user "guest" which doesn't require a password. The AFP service manages this by internally 1) not requesting a password and 2) translating the OSX guest user as the linux user "nobody" who is a member of the group "nogroup". This means that the underlying linux permissions of the share must either allow "everyone" write access to the share, or the share must be assigned to the group "nogroup" (which is the default) and group permissions be set to read/write. Else the guest user will have read-only access (or possibly no access)

2. What is the mechanism that "grants rename and delete privileges to non-owner of files"? How is it done using the read/write/execute permissions on the local (to ReadyNAS) file system?

This refers to the "sticky bit" when it comes to permissions. See: http://en.wikipedia.org/wiki/Sticky_bit

Note that the ReadyNAS dialog can seem a little counter intuitive in that you must *disable* the "grants rename and delete privileges to non-owner of files" checkbox to *enable* the sticky bit.

Unfortunately, the ReadyNAS manual does not get into detail on file access permissions, and all of my appeals to the ReadyNAS team over the years to create a separate document on permissions resulted in nothing

Documentation is not exactly a strength of the ReadyNAS Team. You're not the only one to have "mentioned" this

Change the default access permissions for AFP for the share, apply. Uncheck the box to allow guest access, apply. Revert default access permissions for the share (e.g. to disabled) and click Apply.

I did this earlier today and it worked for me.

Try installing 4.2.18, (which is now 4.2.19 because its been pulled due to the fact that any AFP-enabled share will inadvertently obtain guest access), from readynas.com the "news and events" page. It's not the support page which is where you think you would find it, but no. Installed 4.2.18 and it seems to be working much better, no thanks to their support line.
-- J

sirozha wrote:
1. What is "guest acess" in the first place? How is it provided by AFP? What is the mechanism behind it? How is Guest different from "everyone"?

sphardy wrote:

You connect to your share as the actual user "guest" which doesn't require a password. The AFP service manages this by internally 1) not requesting a password and 2) translating the OSX guest user as the linux user "nobody" who is a member of the group "nogroup". This means that the underlying linux permissions of the share must either allow "everyone" write access to the share, or the share must be assigned to the group "nogroup" (which is the default) and group permissions be set to read/write. Else the guest user will have read-only access (or possibly no access)

So, is this a standard mechanism of providing guest access in various Linux flavors or is this something that the RedyNAS team implemented?

2. What is the mechanism that "grants rename and delete privileges to non-owner of files"? How is it done using the read/write/execute permissions on the local (to ReadyNAS) file system?

sphardy wrote:
This refers to the "sticky bit" when it comes to permissions. See: http://en.wikipedia.org/wiki/Sticky_bit Note that the ReadyNAS dialog can seem a little counter intuitive in that you must *disable* the "grants rename and delete privileges to non-owner of files" checkbox to *enable* the sticky bit.

According to that Wikipedia article, the stick bit - when set on a directory in Linuxv- restricts the renaming and unlinking of the files in that directory unless this is done by the root or owner. Is "unlinking" the same thing as "deleting"? In Mac OS X, there is a requirement that the owner of the file must has the write permission to the file in order to be able to delete it when the sticky bit is set on the enclosing directory. Is there such a requirement in Linux as well?

chazen wrote:
Try installing 4.2.18, (which is now 4.2.19 because its been pulled due to the fact that any AFP-enabled share will inadvertently obtain guest access), from readynas.com the "news and events" page. It's not the support page which is where you think you would find it, but no. Installed 4.2.18 and it seems to be working much better, no thanks to their support line. -- J

Can you post the link to that page? I opened it, but I cannot see where it mentions that there is a new 4.2.18 or 4.2.19. All it says that 4.2.18 has been pulled. Can the Jedi comment on this? Have you released the 4.2.19 beta yet where the guest access problem has been mitigated?