AFP Permission issues after new FW update

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.