AFP: unable to create folders after upgrade to 220.127.116.11
Upgrading to 18.104.22.168 breaks folder creation on AFP shares. Even if you opens up all permissions on dataset and in the AFP share.
uam list = uams_dhx.so uams_dhx2.so
max connections = 50
mimic model = RackMac
vol dbnest = yes
path = /mnt/NaStarTest/NaStarTest
valid users = nastar
rwlist = nastar
cnid dev = no
file perm = 775
directory perm = 777
umask = 000
A ls -la reveals:
drwxr-xr-x 5 root wheel 5 Aug 11 02:12 ./
drwxr-xr-x 4 root wheel 512 Aug 11 01:36 ../
drwxr-xr-x 7 root wheel 8 Aug 11 01:23 .freenas/
drwxr-xr-x 6 root wheel 6 Aug 11 01:36 .system/
drwxrwxr-x+ 3 nastar wheel 4 Aug 11 02:41 NaStarTest/
the user nastar has wheel as primary group. Even if you give the user all the permissions and set it as owner, you are unable to create folders.
#1 Updated by Juliano Arantes over 6 years ago
Just adding it also happens on a fresh install, and there are no problems using CIFS.
The AFP share was correctly set in regards to "Allow List: estudio" and "Read-write Access: estudio".
I've created the dataset choosing "Share type = Apple" and set the owner to "estudio" and the group to "onovodia". I've also chosen "Permission Type = Windows/Mac ACL".
Checking folder permissions with getfacl returns:
- file: plexmedia
- owner: estudio
- group: onovodia
I've read on other threads I should not use the "Full Name" to login and that's also not the case...
Restarting the service as suggested by another user didn't help either.
#5 Updated by Josh Paetzel over 6 years ago
- Status changed from Screened to Investigation
Netatalk in 22.214.171.124 and 126.96.36.199 doesn't have ACL support, however the nightly alpha images for 9.3 do. Could you by chance test one of them out to see if that resolves the issue you are seeing?
(I ask because there may be more needed than what has been done so far)
#6 Updated by James Dean over 6 years ago
Dennis Juhler Aagaard wrote:
If you do a setfacl -b on the share, your troubles are gone. But that is not a solution just a quick fix if you dont need acl. But hey if the ACL's dont work then it is the fix.
Used this workaround after had the same folder creation issue after an upgrade from 188.8.131.52-RELEASE to 184.108.40.206-RELEASE. Not using LDAP or CIFS.
#10 Updated by Dennis Juhler Aagaard over 6 years ago
Building with OPTIONS_FILE_SET+=ACL \
You haven't made other changes regarding this bug?
Because i have a custom 220.127.116.11 build i only want to correct this issue in and not introduce other things too. :)
I should be able to test at the end of my day. :)
#13 Updated by Josh Paetzel over 6 years ago
It doesn't fix the problem. I think the solution is to put unix permissions on AFP shares.
By default, the effective permission of the authenticated user are only mapped to the mentioned UARights permission structure, not the UNIX mode. You can adjust this behaviour with the configuration option mac acls:
map acls = none|rights|mode (G)
no mapping of ACLs
effective permissions are mapped to UARights structure. This is the default.
ACLs are additionally mapped to the UNIX mode of the filesystem object.
If you want to be able to display ACLs on the client, you must setup both client and server as part on a authentication domain (directory service, eg LDAP, Open Directory, Active Directory). The reason is, in OS X ACLs are bound to UUIDs, not just uid's or gid's. Therefor Netatalk must be able to map every filesystem uid and gid to a UUID so that it can return the server side ACLs which are bound to UNIX uid and gid mapped to OS X UUIDs.
Netatalk can query a directory server using LDAP queries. Either the directory server already provides an UUID attribute for user and groups (Active Directory, Open Directory) or you reuse an unused attribute (or add a new one) to you directory server (eg OpenLDAP).
#15 Updated by Dennis Juhler Aagaard about 6 years ago
I have been testing this by building the 18.104.22.168 image with OPTIONS_FILE_SET+=ACL \
plus i have made the change in /freenas/nanobsd/Files/usr/local/libexec/nas/generate_afpd_conf.py
@cf_contents.append("\tmax connections = %s\n" % afp.afp_srv_connections_limit)
cf_contents.append("\tmimic model = RackMac\n") * cf_contents.append("\tmap acls = mode\n")*@
So far it has solved all my problems when making a new dataset and AFP share.
However an old share still has the faulty ACL's attached and need to be removed with the setfacl -b
The setfacl command used in freenas do not support recursive mode, so all shares needs to be walked through.
Plus i have made my shares with the radio button labeled unix, which confirmes your findings.