[BUG] TrueNas Scale SMB/ACL permissions

[slize26]

Hey,

it is a bit hard to explain but i got an problem with files created over SMB.

I got 3 user accounts registered on my server ("admin", "slize", "xyz"). All of the accounts have access to 8 SMB shares on the server. When i am creating a file with the user "admin" only this user can access the folder/file in the ACL based share. The other two are getting an "Permission denied" error.

I think that i found the root of the problem: Newly created files (for example with the user "admin") are getting the Unix permissions "admin:admin rwxrwx---", that locks the file to this user. Correct would be"admin:builtin_users rwxrwx---" (thats how its behaving on my second TrueNas scale system, which is working fine).

My server version is TrueNAS-SCALE-22.02-RC.1-2 and the client runs Windows 10 21H1.

How can i fix that, so that new files are getting the correct group ("builtin_users") assigned?

 

[morganL]

Are there differences in the filesystem ACL for each of the different SCALE systems?
Can you show the filesystem ACL?

Shares |

Shares

www.truenas.com

 

[anodos]

There is a default behavior difference between FreeBSD and Linux WRT group on new file creation. In FreeBSD it is preserved from parent directory. In Linux, it will be created with primary group of process creating file. If you want to ensure that the builtin_users group has guaranteed access to the path in question, then you should set an explicit ACE for the group in question (in access and default ACL for POSIX1E ACLs, or inheriting entry for NFSv4).

 

[slize26]

Are there differences in the filesystem ACL for each of the different SCALE systems?
Can you show the filesystem ACL?

Shares |

Shares

www.truenas.com

Yes, there are different users registered. But i installed/configured both systems the same way and one is working fine , the other is not (both are running TrueNas Scale).
Regarding the filesystem ACL - i think they are included in one of the screenshots, or are there any other options to set ACLs?

There is a default behavior difference between FreeBSD and Linux WRT group on new file creation. In FreeBSD it is preserved from parent directory. In Linux, it will be created with primary group of process creating file. If you want to ensure that the builtin_users group has guaranteed access to the path in question, then you should set an explicit ACE for the group in question (in access and default ACL for POSIX1E ACLs, or inheriting entry for NFSv4).

Okay, i did not change these settings for the other system; but i will try it. Can you explain me where i should set the ACLs (I am only aware of this way: Three dots in the dataset section -> view permissions -> edit permissions -> "Save Access Control List")?

 

[morganL]

I provided the link the the share configuration which includes file system ACL in the post above.

 

[slize26]

I provided the link the the share configuration which includes file system ACL in the post above.

Than i dont get it. By following the instructions i am getting to the same settings as when i just navigate to the permissions in the storage tab.

As for the ACLs they are pretty much the same on both systems. The only difference are three missing local users (which do not exist on the "broken" system).

Edit #1:
I reinstalled the TrueNas OS and imported the pool. I stripped all the ACLs, recreated the users and still the same issue. The created files are getting the group and owner of the user that is creating the over SMB. That leads to insufficient permission when another user tries to open them over SMB (The file in the screenshot was created over SMB with the user "scans", the user admin gets an permission denied when he tries to open the file)

Edit #2:
It is still working fine on the other system. Every files gets the creator assigned as owner and "builtin_users" as group (so that everyone is able to access the files).

Edit #3:
I added a new disk with a new dataset and its behaviour is exactly the same:

 

[anodos]

Default ACL entries are the ones that define access for new objects created in a dataset. Above example only has UGO perms in the default ACL.

 

[slize26]

Thank you for the fast reply!

I am sorry, but i am super confused: Yes, that config is working on the new system, but i did not had to add the default group "builtin_users" and extra Mask for the default group on the other system. Why do i have to add it on this host?

 

[da-anda]

I also don't get why Scale would not set the `setgid` bit or provide an option to do so. I have the very same issue that I want all files created on a particular share have a fixed default user group, but this does not seem to be possible right now :(

 

[da-anda]

also, for some reason, the creating user and it's primary group are granted permissions twice, once as direct owner:group and secondly as additional ACL set user:username:x and group:usergroup:x. But this is only the case when the files are created via SMB, not when I create a file via CLI. All this ACL stuff is just so confusing and inconsistent. I basically don't want/need enhanced ACLs for several groups with different permissions and what not, all I am trying to achieve is that new files end up with a default fixed usergroup (`setgid` bit set in dataset entrypoint + subdirectories recursively) and not the users primary usergroup, and that `others` do not have any access by default.

 

[Jadan1213]

So I created two virtual machines to test permission differences.

• One VM running Scale 22.02.1
  • Created pool scale-data01
    • created dataset scale-permtest
      • Shared dataset scale-permtest over SMB
      • Created user crystawth for SMB access
      • Created "New Folder" on share
• One VM running Core 13.
  • Created pool core-data01
    • created dataset core-permtest
      • Shared dataset core-permtest over SMB
      • Created user crystawth for SMB access
      • Created "New Folder" on share

No defaults were changed, except the shares were set to SMB instead of Generic. Everything else is default. Here's what happened when I made the folder.

With default settings, on a fresh install of both operating systems, with no changes to ANY settings except for changing the dataset to be optimized for SMB, the CORE system inherits the group and rwx permissions. The SCALE system gives the folder the primary group of the user, with no permissions.

