AFP/netatalk: Can no longer create a directory after 9.2.1.7 upgrade

[DaPlumber]

AFAIK the only change to my setup, both OS X Mavericks clients and FreeNAS is the upgrade to FreeNAS 9.2.1.7-RELEASE.

Since that update I can no longer create a directory/folder on the AFP shares/exports from the FreeNAS system. I get a permissions error no matter if I do it via Finder or CLI. Directly logged into the FreeNAS box I can mkdir no problem. The issue is not confined to a single share. The permissions and share setting had not been changed when the issue started appearing, still appear correct, and more liberal permissions haven't fixed the issue either. Files can be created, deleted and modified. Directories/folders can be deleted but not created.

Help?

 

[DaPlumber]

So talking to myself here...

Noticed a "+" at the end of the permissions for the new directory I was created on the share via NAS CLI and also on the share mount point, but not on any of the previously created directories. Hmmm. Don't want no stinkin' ACLs, so some quick "setfacl -b" work later all is now working as expected with nary a restart of anything required. So, where did the ACL turn on come from?

 

[dlavigne]

What type of dataset and what type of permissions on that dataset?

 

[DaPlumber]

What type of dataset and what type of permissions on that dataset?

Um, not sure what you mean by dataset it's a standard zfs dataset with lz4, here's the AFP Perms, the owner and groups are all correct and (as I said) unchanged:

BTW the AFP3 checkbox gets the award for "Most useless help":

If you meant the output of a "zfs get all my pool/myshare":

NAME PROPERTY VALUE SOURCE
mypool/myshare type filesystem -
mypool/myshare creation Wed May 28 23:14 2014 -
mypool/myshare used 1.14T -
mypool/myshare available 3.11T -
mypool/myshare referenced 1.13T -
mypool/myshare compressratio 1.00x -
mypool/myshare mounted yes -
mypool/myshare quota none default
mypool/myshare reservation none default
mypool/myshare recordsize 128K default
mypool/myshare mountpoint /mnt/mypool/myshare default
mypool/myshare sharenfs off default
mypool/myshare checksum on default
mypool/myshare compression lz4 inherited from mypool
mypool/myshare atime on default
mypool/myshare devices on default
mypool/myshare exec on default
mypool/myshare setuid on default
mypool/myshare readonly off default
mypool/myshare jailed off default
mypool/myshare snapdir hidden default
mypool/myshare aclmode restricted local
mypool/myshare aclinherit passthrough inherited from mypool
mypool/myshare canmount on default
mypool/myshare xattr off temporary
mypool/myshare copies 1 default
mypool/myshare version 5 -
mypool/myshare utf8only off -
mypool/myshare normalization none -
mypool/myshare casesensitivity sensitive -
mypool/myshare vscan off default
mypool/myshare nbmand off default
mypool/myshare sharesmb off default
mypool/myshare refquota none default
mypool/myshare refreservation none default
mypool/myshare primarycache all default
mypool/myshare secondarycache all default
mypool/myshare usedbysnapshots 7.70G -
mypool/myshare usedbydataset 1.13T -
mypool/myshare usedbychildren 0 -
mypool/myshare usedbyrefreservation 0 -
mypool/myshare logbias latency default
mypool/myshare dedup off inherited from mypool
mypool/myshare mlslabel -
mypool/myshare sync standard default
mypool/myshare refcompressratio 1.00x -
mypool/myshare written 360K -
mypool/myshare logicalused 1.14T -
mypool/myshare logicalreferenced 1.13T -
mypool/myshare volmode default default

 

[Dennis.kulmosen]

This sounds like this bug: https://bugs.freenas.org/issues/5751
Please update the bug report with your findings to solve this issue.

 

[DaPlumber]

This sounds like this bug: https://bugs.freenas.org/issues/5751
Please update the bug report with your findings to solve this issue.

Well spotted. "Me too" added to bug report 5751 for 9.2.1.7-RELEASE.