AFP Permission issues after new FW update

Pixeltje wrote:

Did you, when entering your username, wait for the drop-down bar showing your username? I've had some similar problem a while ago because i just rapidly typed in my username and hit 'save'. I had no access to the share, but when I deleted the username and entered it again i noticed the drop down list with the suggestion of my username in it. When i clicked that instead of typing it myself, everything worked just fine. (On Sparc NV+).

Hrm, I did see the drop down but did not select it. I will lose my mind if it's that simple. :) Unfortunately I won't be able to give this a shot until I get home tonight, but thanks for the idea.

One other point of interest, in trying to rule out the client as being the issue I also tried mounting the share up on another computer that is still running snow leopard and it has the same behavior, so it would seem that it is not a client side problem at this point. Even if I set the perms to be as free as possible and set them recursively, there's no change in behavior. I see that the dirs are 777 via the command line, so anyone should be able to write to them, but no luck. The unit is also acting squirrely in that it doesn't reboot when I tell it to from the web page (have to use the power button). I've rebooted it several times in my troubleshooting to no avail. If the above suggestion doesn't work I'm not sure what other options I will have other than trying to re-install the firmware to the disks or wiping the unit back to factory, which of course requires me to get all the data off which is not a simple task.

Well, neither selecting the username from the dropdown nor reinstalling the firmware to disk resolved my issue. I'm rsyncing my files now and am going to go for a factory reset, as I don't really see any other option at this point. Needless to say, this has been disappointing, but thanks to everyone for their help/suggestions.

planetaaron. A factory reset would give you native EXT4 with huge file (>2TB) support and 4k sector alignment. Some nice things to have.

We have two macs running Lion, one with the behavior that everyone else here describes, and one that is working perfectly. It makes me think that it is something on the OS X side causing the problem. The errors on the nettalk.log getnamefromuuid failed: Resource temporary unavailable occurs when one of the workstations attempts to access the NAS.

I too have been experiencing permissions problems on my ReadyNAS NV since upgrading to the Beta RAIDiator 4.1.8-T5 to fix connectivity with Mac OS Lion. I got the "CNID DB" error after the upgrade, but the log reported no problems and I was able to access after a reboot. However, I do not seem to be able to add files or folders to the root directory of each of my two shares (BACKUP and MEDIA). Permissions for the shares are reported as: partner: Read & Write and everyone: no access on my Snow Leopard desktop with ethernet, and as: (unknown): Read & Write and everyone:No Access on my Lion notebook with wireless. Based on the advice in this thread, I tried resetting my permissions in the Advanced Tab, which had no effect. My problem is only with the root of each share; I have no problem adding files or folders to the folders that already exist in each share (their permissions are reported as everyone: Read & Write). I also tried creating a third share, which reports the same permissions as the two existing shares, and I have no trouble adding files or folders to it.

So does anyone have any advice or suggestions on how I can repair or reset the permissions at the root level of my two shares that existed prior to the upgrade?

Cheers,
Peter O.

I believe that I'm seeing the same issue that other folks are seeing. After upgrading from 4.2.17 to 4.2.18 on my Ultra 6, I can't write to the shares that I used to be able to write to under the previous firmware after connecting with my normal username. I tried creating a new share, a new group, and playing around with the options in the Advanced tab in the share list, but I still can't write files. The user/group and permissions on the ReadyNAS haven't changed for the share or any of the directories in it, and I can connect just fine - I just can't write.

I *can* write to those same shares if I connect to the share as "guest". The files get different permissions when I do that, but my issues with writing seem to be limited to connections made with my real username. After connecting to the same shares using CIFS using my real username, I can also write just fine. So, problems with AFP only when connecting with a real username.

I see the same behavior from a MBP running 10.6.8, and an iMac running 10.7.

The failures in the netatalk log are the ones mentioned above:

47.131916 afpd[7621] {acls.c:1121} (E:Default): getnamefromuuid(uuid, &username, &uuidtype) failed: Resource temporarily unavailable

Rob

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.

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.

In the past, when I created the users on the ReadyNAS, I made sure that the group UID and user UIDs were the same as they were on the mac. It worked before.

On my MBP, I could access the shares correctly. When I checked the UIDs, the MBP had a different UID than my other computer and the ReadyNAS.

I deleted my users on the ReadyNAS, re-created them--letting the ReadyNAS created the user's UID, and everything works perfectly.

Thanks!!

My permission issues differ slightly from rccoleman. I can't copy files or folders or create new folders in the root directory of my shares, regardless of whether I connect with my username or as a guest. No problems whatsoever copying files or creating folders within folders that already exist in my shares. Don't know much about UID/GID, but having the same problem on two shares with different UIDs. I can copy files and create new folders at root level from Windows in a VM, so I conclude the problem is with AFP. I'm having the exact same problems on a laptop recently upgraded to Lion and a desktop running Snow Leopard, suggesting the problem is with the enhancements to advanced AFP permission settings that came with 4.1.8-T5.
Cheers,
Peter O.

UPDATE - I RESOLVED this problem. When I did a "Get Info" on the shares with Pathfinder, I noticed under attributes that "locked" was checked. Unchecking it allowed me to add and delete files and folders in the root of my shares using either Pathfinder or Finder in either Snow Leopard or Lion.

Ok, this just gets weirder. After a factory reset, the only way that I can get it to work is to create a share on the readynas that is owned by a username that is *different* from the username/uid on my mac, then type in that username & password in the "Connect As" dialogue box. If I try to use my account name that is the same on the Mac and the Readynas, I can't write to it via the finder.

Next up, complete OS re-install.