AFP Permission issues after new FW update

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