ACL Permissions on SMB Share new items issue

[mtuttle007]

I'm new to TrueNAS running Scale 22.02-RC.2 and trying to understand how to setup ACL permissions on a dataset that is ultimately shared through a SMB share using the purpose "Default share parameters".

To simplify I have 2 local users setup in TrueNAS with the "Microsoft Account" option set to true on both. Both are part of the same group that has full permissions to my "shared" dataset. When I first set the permissions and copy all of my files over everything works fine.

The issue I'm having is when user A creates a file in my "shared" dataset only user A can open or modify the file. If I look at the permissions on the new file the owner is only set to whoever create the file (user A or B). The group permissions aren't being applied for whatever reason. If I set the permission recursively on my "shared" dataset again that fixes the permission issue. It's almost like I have a umask issue somehow.

The attached screenshots hopefully provide further clarification. If you could point me in the right direction I would appreciate it.

-Matt

 

[mtuttle007]

I believe I figured it out.

I had to add a "Group" entry in addition to just "group@". Both are set to "tutgroup".

"Group" seems to drive the default group on new items.

Does the above sound correct?

-Matt

 

[Destari]

From what I can tell, the SMB/NFSv4 permissions in SCALE are just an absolute nuclear disaster. I have similar issues, and permissions just flat out being ignored.

 

[anodos]

From what I can tell, the SMB/NFSv4 permissions in SCALE are just an absolute nuclear disaster. I have similar issues, and permissions just flat out being ignored.

What permissions are being flat-out ignored? Until fairly recently in the nightlies, ACLs weren't implemented for NFS protocol. This has now been addressed, and some users who use krb5+nfsv4+acls have confirmed everything is working as expected. This should be fully-functional in 22.02 release.

 

[anodos]

The issue I'm having is when user A creates a file in my "shared" dataset only user A can open or modify the file. If I look at the permissions on the new file the owner is only set to whoever create the file (user A or B). The group permissions aren't being applied for whatever reason. If I set the permission recursively on my "shared" dataset again that fixes the permission issue. It's almost like I have a umask issue somehow.

Okay. You've set permissions via "group@" this is equivalent to your "group" permissions in normal unix permissions (User, Group, Other).

In case of the share in question this is (tutgroup). Users who are a member of that group should be able to access the share. By default in Linux when a new file or directory is created, the new object's owning uid and gid are set to the uid and primary group's gid of the user creating the object.

So if "User A" has primary group of "User A" and auxiliary group of "tutgroup", then new file will still inherit `group@ - FULL CONTROL`, but this will now grant permissions to the group "User A" (the Group / gid of file). If "User B" has primary group of "User B" and auxiliary group of "tutgroup", he will not be able to access the new file.

The solution to this in general case (where you want to grant all local users on the NAS access to a share), just add an entry for the Group "builtin_users" (GROUP, not GROUP@).

When a dataset is created with the "SMB" preset, this group is automatically granted permissions.

In general if a datset is going to be accessed via both SMB and NFS on SCALE with the NFSv4 ACL type, it's probably a good idea to have
"aclmode == passthrough", leave the owner@, group@, and everyone@ entries in place (because these will be used to synthesize a POSIX mode for clients), and add an explicit entry granting builtin_users MODIFY or FULL_CONTROL.

 

[Destari]

I don't want o hijack the thread, so just let me know if I need to spin it into a new one.

My issue is that I am not using LDAP or AD for authentication, only local users. I am only using SMB, NFS is not used or enabled anywhere on the server. I have home shares set up, which get properly created under an encrypted dataset "Dataset 1", and an unencrypted dataset for everything else "Dataset 0". There is a child Dataset "Media" underneath Dataset0 which uses a different record size to optimize for very large files.

No matter what permissions I set or use against any of the datasets, only a user that is part of the "administrators group" configured under the SMB service itself can access *anything*. Of the 2 local non-root users I have tested thus far, they both have samba auth enabled and are allowed to authenticate but get an access denied when they try to access any of the shares. This includes home shares, which I have confirmed are owned by the correct user/group for the individual user, but are inaccessible by that user.

