Project

General

Profile

Bug #5751

AFP: unable to create folders after upgrade to 9.2.1.6

Added by Dennis Juhler Aagaard over 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Important
Assignee:
Josh Paetzel
Category:
OS
Target version:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

Upgrading to 9.2.1.6 breaks folder creation on AFP shares. Even if you opens up all permissions on dataset and in the AFP share.

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

[NaStarTest]
path = /mnt/NaStarTest/NaStarTest
valid users = nastar
rwlist = nastar
cnid dev = no
file perm = 775
directory perm = 777
umask = 000

A ls -la reveals:

total 45
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.


Related issues

Related to FreeNAS - Feature #3242: Enable AFP ACL support when using LDAPClosed: Not To Be Fixed2013-10-01
Copied to FreeNAS - Bug #5825: AFP: unable to create folders after upgrade to 9.2.1.6Resolved2014-08-11

Associated revisions

Revision d9bf8a34 (diff)
Added by Josh Paetzel over 6 years ago

Add ACL support to netatalk Ticket: #5751

History

#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:

  1. file: plexmedia
  2. owner: estudio
  3. group: onovodia
    owner@:rwxpDdaARWcCos:fd----:allow
    group@:rwxpDdaARWcCos:fd----:allow
    everyone@:r-x---a-R-c---:fd----:allow

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.

#2 Updated by Josh Paetzel over 6 years ago

  • Status changed from Unscreened to Screened
  • Target version set to 9.3-M2

I susperct this is somehow related to ACL support in netatalk, which I just enabled recently, but don't remember exactly when. I shall research this.

#3 Updated by Dennis Juhler Aagaard over 6 years ago

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.

#4 Updated by Josh Paetzel over 6 years ago

  • Related to Feature #3242: Enable AFP ACL support when using LDAP added

#5 Updated by Josh Paetzel over 6 years ago

  • Status changed from Screened to Investigation

Netatalk in 9.2.1.6 and 9.2.1.7 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?

http://download.freenas.org/nightly/x64/

(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 9.2.1.6-RELEASE to 9.2.1.7-RELEASE. Not using LDAP or CIFS.

#7 Updated by Josh Paetzel over 6 years ago

  • Copied to Bug #5825: AFP: unable to create folders after upgrade to 9.2.1.6 added

#8 Updated by Josh Paetzel over 6 years ago

  • Target version changed from 9.3-M2 to 9.2.1.8-RELEASE

#9 Updated by Josh Paetzel over 6 years ago

This needs testing but it should 'in theory' fix the problem

#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 9.2.1.7 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. :)

#11 Updated by Josh Paetzel over 6 years ago

That's the only change I've made, but I haven't tested it to see if it actually fixes the problem.

#12 Updated by Dennis Juhler Aagaard over 6 years ago

My building machine is dead slow, so i will first have a chance to test it tomorrow (GMT+1)
I will report any findings, thanks. :)

#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)

none
no mapping of ACLs 
rights
effective permissions are mapped to UARights structure. This is the default.
mode
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).

#14 Updated by Josh Paetzel about 6 years ago

  • Status changed from Investigation to Resolved

8f1b19e5458987abfda03ff4cb043f95f61bb763

causes the permissions radio button to be labeled unix/mac which will do the right thing.

#15 Updated by Dennis Juhler Aagaard about 6 years ago

I have been testing this by building the 9.2.1.7 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.

Also available in: Atom PDF