Cannot write to AFP share regardless of permissions

[Bish]

Hello (first post!) all

Sorry for the length of this, but want to be thorough. Everything was going so well, until... Well no, loads of things went utterly wrong, but I've steadily been reading this forum (and elsewhere) and educating myself, and thought I'd got somewhere. But suddenly things went wrong.

SO. Running 9.2.1.6 as a home file server. All clients are Macs, so I went with AFP. I appreciate it's not a very popular option around here but bear with me.

I created two shares, one at /mnt/MyStuff/General and one at /mnt/MyStuff/Video*, set both up identically for guest access - it's a home network, everyone's trustworthy and I've a backup regime in place such that if anyone screws up nothing too awful will happen. Allow list has 'nobody' and Read write access has 'nobody'. AFP3 Unix Privs are turned on because the oldest client runs 10.6.8 so should be fine. In default file/folder permissions I went ahead and checked everything and left Default umask on 000.

So, I played around with it for a bit and found myself rather pleased with my reasonably fast and very functional NAS. Everything worked much better than previous consumer boxes I've tried before and I was very happy. I rsynced a couple of TB of data from one of those boxes (a slow process, but we got there in the end) and carried on testing. After several days of mucking around, and waiting for an inherited crashplan backup to complete, I was satisfied that my (non critical) data was fairly safe and stable.

And then last night something weird happened. I'd left one of my desktop machines copying some more videos over to the nice new NAS and mounted the /Video share on a laptop, expecting to see a bunch of files waiting to be organised, but there was nothing there. I went back to the desktop and found it had thrown up a username / password dialog box, and leaving it blank and pressing enter (to trigger the nobody profile) didn't work.

That left me with a /General share which anyone could continue to read, write and execute on, and a /Video one which could only be read. That sounded like an ownership problem (except that I hadn't changed anything), so I ssh into the box as root and do chown -R nobody:nobody /mnt/MyStuff/Video

That changed absolutely nothing. ls -lo revealed that all files had 775 permissions. Maybe chmod to 777 could help? No, operation not permitted in this build.

I've since succeeded in making the /General share behave exactly like the /Video share - in a stupid moment of stupid, I wondered if simply changing the General share to /mnt/MyStuff would allow me to fix the /Video permissions in the Mac Finder, but no, it just broke things more.

So to recap - I now have a very big 1/5 full NAS that I can no longer write to, at all. I've tried reboots between removing the shares and recreating them, turning the AFP service off and on, chowning the whole lot to a new guest user and simply supplying the new credentials when mounting in the OS, but nothing works - whatever I do, I've still got a read-only file system and cannot find a way to undo it. There are no peculiar flags or attributes going on (except everything being marked uarch, but I think from what I've read, that's just zfs marking files and folders that have changed since the last snapshot, right?), lsattr shows everything blank.

I've now gone around and around this hundreds of times in the last 24 hours and have read an awful lot of threads which don't have answers for me - can anyone help?

*Actual paths have been changed to conceal geekdom.

 

[cyberjock]

Ok, so I'm writing a guide for FreeNAS permissions. I have no experience with Mac permissions, but this may work. So can you be my guinea pig? If so, try this command:

winacl -a reset -rxp /mnt/MyStuff/Video

That, I hope, will allow you to have access to your files again. ;)

 

[Bish]

Thanks cyberjock. Always happy to be a guinea pig, but sadly, no, that doesn't solve it - it runs quietly for a good long while and then returns to the prompt, and when I remount the share it's still not giving the guest user write permissions (and also still not letting me connect with any other user).

In the meantime, I finally relented and recreated the shares as NFS shares - hey presto, guest account can read/write with no problems. So I have at least a short-term fix and probably a long term one. I'd still rather use AFP (I know it's on its way out, but the convenience of having shares that automatically reveal themselves in the finder* is a huge bonus for friends/family who come over... and yes, bar one, they all use macs!) but if a fix can't be found and the NFS doesn't suddenly do the same thing, I've at least got a functional NAS!

*I'm not aware of a way to make NFS shares do this, but if anyone is...?

 

[Bish]

Aw crap, spoke too soon - I just tested writing by creating a new folder and deleting it. That works fine, but when I try to copy something over from a local drive, it asks for a username and password. I can put one in and it tries to copy, but then fails because it's already copied zero byte files with the same file names. Overwriting them doesn't work, and I just end up with a folder full of empty files.

The positive is that the Finder is now showing correct permissions: Get Info on a file or folder pulls up the owner as nobody, so that's something. So now the share is read/write accessible, but I can't actually copy stuff... Anyone have any ideas where I'm going wrong?

 

[esamett]

cyberjock:

please give this guinea pig the correct syntax to fix windows acl for windows user.
thanks.

evan

ps; my very little brain tried:

winacl -a reset -rp /mnt/tank
trying to reset everything recursively in tank
result: able to change some permissions and copy some files and folders, but not all: "you will need to provide administrative permission..."

winacl - add -rp /mnt/tank
not sure what "add" command is
result: same

[root@freenas ~]# winacl -a add -rp /mnt/windowsbackup/backup-password
winacl: invalid action


[root@freenas ~]# winacl -a update -rp /mntwindowsbackup/backup-password
[root@freenas ~]#
result: same problem

[root@freenas ~]# winacl -a reset -rxp /mnt/windowsbackup/backup-password
[root@freenas ~]#
result: same problem


