SAMBA Share Improper Inheritance (ixnas vs zfsacl) on MacOS

Fox

Explorer
Joined
Mar 22, 2014
Messages
66
I have an issue with FACL inheritance between my mac (client) and my truenas core box SMB share.

When I use the SMB/SAMBA vfs objects "zfsacl" aux setting (referenced below) it works as expected, but using the default ixnas, causes the following issue.

I would rather avoid customizing/adding the SMB aux settings in the share because I will need to maintain it and confirm it still works each time I upgrade to a new version of TrueNas. I'm wondering if the following behavior I'm seeing is a bug, or a "feature".

Problem walk through:

First I create a file from the mac command line on the SMB share as follows:
Code:
mac>: touch /mySMBshare/docs/subdir/x
mac>: ll
-rwx------  1 fox  wheel      0 Jan 18 16:15 x

Now I log into the truenas core box and take a look at the file, specifically the inheritance of permissions:
Code:
truenas>: getfacl /mnt/tank/docs/subdir/x
# file: x
# owner: fox
# group: wheel
            owner@:rwxpDdaARWcCos:------I:allow
            group@:rwxpDdaARWcCos:------I:allow

The above is working as expected when using zfsacl, but when using the ixnas, which is the default vfs objects setting, I get the following:

On the mac I create the file called "z"
Code:
mac>: touch /mySMBshare/docs/subdir/z
mac>: ll
-rwx------  1 fox  wheel      0 Jan 18 16:20 z

Now on truenas I show the permissions, but they are not correct:
Code:
truenas>: getfacl /mnt/tank/docs/subdir/z
# file: z
# owner: fox
# group: wheel
            owner@:rw-p--aARWcCos:-------:allow
            group@:rw-p--a-R-c--s:-------:allow
         everyone@:rw-p--a-R-c--s:-------:allow

The permissions/facls on the parent folder:
Code:
truenas>: getfacl /mnt/tank/docs/subdir
# file: .
# owner: root
# group: wheel
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow

Other settings:
Code:
[docs]
    path = /mnt/tank/docs
    guest ok = no
    read only = no
    comment = documents
    nfs4:chown = true
    ea support = false
    fruit:encoding = native
    mangled names = no
    smbd max xattr size = 2097152
    fruit:metadata = stream
    fruit:resource = stream
    fruit:time machine = yes
    fruit:locking = none
    vfs objects = catia fruit streams_xattr shadow_copy_zfs ixnas zfs_core aio_fbsd
    hide dot files = yes



Thanks
 
Last edited:

Fox

Explorer
Joined
Mar 22, 2014
Messages
66
What version of TrueNAS is this and is the ZFS dataset 'aclmode' property for that path set to 'RESTRICTED'?
TrueNAS Core Ver: TrueNAS-13.0-U3.1

Using "PASSTHROUGH" as the ACL data mode
 

Fox

Explorer
Joined
Mar 22, 2014
Messages
66

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
This seems to work.. Thanks..
Looking at your ACL, it's non-default for us (in that it only has owner@, group@, everyone@ entries). We typically add explicit group entries for builtin_users and builtin_administrators. Depending on server configuration (it looks like you're using vfs_fruit) MacOS clients can use special NFS ACEs to basically chmod and overwrite these entries. Setting aclmode to restricted prevents this. I find this better matches admin expectations for ACL inheritance behavior.
 

Fox

Explorer
Joined
Mar 22, 2014
Messages
66
Looking at your ACL, it's non-default for us (in that it only has owner@, group@, everyone@ entries). We typically add explicit group entries for builtin_users and builtin_administrators. Depending on server configuration (it looks like you're using vfs_fruit) MacOS clients can use special NFS ACEs to basically chmod and overwrite these entries. Setting aclmode to restricted prevents this. I find this better matches admin expectations for ACL inheritance behavior.
Actually, my setup can be more complicated, with explicit groups, but I opted for a simple example. I like setting my permissions using the command line on truenas with setfacl, I guess I'm old school.

I had been using Windows for years but this year I switched to a mac.. I like the mac, but my biggest complaint (SAMBA related) is the slow speed when doing a "share to share" copy, when the shares are on the same server. Windows SMB automatically figured it out and did not copy down to the client and back up, and it was fast, way faster than my gigabit ethernet speed. I think this feature is called "Server to Server" copy in SAMBA.. I wish I could get it to work with the mac.. I searched and I thought I was close, but no luck.

Thanks again

R
 
Top