SOLVED File rights, ACL please kill me now.

[spacecabbie]

So,
Situation:
Truenas 12 with 2 zfs pools and 5 datastores
Pool: https://i.imgur.com/qDVF3Ee.png
Datastore: https://i.imgur.com/VodhsCS.png
For reference purposes I am not attached to their settings and kan be changed.

3 datastores with smb share.

https://i.imgur.com/WCMsvu1.png

https://i.imgur.com/Cm3sczp.png

3 jails all writing to the data store via mounted dir.

Now I am trying to change to proper permissions last time I gave up made a script to reset all file rights open to everyone every 5mins.
So I am try'ing to understand ACL and it seems simple enough still the issue I keep getting a double entry for everyone@

Code:

# file: /mnt/Isolinear_chip/Plex Media
# owner: hhaufe
# group: media
         everyone@:rwxp-daARWc---:fd-----:allow
            group@:rwxp-daARWc---:-------:allow
            owner@:rwxp-daARWcCo-:-------:allow
         everyone@:--------------:fd-----:allow

Why does that happen I am setting a base ACL (strip and then defaults) and then edit and apply rights from windows I understand that better then do it under freebsd.

 

[ChrisRJ]

If it makes you feel better, I also always struggle with this. Perhaps I still need to see some good example, but the user experience of ACLs in FreeNAS 11.3U5 is by far the worst I have experienced for file access configuration. Novell NetWare was the best, followed by native Windows (although that was on NT 4 and so is very dated). Linux and Unix groups on earlier FreeNAS were ok-ish, but lacked the flexibility I would have wanted for enterprise use.

 

[anodos]

So I am try'ing to understand ACL and it seems simple enough still the issue I keep getting a double entry for everyone@

The secondary empty everyone@ is added by the samba VFS module in this case to lock ZFS acl inheritance behavior to be more windows like. In the absence of inheritable entries for the special entries owner@, group@, everyone@, ZFS will add new non-inheriting ones based on umask at file creation. This is surprising for windows admins who explicitly remove these entries on SMB shares (they don't want CREATOR-OWNER, CREATOR-GROUP, and EVERYONE entries randomly appearing in shares).

Regarding setting via Windows or the FreeNAS GUI, they both do the same thing. The samba VFS module intercepts the SMB2 setinfo request and translates it into the native FreeBSD syscall for setting NFSv4 ACLs. The FreeNAS webui makes the same syscall.

 

[spacecabbie]

The secondary empty everyone@ is added by the samba VFS module in this case to lock ZFS acl inheritance behavior to be more windows like. In the absence of inheritable entries for the special entries owner@, group@, everyone@, ZFS will add new non-inheriting ones based on umask at file creation. This is surprising for windows admins who explicitly remove these entries on SMB shares (they don't want CREATOR-OWNER, CREATOR-GROUP, and EVERYONE entries randomly appearing in shares).

Does that mean if I set inheritable ACL it does not happen ?
Also which one takes precedence ? because the double one does not have any rights so I am unsure if its causing issues atm. (I do not thinkso but still)

Regarding setting via Windows or the FreeNAS GUI, they both do the same thing. The samba VFS module intercepts the SMB2 setinfo request and translates it into the native FreeBSD syscall for setting NFSv4 ACLs. The FreeNAS webui makes the same syscall.

Yes good point webgui also generated the double everyone@ I was setting via windows because I remember reading somewhere this would be better. But that was an old post. I can set it via CLI also.

Thank you btw for your exelend explanation

 

[anodos]

Does that mean if I set inheritable ACL it does not happen ?
Also which one takes precedence ? because the double one does not have any rights so I am unsure if its causing issues atm. (I do not thinkso but still)

You can think of allow entries as summing up. "full control" + "none" = "full_control". It doesn't cause issues. If you are solving an issue via changing permissions in a cronjob, that means that something is setting permissions behind your back (SMB clients or jailed processes with access to same dataset are prime culprits for this). In the case of a jailed process, the interaction between syscalls to set a POSIX mode and an existing ZFS ACL is nuanced and configurable.

For SMB shares we default to setting ZFS to deny attempts to set a POSIX mode when a non-trivial ZFS ACL is present (the ZFS dataset property aclmode=restricted), but if a dataset is set to "aclmode=passthrough" (non-SMB-optimized ZFS dataset) chmod(2) will alter your owner@, group@, and everyone@ to reflect the POSIX mode specified in the syscall. This includes stripping all inheritance flags and removing some permissions bits that samba interprets to reflect a user's permissions. For most predictable behavior with ACLs on an SMB share, I recommend using the "restricted" aclmode and explicit group entries (not group@) for handling permissions.

If you must use a passthrough aclmode (there are some applications with inadequate error handling that do not respond well to chmod(2) failing with EPERM), then there are two configuration options (mutually exclusive) that will lead more predictable results:

1) strip ACLs from the dataset, and then in the SMB share configuration, uncheck the "ACL" checkbox.
2) set an explicit ACL entry granting the group FULL_CONTROL.

For general purposes with the GUI ACL editor, I recommend sticking to the BASIC ACL permissions sets and flag sets (just like one should generally avoid using the "advanced" ACL editor on windows).

I also strongly recommend running the latest version of 12.0. In 12.0-U2 I fixed an ACL bug in our samba VFS module.

 

[spacecabbie]

You can think of allow entries as summing up. "full control" + "none" = "full_control". It doesn't cause issues. If you are solving an issue via changing permissions in a cronjob, that means that something is setting permissions behind your back (SMB clients or jailed processes with access to same dataset are prime culprits for this). In the case of a jailed process, the interaction between syscalls to set a POSIX mode and an existing ZFS ACL is nuanced and configurable.

For SMB shares we default to setting ZFS to deny attempts to set a POSIX mode when a non-trivial ZFS ACL is present (the ZFS dataset property aclmode=restricted), but if a dataset is set to "aclmode=passthrough" (non-SMB-optimized ZFS dataset) chmod(2) will alter your owner@, group@, and everyone@ to reflect the POSIX mode specified in the syscall. This includes stripping all inheritance flags and removing some permissions bits that samba interprets to reflect a user's permissions. For most predictable behavior with ACLs on an SMB share, I recommend using the "restricted" aclmode and explicit group entries (not group@) for handling permissions.

If you must use a passthrough aclmode (there are some applications with inadequate error handling that do not respond well to chmod(2) failing with EPERM), then there are two configuration options (mutually exclusive) that will lead more predictable results:

1) strip ACLs from the dataset, and then in the SMB share configuration, uncheck the "ACL" checkbox.
2) set an explicit ACL entry granting the group FULL_CONTROL.

For general purposes with the GUI ACL editor, I recommend sticking to the BASIC ACL permissions sets and flag sets (just like one should generally avoid using the "advanced" ACL editor on windows).

I also strongly recommend running the latest version of 12.0. In 12.0-U2 I fixed an ACL bug in our samba VFS module.

Alrighty seems I got hooked up on that double entry. It seemed i had already resolved the issue just never tested since I figured it was not going to work thanks !