AFP Permission issues after new FW update

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?