[root@freenas ~]#
[root@freenas ~]# rsync -a /mnt/windowsbackup/backup-password/ /mnt/test2/datase
t2
result:
No files transferred, just the directory structure. Folders still "read only." Windows does not allow me to change permission to delete. Unable to delete dataset from FreeNAS GUI for several minutes "Busy" error. Finally worked.

Shell
es/Spain 2011/.Spain 2011 990.jpg.myZKTl" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/test2/dataset2/backup2/jack dell 610/My Documents/My Pictur
es/Spain 2011/.Spain 2011 991.jpg.WUoYEA" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/test2/dataset2/backup2/jack dell 610/My Documents/My Pictur
es/Spain 2011/.Spain 2011 992.jpg.1yOfMy" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/test2/dataset2/backup2/jack dell 610/My Documents/My Pictur
es/Spain 2011/.Spain 2011 993.jpg.2u5ik8" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/test2/dataset2/backup2/jack dell 610/My Documents/My Pictur
es/Spain 2011/.Spain 2011 994.jpg.TFbejz" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/test2/dataset2/backup2/jack dell 610/My Documents/My Pictur
es/Spain 2011/.Spain 2011 995.jpg.FeillE" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/test2/dataset2/backup2/jack dell 610/My Documents/My Pictur
es/Spain 2011/.Spain 2011 996.jpg.X96kf0" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/test2/dataset2/backup2/jack dell 610/My Documents/My Pictur
es/Spain 2011/.Spain 2011 997.jpg.Pj2wt2" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/test2/dataset2/backup2/jack dell 610/My Documents/My Pictur
es/Spain 2011/.Spain 2011 998.jpg.7bIkqJ" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/test2/dataset2/backup2/jack dell 610/My Documents/My Pictur
es/Spain 2011/.Spain 2011 999.jpg.tylgQt" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/test2/dataset2/backup2/jack dell 610/My Documents/My Pictur
es/Spain 2011/.Thumbs.db.NMExe4" failed: Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 2
3) at main.c(1053) [sender=3.0.9]
[root@freenas ~]#

[root@freenas ~]# rsync -rtl /mnt/windowsbackup/backup-password/backup2/ /mnt/te
st2/dataset2a/backup2/
[root@freenas ~]#
result: files transfer over but I am unable to change permissions on new dataset

[root@freenas ~]# cp -RL /mnt/windowsbackup/backup-password/backup2/ /mnt/test2/
dataset2a/backup2/
[root@freenas ~]#
result: files transfer but unable to to change permissions on new dataset

 

[Bish]

Esamett/Evan:

No idea what's going on with your setup. I assume you're using CIFS which (until the post I'm writing now) has nothing to do with this thread, but if you've really reached the 'screw this, let's start again' point with your permissions, you might want to read up on rsync flags some more, as it has some handy ignore permissions options - make sure the umask and default permissions for your .../test2/dataset2 are sensible and you might have more success.

Everyone else:

Anyhow. NFS didn't work for me either. Tried CIFS which now works properly, but is slooooow. It also declares itself in my finder as two different names, even though everything is off in services except CIFS and SSH (and S.M.A.R.T). Honestly I can't see that I've done much wrong. Extensive googling revealed a blog post back in 2010 that recommended chmodding the whole share to 777 - exactly what I wanted to try doing, but can't - and a post here saying that blocking root from chmod is a new feature.

Can someone please give me an alternative way to just whack permissions wide open? I know this is a terrible idea long term - my eyes are well and truly open - but just want to see if this resolves the basic problem of read/write access on AFP: if it does, I can use Finder to take ownership of the files client-side and then try making the permissions more sensible, and see if I get anywhere. Alternatively, if anyone has a magic bullet, let me know (not holding my breath).

If not, I'm probably going to have to admit defeat with freenas, change systems and go through the whole rigmarole of migrating data again...

 

[esamett]

Yeah, its CIFS. There is a SNAFU with SAMBA which is under CIFS. Going from version 3 to 4 which recently happened. Apparently some ugliness with permissions is no longer "swept under the rug." My confusion is that I don't understand what permissions I need to get Windows/CIFS happy and how to reset them.

I don't know what umask is. I set up my volume with UNIX 777 and the dataset with Win/Mac permissions. User: nobody, Group: nogroup.

Thanks

 

[Bish]

Sorry my bad, you don't have a umask setting in the CIFS bit (it just sets a kind of default permissions profile for new files, but is confusingly back-to-front in that it's more like setting prohibitions, so 000 has the same effect as 777 would...). This is possibly terrible advice from a noob, but have you considered going to the dataset permissions and switching to Unix type permissions and then back again?

I'd strongly recommend you check with more knowledgeable people whether that'd possibly screw things up before trying it, but in an ideal world, when you switched back to Win/Mac permissions it might revert things.

Also, on the offchance you haven't tried it, you could run

chown -R nobody:nogroup /mnt/Lowest/Folder/In/Your/Share

But do make sure that's not going to mess with any Jails.

Oh, and on the AFP stuff it recommends setting both owner and group to 'nobody' (not 'nogroup'), but I'm not sure what difference that does or doesn't make. Easy to test - if the above command doesn't help, swap the nogroup bit for nobody.

 

[Bish]

Oh and on a tangent - anyone? Any suggestions to fix my problem?

 

[esamett]

I will report progress. I am corresponding with cyberjock on another thread. To quote the Man with no Name - Clint Eastwood: "Sometimes a Man's life depends upon the merest shred of information."

good luck!
evan

 

[L]

So I am a mac/unix user. Nobody is historically an untrusted root user. I would change your dataset ownership to be owned by guest. Also take off the allow user of nobody..