In my scenario I am using an "smb_media" group and adding a user "stream" to it, which belongs to a service that will only need access to that share. That smb_media group is given Full Access to the Media child dataset, and is properly visible through a Windows client in the security tab. The end result, however, is that the stream user account is unable to access that share at all. Stream is also unable to access it's automatically created home folder. If I add the stream account to an "smb_administrators" group which was set as the admin at the service level, the stream account can access all data correctly.

Again, Viewing the security tab under a Windows client shows the ACLs to actually be set correctly, including on home folders, but as soon as a user is removed from the admin group, they can access nothing at all, on any dataset shared over SMB.

I am running 22.02-RC.2

 

[anodos]

I don't want o hijack the thread, so just let me know if I need to spin it into a new one.

My issue is that I am not using LDAP or AD for authentication, only local users. I am only using SMB, NFS is not used or enabled anywhere on the server. I have home shares set up, which get properly created under an encrypted dataset "Dataset 1", and an unencrypted dataset for everything else "Dataset 0". There is a child Dataset "Media" underneath Dataset0 which uses a different record size to optimize for very large files.

NFSv4 ACLs here refers to a permissions model defined in RFC3530 and RFC5661. They are implemented in the local filesystem and govern local filesystem access.

No matter what permissions I set or use against any of the datasets, only a user that is part of the "administrators group" configured under the SMB service itself can access *anything*. Of the 2 local non-root users I have tested thus far, they both have samba auth enabled and are allowed to authenticate but get an access denied when they try to access any of the shares. This includes home shares, which I have confirmed are owned by the correct user/group for the individual user, but are inaccessible by that user.

This sounds like you have a permissions issue on some path component leading up to the share. For example if you have a share
"/mnt/tank/SHARE" and have made it so that only administrators can traverse/execute "/mnt/tank", then your users will not be able to access /mnt/tank/SHARE even if they have FULL_CONTROL of that path.

Unix strictly enforces traverse checking for paths.

 

[Destari]

NFSv4 ACLs here refers to a permissions model defined in RFC3530 and RFC5661. They are implemented in the local filesystem and govern local filesystem access.

I am aware, I was noting this to indicate I don't need the NFS protocol to be functional here, only SMB and it's required ACL formats. To that end, all datasets are set to a share type of "SMB"

Unix strictly enforces traverse checking for paths.

So am I right to assume that in this instance Child datasets will cause this to be completely non-functional? Because the "Stream" user does not have full access to Dataset0 nor all other shares under it, but does have access to child dataset "Media," it will be denied access to "Media" simply because of the hierarchy? This seems completely backward from what I am used to with SMB, because as far as I can tell, it's common practice to restrict access to the root directory except by administrative users to preserve the folder structure and force organization. Even more so in an access-based enumeration mode, which I have yet to test out within TrueNAS.

Additionally, I thought that Datasets in ZFS were considered separate filesystems; is there a separation where the child dataset can contain independent permissions? Or am I stuck moving child datasets to a root dataset?

 

[anodos]

I am aware, I was noting this to indicate I don't need the NFS protocol to be functional here, only SMB and it's required ACL formats. To that end, all datasets are set to a share type of "SMB"



So am I right to assume that in this instance Child datasets will cause this to be completely non-functional? Because the "Stream" user does not have full access to Dataset0 nor all other shares under it, but does have access to child dataset "Media," it will be denied access to "Media" simply because of the hierarchy? This seems completely backward from what I am used to with SMB, because as far as I can tell, it's common practice to restrict access to the root directory except by administrative users to preserve the folder structure and force organization. Even more so in an access-based enumeration mode, which I have yet to test out within TrueNAS.

