AFP Permissions Issue?

[ObiTobi]

Hi all,

I wish you happy new year :D

I updated my box from 9.1 to 9.2 Release. It work all but there are some things
For all my AFP shares I see in messages afp permission error and I have no idea why.

As example
afpd[36397]: sys_lsetxattr("/mnt/zpool01/home/."): Permission denied

FS-Permissions shows like this:
ls -la /mnt/zpool01/home/
total 637
drwxr-xr-x 39 root wheel 39 Jan 1 11:59 ./
drwxr-xr-x 12 root wheel 12 Dec 14 13:21 ../
drwxr-x---+ 16 tobi domänen-benutzer 43 Jan 1 12:13 tobi/

Users have only wrtire/ change permissions for your own home directory.

Cheers

 

[jkh]

Right, but something is trying to set an extended attribute on the parent directory, and that's not permitted so obviously you're going to get a Permission denied error. In other words, this is behaving exactly as expected! No mystery there.

 

[ObiTobi]

Would it be better the ACL switch from Unix to Windows?

 

[jkh]

Yes.

 

[ObiTobi]

I'm not sure if I have to do something else somewhere. I have now changed with the settings from Unix to Windows. The only thing that has changed as a result is that in each directory a file ".windows" was created
The message from the top is still there.

 

[jkh]

Hmm. We just fixed a bug with AFP sharing that will be in the 20140104 9.2.1-ALPHA image, once that's finished building and up on the site. It might actually fix this, but it's not clear yet. You might want to check back on cdn.freenas.org in a day or so!

 

[ObiTobi]

fine. Thank you very much :D

 

[jkh]

OK, try this build: http://cdn.freenas.org/9.2.1/ALPHA/20140106/

It should be at least as good as 9.2.0 in terms of quality (we haven't changed a lot) but fixes a number of AFP permissions problems.

 

[ObiTobi]

Ok. I tried today the snapshots from 0601 and 0701. Nothing has changed on the afp error messages.
The Time Machine backup not working with both snapshots.

 

[jkh]

Ok. I tried today the snapshots from 0601 and 0701. Nothing has changed on the afp error messages.
The Time Machine backup not working with both snapshots.

Hmm, OK, I'm out of ideas then. I totally cannot reproduce this problem! My Macs are all successfully backing up to Time Machine on multiple FreeNAS boxes running 9.2.0 and 9.2.1.

 

[shmixx]

I'm getting the same error as opp above:
Jan 31 14:49:44 atlantis afpd[9300]: sys_lsetxattr("/mnt/vol1/private/."): Permission denied
My goal is for Share1 to be able to be read/write for anyone added to homeusers group. Currently though, it doesn't seem to be happening.

Current Build: FreeNAS-9.2.1-RC-83ae0c1-x64
3 AFP Shares. 2 users all part of a group (homeusers).

• TM1 - Works as intended
  • Dataset Owner: user1
  • Dataset Group: homeusers
  • Dataset ACL: Windows/Mac
  • Share Allow: user1
  • Share Read/Write: user1
  • Share default permissions: 755/644
• TM2 - Works as intended
  • Dataset Owner: user2
  • Dataset Group: homeusers
  • Dataset ACL: Windows/Mac
  • Share Allow: user2
  • Share Read/Write: user2
  • Share default permissions: 755/644
• Share1 - Don't have permission to "modify some items"
  • Dataset Owner: nobody
  • Dataset Group: homeusers
  • Dataset ACL: Windows/Mac
  • Share Allow: @homeusers
  • Share Read/Write: @homeusers
  • Share default permissions: 775/664 (tried normal permutations of 755/644 as well, no dice)

Is there something I'm missing to be able to write to this directory? And/or is my hunch on modifying AFP default permissions on this share logical for my end goal?

 

[ObiTobi]

The bug with the permissions is still here on 9.2.1 and 9.2.1.1

 

[jkh]

The bug with the permissions is still here on 9.2.1 and 9.2.1.1

This may not be a bug. Be sure to set ACL rather than unix permissions here (e.g. Perms as set with the setfacl command, not file permission mode flags). I think for the more nuanced permissions you folks are trying to achieve, you will need to drop to the CLI to set the right ACLs since FreeNAS does not have an ACL permission UI. Most CIFS customers use the windows file explorer permissions UI for this, but since this is being done from a Mac, it should probably be done on the FreeNAS side. See FreeBSD setfacl man page for details.

 

[ObiTobi]

I see something different. With Maverick has Apple expanded the EA. This should be now implemented in the AFP/ Netatalk . Since it is apparently not and / or incorrectly implemented in FreenNAS, I see it as a bug (see my first post).
As far as I know in other NAS systems, the changes are all implemented (Synology, Qnap)

 

[jkh]

I'm not sure I understand what you mean by "Apple has expanded the EA". Can you give more technical details? Are you saying that default global afpd configuration is wrong? Really not enough details to go on in your post.

 

[ObiTobi]

Not much really but something is here

 

[jkh]

Not much really but something is here

No, not helpful since it doesn't really tell us anything about netatalk's configuration or how it might / should be changed. Maybe you want to change your afpd.conf to specify "ea = ad" (use .AppleDouble files, which are of course capable of being any size) and see if that changes the behavior?

 

[ObiTobi]

If you tell me how I can change it ...
I can not find afpd.conf here. There is only one /etc/local/afp.conf and has in the global section these settings

[Global]
uam list = uams_dhx.so uams_dhx2.so
max connections = 50
mimic model = Xserve
vol dbnest = yes

Manual I can not change it because the FS is mounted RO. Or in other words, that file is generated from "/usr/local/libexec/nas/generate_afpd_conf.py" (This file is ob RO FS) and my changes are discarded so.

 

[jkh]

From root shell:

mount -uw /
Edit afpd.conf
Stop and start AFP service

These changes won't persist but good enough for testing purposes.

 

[ObiTobi]

Anther question. Are you sure, that the "ea = auto" is default setting? The man page give no answer which is the default value.