× NETGEAR will be terminating ReadyCLOUD service by July 1st, 2023. For more details click here.
Orbi WiFi 7 RBE973
Reply

Re: AFP Permission issues after new FW update

sphardy1
Apprentice

Re: AFP Permission issues after new FW update

opt2bout wrote:

On our ReadyNAS the NFS security settings and privileges appear to be working just fine. The NFS permissions are based on the host for granting access, and we are able create and edit files/folders. The UID on the NAS have the client's UID/GIDs so they don't match anything on the NAS without a NFS map configured.

Sorry but I don't understand your response or the point you are making
Message 26 of 46
opt2bout
Aspirant

Re: AFP Permission issues after new FW update

Sorry but I don't understand your response or the point you are making

NFS shares are working for us even though the client's UIDs/GIDs aren't the same as the ReadyNAS
Message 27 of 46
sphardy1
Apprentice

Re: AFP Permission issues after new FW update

I would expect so - my point was that not that NFS would not work, but that not fixing the AFP issue prevents Mac users of both AFP & NFS accessing data with the same account
Message 28 of 46
opt2bout
Aspirant

Re: AFP Permission issues after new FW update

sphardy wrote:
I would expect so - my point was that not that NFS would not work, but that not fixing the AFP issue prevents Mac users of both AFP & NFS accessing data with the same account

Yes, and my point is that our Mac clients are able to access both the AFP and NFS shares without any problems.
Message 29 of 46
sphardy1
Apprentice

Re: AFP Permission issues after new FW update

With the same account?

Example: If I created a file on the NAS via NFS with permissions 644 (rw-r--r--), how do I then edit that file via AFP? Without first changing permissions given this bug prevents me from setting up the same account (ie with the same UID) on the NAS as I have on my Mac?
Message 30 of 46
planetaaron
Aspirant

Re: AFP Permission issues after new FW update

I haven't tested it because frankly, I'm tired of screwing with this, but I believe the uid is set by the client (aka your computer, not the readyNAS), so the UID on the readynas doesn't really matter. Of course, this should be verified and if that's not the case then yes, it should be fixed. It should probably be fixed regardless because having to ensure that they're different is counter-intuitive to anyone with a unix background.
Message 31 of 46
sphardy1
Apprentice

Re: 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
Message 32 of 46
CharlesLaCour
Aspirant

Re: 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.
Message 33 of 46
planetaaron
Aspirant

Re: AFP Permission issues after new FW update

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.
Message 34 of 46
blacey
Aspirant

Re: AFP Permission issues after new FW update

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.
Message 35 of 46
sirozha
Aspirant

Re: AFP Permission issues after new FW update

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!
Message 36 of 46
sphardy1
Apprentice

Re: 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
Message 37 of 46
mdgm-ntgr
NETGEAR Employee Retired

Re: AFP Permission issues after new FW update

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.
Message 38 of 46
chazen
Aspirant

Re: AFP Permission issues after new FW update

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
Message 39 of 46
sirozha
Aspirant

Re: 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?
Message 40 of 46
sirozha
Aspirant

Re: AFP Permission issues after new FW update

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?
Message 41 of 46
sirozha
Aspirant

Re: AFP Permission issues after new FW update

mdgm wrote:
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.


mdgm,

Thanks for this tip. I will have to try it later today.
Message 42 of 46
dgerson76
Aspirant

Re: AFP Permission issues after new FW update

Strange issues here too- Duo on latest beta.

If i made a few new folders via the finder, and place some media in them, my WDTV can't see the media. It sees the folder, just no media. If i move the video to a previously existing folder, the video shows and plays fine. Very odd.

Thanks
Dan
Message 43 of 46
sphardy1
Apprentice

Re: AFP Permission issues after new FW update

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

The "nobody" user and "nogroup" group are standard Linux features (UID = GID = 65534). Mapping the OSX "guest" user to the linux "nobody" user is the default setup implemented by netatalk - so yes you can consider this "standard"

sirozha wrote:
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"?

I would interpret it that way, though I've never really noticed the use of "unlink" in that article before. Here's the linux man page description which is perhaps a better description:

Linux man pages wrote:

A directory whose `sticky bit' is set becomes an append-only directory, or, more accurately, a directory in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files.


sirozha wrote:
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?

Depends - as the man page states: "A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory..."

In that case, if the *file* does not have write access permission then it may still be deleted - the user is typically prompted to over-ride the lack of write permission, but that option may then be application dependent.
Message 44 of 46
dcl_
Aspirant

Re: AFP Permission issues after new FW update

mdgm wrote:
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.


Unfortunately I couldn't do this because I was unable to mount the default share of user (eg user XYZ automatically has a default share named XYZ which is only available to user and admin).

This is a default share (like media) but unlike media you're not able to change anything for obvious reasons.

However, simply restarting my mac solved the problem??? I'm a noob of course, but as Time Machine was working, the media share etc. was working fine, I just couln't figure why the default user share should be so obstinate.
Message 45 of 46
BeatCrazy
Aspirant

Re: AFP Permission issues after new FW update

I hate to cross-post, but maybe my issue is related to this one?

In my attempt to auto-mount my AFP shares after reboot, I ran across this problem with my NV. My shares do not display any info. I'm using Lion, and 4.1.8.t5.

I can access the shares from Lion, no problem. When I try to select Get info, I get this:



When I used Command +K, I'm able to connect via afp://xxx.xxx.x.xxx and can see my shares on the NAS NV. However, they are grayed out, I cannot select them.

So, something is wrong, but I don't know if it's an NV setting, or a Lion issue.
Message 46 of 46
Top Contributors
Discussion stats
Announcements