Typical users in Windows have the "bypass traverse checking privilege", but it can be said the same is true in Windows (it's just not enforced). https://docs.microsoft.com/en-us/wi...rity-policy-settings/bypass-traverse-checking

We have a special permission set in the GUI "TRAVERSE" which can be granted to allow the user / group in question to pass through that path.
If you have Stream user that you want to grant access to
/mnt/tank/dataset0/media,
Then it will need

/mnt/tank - TRAVERSE (in this case Other + Execute)
/mnt/tank/dataset0 -TRAVERSE
/mnt/tank/dataset0/media - <whatever permissions you want>

This has been how permissions have worked in Linux / Unix basically since the beginning. My guess is lack of enforcement of traverse checking in Windows is probably for backwards-compatibility from times before they had NTFS ACLs (sins we commit for sake of backwards-compatibility and not breaking large users).

Additionally, I thought that Datasets in ZFS were considered separate filesystems; is there a separation where the child dataset can contain independent permissions? Or am I stuck moving child datasets to a root dataset?

They are separate filesystems. There is no reason to move around datasets. Like in Windows, every file / directory on ZFS has an ACL. You just need to make sure you're not cutting the legs out from under your users.

 

[Destari]

That definitely got things further than before.

In the case of my home folders, when applying traverse to "builtin_users" and ensuring that is set on both the root encrypted dataset and the "home" child dataset, the user is still unable to read their home folder. Instead applying the traverse permission to everyone@ seems to have the intended effect.

Is there a risk to allowing traversal to everyone@? I do not have any sort of guest access enabled, nor intend to enable it at any time.

In my case I am just attempting to reduce the total number of ACLs to maintain, in the event I have dozens of shares/groups under Dataset0 that all need to be denied access to the root.

 

[anodos]

That definitely got things further than before.

In the case of my home folders, when applying traverse to "builtin_users" and ensuring that is set on both the root encrypted dataset and the "home" child dataset, the user is still unable to read their home folder. Instead applying the traverse permission to everyone@ seems to have the intended effect.

Is there a risk to allowing traversal to everyone@? I do not have any sort of guest access enabled, nor intend to enable it at any time.

The rights assigned in case of TRAVERSE are: execute, read attributes, read extended attributes, and read ACL. This is sufficient for the smbd process to chdir(2) into the directory in question, but not to list its contents (read data is required). Since guest access is not allowed, access would be denied earlier in the session setup and so from a security standpoint I do not view this as a big issue.

In my case I am just attempting to reduce the total number of ACLs to maintain, in the event I have dozens of shares/groups under Dataset0 that all need to be denied access to the root.

In most cases I think a non-inheriting everyone@-TRAVERSE entry is appropriate on ZFS dataset mountpoints. But from the standpoint of providing a product for people to use at $place-of-work, it's best to allow the system administrator insight into what what is actually being set, and make judgment calls about how he or she wants to configure it.

 

[TurtleFX]

Hi,
After migration from CORE to SCALE (TrueNAS-SCALE-22.02.0) I noticed similar behaviour regarding permissions, as described by mtuttle007.

I have a user, e.g. "myuser" with primary group "nasusers" (no auxiliary groups are set).
user@ is set to "myuser", group@ is set to "nasusers".
if "myuser" on windows creates a file or folder on SMB share, only permissions for user "myuser" are set and no permissions for "nasusers" are created. i.e. following permissions are seen from terminal:

Code:

getfacl Test_Folder
# file: Test_Folder
# owner: myuser
# group: nasusers
user::rwx
group::---
other::---

In this situation, other users in "nasusers" group (e.g. "mysuer2") can't access those files/folders.
If I additionally add Full Control permissions to group "nasuers" (i.e. group@ is not changed and it is also set to "nasusers"), then if "mysuer" creates a filer or folder, permissions for the goup are also set:

Code:

getfacl Test_Folder
# file: Test_Folder
# owner: myuser
# group: nasusers
user::rwx
group::rwx
other::---

Is this expected behaviour?

Also, I have auxiliary parameter "ixnas:zfsacl_sortaces = true" set on all SMB shares and aclmode=passthrough on all datasets, because I am synching most of the datasets using syncthing plugin/app and without those settings chmod (executed by syncthing) was not working on CORE.

 

[anodos]

ixnas doesn't exist in SCALE. getfacl is wrong command if NFSv4 ACLs are present. From CLI you can use nfs4xdr_getfacl.

 

[TurtleFX]

Thanks for your reply.
Removed ixnas auxiliary parameter from SMB share.
I always used SMB shares nad never used NFS, so don't remember setting any NFSv4 ACLs.

Rechecked permissions using nfs4xdr_getfacl.
1) Withouth Full Control permissions for "nasusers" group (i.e. only group@ permissions are set):

