Is ACL inheritance broken in regards to SMB?

[FwuXi]

Hi, I recently upgraded (sidegraded?) A TrueNAS Core 13 install to TrueNAS SCALE. However there were some issues in getting my Samba shares back up and running. I only had three, so I just opted to recreate the shares, and the issue seemed dealt with; however, while working with and learning the new container apps, I went to edit the ACLs of a share, and add the apps user as read-only, and in testing this I discovered that inheritance isn't respected?

For example, if I have a userA, and userB, besides the root user, and each user's primary group is their respective groups created on account creation, and they both share an auxiliary group of 'aGroup' then setup a dataset owned by root and aGroup, with ACLs for user@root and group@aGroup set to full-control with inheritance, and a SMB share is created for this dataset with defaults. A Windows client logged into userA can create a file, but the group is reported as userA, and not as aGroup. Thus userB cannot modify, delete, or otherwise interact with the file. If you create a file with the shell as root, the file correctly inherits the group and its permissions, and can be modified or deleted by members of aGroup.

Is there something I'm missing in regards to the ACL setup here, or is this an issue with TrueNAS SCALE today? I searched and found a few threads from back when Scale was in beta, each ending rather abruptly with no resolution. So I'm not 100% on whether this is a known issue, or if there's a fix for this behavior if I'm not mistaken in my ACL setup.

 

[anodos]

Group@ references the owning group of a file (same one you see when you ls -l or stat(2) a file). Linux and FreeBSD have different default behaviors regarding which group owns a file on creation. FreeBSD inherits group from parent directory. Linux gets it from the process creating the file.

In latest versions of SCALE I altered behavior of NFSv4 ACL type to have freebsd behavior (because there is no strong expectations there regarding behavior, but if you are using POSIX1E then normal Linux behavior applies.

 

[FwuXi]

Just to double check then, I looked at which ACL type the dataset has and it is set to NFSv4. The version of SCALE I'm running is 22.02.3, I imagine this version has the altered behavior? If so, I'm not sure why it wouldn't work.

 

[FwuXi]

So I couldn't get NFSv4 ACLs to mimic the FreeBSD ones like you suggested; however, I seemed to be able to do what I needed by having 'create mask' and 'group' specified in the auxiliary parameters in the share's settings. Checking at the shell with the nfs4xdr_getfacl command, showed that not only were files being created with the correct perms and group, but also had the proper ACL permissions being applied when it came to making the apps user read-only. So for the time being, this seems to work.