Next I changed the group owner on CORE to 'builtin_users' and on SCALE to 'users' and created a new folder in each directory. This is what happened:

This is with defaults. No changes to ACL type, no changes to permission settings, the only thing set on dataset creation is SMB over Generic.

No matter what i've tried on SCALE, I can NOT get it to inherit the group settings I want. I see all these posts about changing/altering the ACLs and all these things that are tried, but the simple truth is, you can NOT out of box, without pulling your hair out, get things to work as expected on SCALE. I get that FreeBSD and Linux handle things differently. Linux can be set to do this with the 'setgid' bit, but there's no option to do this in the UI, and chmod functionality is blocked when a dataset is configured for SMB.

So I bet you're asking, why not just use core? I want linux, with KVM, and docker. I love the idea of SCALE. But these permissions blunders are quite aggravating. So has anyone figured this out yet? The bigger question I suppose, is why ixsystems, has something not been put in place to get this functionality in a simple and reasonable way?

Forgive the rant, Not sure what to do at this point.

 

[anodos]

So I created two virtual machines to test permission differences.

• One VM running Scale 22.02.1
  • Created pool scale-data01
    • created dataset scale-permtest
      • Shared dataset scale-permtest over SMB
      • Created user crystawth for SMB access
      • Created "New Folder" on share
• One VM running Core 13.
  • Created pool core-data01
    • created dataset core-permtest
      • Shared dataset core-permtest over SMB
      • Created user crystawth for SMB access
      • Created "New Folder" on share

View attachment 56071

No defaults were changed, except the shares were set to SMB instead of Generic. Everything else is default. Here's what happened when I made the folder.


View attachment 56072

With default settings, on a fresh install of both operating systems, with no changes to ANY settings except for changing the dataset to be optimized for SMB, the CORE system inherits the group and rwx permissions. The SCALE system gives the folder the primary group of the user, with no permissions.

Next I changed the group owner on CORE to 'builtin_users' and on SCALE to 'users' and created a new folder in each directory. This is what happened:

View attachment 56073

This is with defaults. No changes to ACL type, no changes to permission settings, the only thing set on dataset creation is SMB over Generic.

No matter what i've tried on SCALE, I can NOT get it to inherit the group settings I want. I see all these posts about changing/altering the ACLs and all these things that are tried, but the simple truth is, you can NOT out of box, without pulling your hair out, get things to work as expected on SCALE. I get that FreeBSD and Linux handle things differently. Linux can be set to do this with the 'setgid' bit, but there's no option to do this in the UI, and chmod functionality is blocked when a dataset is configured for SMB.

View attachment 56074

So I bet you're asking, why not just use core? I want linux, with KVM, and docker. I love the idea of SCALE. But these permissions blunders are quite aggravating. So has anyone figured this out yet? The bigger question I suppose, is why ixsystems, has something not been put in place to get this functionality in a simple and reasonable way?

Forgive the rant, Not sure what to do at this point.

You can set up to 128 entries for different groups in an NFSv4 ACL. group@ is a special entry that maps to the owning group and you are seeing an OS difference between FreeBSD and Linux. You have the ZFS aclmode "restricted" set, which disallows chmod(2) in case of an ACL being present to prevent users from breaking their permissions through chmod. This is all working exactly as designed in ZFS and Linux.

We cannot go through existing data and alter the setgid bit on migration to Linux for users. That would be a huge POLA violation. With NFSv4 ACLs you have significantly better option than using setgid (just add an ACL entry for the group that should have access).

 

[anodos]

Okay. Wrote a patch for case of NFSv4 ACLs: https://github.com/truenas/linux/pull/49/files
We'll have FreeBSD-style S_GID / file creation semantics if the ZFS dataset acltype is NFSv4 ACL.

 

[bemarino]

If you don't need to be able to manage file/folder permissions from Windows, this is what I finally did:

1. Create dataset as normal. I left "Share Type" as Generic so we're dealing with Unix permissions only -- no extended ACLs.
2. Recursive chmod 2775 on all directories in the dataset (for the uninitiated, that's how you actually "setgid"), recursive chmod 664 on all files.
3. Recursive chgrp sharegroup on all directories in the dataset (replacing "sharegroup" with whatever you're naming the Unix group we're giving permissions to).
4. Create the SMB share with "No presets". This allows you to also uncheck "Enable ACL" (in the Advanced section).
5. Add "create mask = 0664" as the only auxiliary parameter on the SMB share.

The effect of this is that I'm only dealing with one set of bog-standard Unix permissions, and Samba creates new files/folders with both the correct group and permissions for that group.

I stress that Windows won't even be able to SEE the permissions on the files/folders in the share, so don't try this on your Active Directory domain. ;-) But a lot of us don't have anything that complicated. My use case was two users sharing files on my home NAS, and for that, this was SOOOO much easier for me to understand and troubleshoot.

 

[Jadan1213]

Okay. Wrote a patch for case of NFSv4 ACLs: https://github.com/truenas/linux/pull/49/files
We'll have FreeBSD-style S_GID / file creation semantics if the ZFS dataset acltype is NFSv4 ACL.

Wait so that's it? That little bit of code will make it work like we want? Easily and simply? That's pretty amazing actually.