AFP Permission issues after new FW update

Ok, as others have stated, I've confirmed that on Lion and radiator 4.2.18 the username is irrelevant but the UID must be different than whatever your UID is on your mac, otherwise you can't write to it via the finder. I would consider this to be a bug, especially since it wasn't a problem in previous versions, but I will leave that to others to decide if it should be addressed or not.

opt2bout wrote:
CharlesLaCour wrote: By any chance is you UID/GID on your Mac the same as on the ReadyNAS? I was having an issue like this and I changed my accounts UID/GID on the NAS and it is working OK. I change it back and it starts to fail again. Yes, they were identical. When they don't match, it works.

Ditto. Changed my UID to not match, chowned everything to the new UID, and my home share works fine now.

planetaaron wrote:
Ok, as others have stated, I've confirmed that on Lion and radiator 4.2.18 the username is irrelevant but the UID must be different than whatever your UID is on your mac, otherwise you can't write to it via the finder. I would consider this to be a bug, especially since it wasn't a problem in previous versions, but I will leave that to others to decide if it should be addressed or not.

If your conclusion is correct, then this *must* be fixed else the consequence is that Mac users can no longer properly take part in an NFS network which relies in synchronized UIDs for permissions control while also using AFP

sphardy wrote:

planetaaron wrote: Ok, as others have stated, I've confirmed that on Lion and radiator 4.2.18 the username is irrelevant but the UID must be different than whatever your UID is on your mac, otherwise you can't write to it via the finder. I would consider this to be a bug, especially since it wasn't a problem in previous versions, but I will leave that to others to decide if it should be addressed or not. If your conclusion is correct, then this *must* be fixed else the consequence is that Mac users can no longer properly take part in an NFS network which relies in synchronized UIDs for permissions control while also using AFP

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.

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

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

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

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.

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?

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.