Code:

nfs4xdr_getfacl Test_Folder
# File: Test_Folder
# owner: 2000
# group: 2000
# mode: 0o40700
# trivial_acl: false
# ACL flags: none
         everyone@:-------------s:fd-----:allow
            owner@:rwxpDdaARWcCos:-------:allow
            owner@:rwxpDdaARWcCos:fdi----:allow
            group@:rwxpDdaARWcCos:fdi----:allow

2) With additional Full Control permissions for "nasusers" group:

Code:

nfs4xdr_getfacl Test_Folder_2
# File: Test_Folder_2
# owner: 2000
# group: 2000
# mode: 0o40770
# trivial_acl: false
# ACL flags: none
         everyone@:-------------s:fd-----:allow
            owner@:rwxpDdaARWcCos:-------:allow
            owner@:rwxpDdaARWcCos:fdi----:allow
            group@:rwxpDdaARWcCos:fdi----:allow
group:nasusers:rwxpDdaARWcCos:fd-----:allow

In the 1st case, Syncthing app complains, that permission is denied to that folder, in the 2nd case everything is fine.
Syncthing app is is installed from TrueCharts catalog. runAsGroup and fsGroup are set to GID of "nasusers" group, i.e. 2000

 

[anodos]

NFSv4 ACL is about the specification, not the protocol. What about the full path to the dir in question? (each path component separately).

I'm asking because many users have followed bad advice of some youtube influencers and cut out legs from under themselves permissions-wise.

 

[anodos]

Ah, in your first example you have set the INHERIT_ONLY (i) flag on group@, which means that the ACL does not apply to the path in question. The only permission that is effective on that path is:
```
owner@:rwxpDdaARWcCos:-------:allow
```
So permissions are working as expected if your user is only a member of group 2000.

 

[TurtleFX]

ACLs on each path component:

Code:

nfs4xdr_getfacl /mnt
nfs4xdr_getfacl: Failed to get NFSv4 ACL

nfs4xdr_getfacl /mnt/Tank0
# File: /mnt/Tank0
# owner: 0
# group: 0
# mode: 0o40755
# trivial_acl: false
# ACL flags: auto-inherit:
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow

nfs4xdr_getfacl /mnt/Tank0/Unsorted
# File: /mnt/Tank0/Unsorted
# owner: 2000
# group: 2000
# mode: 0o40770
# trivial_acl: false
# ACL flags: none
         everyone@:--------------:-------:allow
            owner@:rwxpDdaARWcCo-:fd-----:allow
            group@:rwxpDdaARWcCo-:fd-----:allow

nfs4xdr_getfacl /mnt/Tank0/Unsorted/Test_Folder_3
# File: /mnt/Tank0/Unsorted/Test_Folder_3
# owner: 2000
# group: 2000
# mode: 0o40700
# trivial_acl: false
# ACL flags: none
            owner@:rwxpDdaARWcCos:-------:allow
            owner@:rwxpDdaARWcCos:fdi----:allow
            group@:rwxpDdaARWcCos:fdi----:allow

As far as I remember, I never changed ACLs and permissions on the pool (Tank0). I removed INHERIT_ONLY (i) flag on group@ from "Unsorted" dataset, but permissions on newly created folder "Test_Folder_3" remained the same as in the 1st case. INHERIT_ONLY (i) flag is set on it for some reason.
Syncthing is still complaining if group "nasusers" is not added to ACL.

 

[anodos]

ACLs on each path component:

Code:

nfs4xdr_getfacl /mnt
nfs4xdr_getfacl: Failed to get NFSv4 ACL

nfs4xdr_getfacl /mnt/Tank0
# File: /mnt/Tank0
# owner: 0
# group: 0
# mode: 0o40755
# trivial_acl: false
# ACL flags: auto-inherit:
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow

nfs4xdr_getfacl /mnt/Tank0/Unsorted
# File: /mnt/Tank0/Unsorted
# owner: 2000
# group: 2000
# mode: 0o40770
# trivial_acl: false
# ACL flags: none
         everyone@:--------------:-------:allow
            owner@:rwxpDdaARWcCo-:fd-----:allow
            group@:rwxpDdaARWcCo-:fd-----:allow

