SMB Windows Shares + Domain Joined - Domain Users added by default

frtruenas

Cadet
Joined
Jan 3, 2022
Messages
4
I'm new to TrueNas and I've been scratching my head for some time trying to figure this out, I hope there are some seasoned users out there that can assist.

I've joined my TrueNas instance to my windows domain controller (no issues seeing users or groups), created my pool and a dataset for SMB shares and set my permissions - so far so good. The issue is that no matter what options/settings I use, the "Domain Users" group from AD is always added to new files/directories with modify permissions (when its not listed in the ACL), which means any user can delete files.

My setup.

TrueNAS-SCALE-22.02-RC.2

Clients:
- Windows 8.1
- Windows Server 2016

Dataset
- ACL mode = Restricted
- ACL Type NFSv4
- Case Sensitivity = Insensitive (default)

Filesystem ACL:

ObjectPermissionPermission TypeFlags
owner@ - rootFull Control (Inherit)BasicBasic
group@ - rootModify (inherit)BasicBasic
Domain\GroupAModify (Inherit)BasicBasic
Domain\GroupBRead (Inherit)BasicBasic
Domain\GroupBTraverse (Inherit)BasicBasic

Windows SMB Share Permissions

GroupPermissionType
EveryoneFull Allowed


A user in GroupA can create files and directories, and "Domain\Domain Users" is added with modify permissions. A user in GroupB is not able to create files/directors (as expected) but can delete files/folders created by a user in GroupA. I can't figure out why "Domain\Domain Users" group is added, I've even tried to explicitly add an entry for that group and grant it only READ access, but that didn't work either. If I go back and re-apply the permissions to the dataset, it does remove the "Domain\Domain Users" group and things work as expected, but again any new files receive the group.

Playing with the ACL for Windows SMB share gets me close, but according to my interpretation it's purpose is for Access Based Share Enumeration. If i add an entry for GroupB with only READ access in the SMB share, it does prevent the user from deleting the file, but domain users is still listed as having modify permissions. I don't want to use this as a workaround in the event that what I've read is correct and that it's only used for Access Based Enumeration and one day it starts working as intended.

Source: https://www.truenas.com/docs/core/sharing/smb/smbshare/


Any ideas? And sorry for the long post.

Thank you
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,546
If you're concerned, remove the group@ entry. Linux will create new files with the primary group of the user creating the file. Primary group for AD users defaults to "domain users".
 

ClassicGOD

Contributor
Joined
Jul 28, 2011
Messages
145
Like @anodos wrote removing group@ entry should solve your issue but here is why:

user@ and group@ entries are "dynamic" and always refer to owner of the file/folder. It's root for your top directory but if user in GroupA creates a folder that user is its owner and the user@ and group@ entries are populated with this user and his primary group which like @anodos mentioned defaults to "domain users" for AD users. That is why user from GroupB suddenly gains permissions to this folder as he is a part of "domain users" and thus gets permissions defined in group@.
 

frtruenas

Cadet
Joined
Jan 3, 2022
Messages
4
Yayyyyyyyyyyy :smile: thank you @anodos and @ClassicGOD for the explanation. Makes complete sense. I didn't fully understand the purpose of user@ and group@ (even after reading many articles/posts). This deserves to be added as a footnote for the Windows SMB share page, the simple explanation might help future noobies like myself.

I'm not sure if its problematic for the operation of TrueNas but i've also removed user@ as the share is a simple one, in that only those in GroupA can modify and GroupB can read, didn't need to have the AD account of the individual that created the files listed in the permissions and there will be no need to modify the permission from windows.
 

frtruenas

Cadet
Joined
Jan 3, 2022
Messages
4
Just an update, I've decided to keep user@ in there, helps with troubleshooting open connections and who's creating the files (e.g. had a connection from another service that kept re-creating a folder and had no idea where it was coming from until I added user@, saw who created it and with smbstatus was able to track it down to the client.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,546
Just an update, I've decided to keep user@ in there, helps with troubleshooting open connections and who's creating the files (e.g. had a connection from another service that kept re-creating a folder and had no idea where it was coming from until I added user@, saw who created it and with smbstatus was able to track it down to the client.
In windows you should still be able to view the file owner (advanced option in security tab) without there being an explicit owner@ ACE. On local side, file owner is returned in stat(1) and stat(2) output.
 

frtruenas

Cadet
Joined
Jan 3, 2022
Messages
4
@anodos. Just ran a test by removing owner@ , and that is correct, the owner is listed in the "advance security" screen in windows this sure helps keeping the ACL clean while still having other means to troubleshoot/track down where issues may be coming from.

Thank you for the assist, with this setup I'm finally able to start moving my data over to TrueNas.
 
Top