nfs4xdr_getfacl /mnt/Tank0/Unsorted/Test_Folder_3
# File: /mnt/Tank0/Unsorted/Test_Folder_3
# owner: 2000
# group: 2000
# mode: 0o40700
# trivial_acl: false
# ACL flags: none
            owner@:rwxpDdaARWcCos:-------:allow
            owner@:rwxpDdaARWcCos:fdi----:allow
            group@:rwxpDdaARWcCos:fdi----:allow

As far as I remember, I never changed ACLs and permissions on the pool (Tank0). I removed INHERIT_ONLY (i) flag on group@ from "Unsorted" dataset, but permissions on newly created folder "Test_Folder_3" remained the same as in the 1st case. INHERIT_ONLY (i) flag is set on it for some reason.
Syncthing is still complaining if group "nasusers" is not added to ACL.

That's because it has no permissions to the path. You're runas group 2000, but what's the uid it's running as? The ACL on Test_Folder_3 does not permit it access (only allows file owner).

I'm not familiar with syncthing's internals, but correct way to sync NFSv4 ACLs in SCALE would be for app to copy the "system.nfs4_acl_xdr" xattr from source to destination. Rsync has options to do this (depending on version).

 

[TurtleFX]

Syncthing app runs with default UID 568.

It can access all existing files and folders inside this “Unsorted” dataset, which is connected to Syncthing app. I can create files and folders from the shell of Syncthing app/container. Permissions of such folder and file:

Code:

nfs4xdr_getfacl /mnt/Tank0/Unsorted/Test_Folder_Syncthing
# File: /mnt/Tank0/Unsorted/Test_Folder_Syncthing
# owner: 568
# group: 2000
# mode: 0o40770
# trivial_acl: false
# ACL flags: none
            owner@:rwxpDdaARWcCo-:fd----I:allow
            group@:rwxpDdaARWcCo-:fd----I:allow

nfs4xdr_getfacl /mnt/Tank0/Unsorted/Test_Folder_Syncthing/Test_File_Syncthing
# File: /mnt/Tank0/Unsorted/Test_Folder_Syncthing/Test_File_Syncthing
# owner: 568
# group: 2000
# mode: 0o100770
# trivial_acl: false
# ACL flags: none
            owner@:rwxpDdaARWcCo-:------I:allow
            group@:rwxpDdaARWcCo-:------I:allow

And I can access these files and folders with “myuser” on SMB share on Windows. So user inside Syncthing app/container (UID 568, GID 2000) has access to this dataset.

The issue is only with new files, which are created by “myuser” (UID 2000, GID 2000) on SMB share.
And this issue disappears, if I set group (in addition to group@) permissions on this dataset. But group and group@ are the same (GID 2000) and permissions for group@ and group are the same (Full Control).

So I still don’t understand, why this is happening.

 

[TurtleFX]

Just noticed, that if file is created by my "myuser" on SMB share inside a folder, which was previously created by syncthing user, it does not have group permissions:

Code:

 nfs4xdr_getfacl /mnt/Tank0/Unsorted/Test_Folder_Syncthing/Test_File_SMB
# File: /mnt/Tank0/Unsorted/Test_Folder_Syncthing/Test_File_SMB
# owner: 2000
# group: 2000
# mode: 0o100700
# trivial_acl: false
# ACL flags: none
            owner@:rwxpDdaARWcCos:-------:allow

Folder created in same directory has group permissions applied:

Code:

nfs4xdr_getfacl /mnt/Tank0/Unsorted/Test_Folder_Syncthing/Test_Folder_SMB
# File: /mnt/Tank0/Unsorted/Test_Folder_Syncthing/Test_Folder_SMB
# owner: 2000
# group: 2000
# mode: 0o40700
# trivial_acl: false
# ACL flags: none
            owner@:rwxpDdaARWcCos:-------:allow
            owner@:rwxpDdaARWcCos:fdi----:allow
            group@:rwxpDdaARWcCos:fdi----:allow

However, syncthing does not have access to the folder and to the file created by "myuser" on SMB share.