Using TrueNAS Core v13.0-U3.1. I access a SMB share from a Windows 10 PC and the access rights seems ok except for some specific files. To simplify things, say one of the file are in a "Files" folder at the root of the dataset and is named "File A". Here are the details :
TrueNAS User
Name : steve
Password : (defined)
User ID : 1000
Samba authentication : Enabled
Permit Sudo : Enabled
Auxiliary groups : wheel, builtin_users
Windows User
Name : steve
Password : (defined, same as TrueNAS User)
TrueNAS SMB Share
Name : Media
Path : /mnt/Main/Media
Purpose : Default share parameters
Enabled : Yes
ACL for /mnt/Main/Media
1. everyone@ : Traverse - No Inherit
2. owner@ : Full control - Inherit
3. group@ : Full control - Inherit
4. builtin_users : Modify - Inherit
5. steve : Full Control - Inherit
"Files" Directory access rights
FreeBSD Rights : drwxrwx---
Owner user : steve
Owner group : wheel
"File A" File access rights
FreeBSD Rights : -rwdrwx---
Owner user : steve
Owner group : wheel
ACL :
I expect the Windows account used to authenticate to the share to be mapped with success to the same account name on TrueNAS as their names and password are the same. But it don't seems to always be the case as I can't read or inspect security on "File A". But on the "Files" folder, it works as I am able to create a directory, open it and delete it.
From the windows PC, I created a "File B" in the "Files" directory. It worked, I am able to read it, consult the security settings and delete it. The owner was "steve" and the group owner was "wheel". The FreeBSD and ACL rights was identical to the "File A" specified above.
So, I understand something is possibly wrong with the security of the file created by the Docker, but I don't understand why two files with the same OS and ACL security react differently. I am searching for an answer please.
TrueNAS User
Name : steve
Password : (defined)
User ID : 1000
Samba authentication : Enabled
Permit Sudo : Enabled
Auxiliary groups : wheel, builtin_users
Windows User
Name : steve
Password : (defined, same as TrueNAS User)
TrueNAS SMB Share
Name : Media
Path : /mnt/Main/Media
Purpose : Default share parameters
Enabled : Yes
ACL for /mnt/Main/Media
1. everyone@ : Traverse - No Inherit
2. owner@ : Full control - Inherit
3. group@ : Full control - Inherit
4. builtin_users : Modify - Inherit
5. steve : Full Control - Inherit
"Files" Directory access rights
FreeBSD Rights : drwxrwx---
Owner user : steve
Owner group : wheel
"File A" File access rights
FreeBSD Rights : -rwdrwx---
Owner user : steve
Owner group : wheel
ACL :
- owner@:rwxpDdaARWcCos:------I:allow
- group@:rwxpDdaARWcCos:------I:allow
- group:builtin_users:rwxpDdaARWc--s:------I:allow
- user:steve:rwxpDdaARWcCos:------I:allow
- everyone@:--------------:------I:allow
- A docker application who uses UID 1000 ("steve" on the host) and GID 1000 ("wheel" on the host) create "File A" in the "Files" directory.
- On the Windows PC, I access the share using the hostname who is known from the DNS : \\srvr-nas
- Authentication pop up. I enter "steve" and the password who is the same on the Windows PC ans TrueNAS.
- I see the shares. I go to the "Media" share.
- I can do anything on all the files and directory whose owner user is root as I am in the "wheel" group.
- I go to the "Files" directory on the "Media" share.
- I can create and delete a directory.
- I cannot read "File A" but can delete it.
- Naturally, unable to read advanced security settings and unable to change the owner.
I expect the Windows account used to authenticate to the share to be mapped with success to the same account name on TrueNAS as their names and password are the same. But it don't seems to always be the case as I can't read or inspect security on "File A". But on the "Files" folder, it works as I am able to create a directory, open it and delete it.
From the windows PC, I created a "File B" in the "Files" directory. It worked, I am able to read it, consult the security settings and delete it. The owner was "steve" and the group owner was "wheel". The FreeBSD and ACL rights was identical to the "File A" specified above.
So, I understand something is possibly wrong with the security of the file created by the Docker, but I don't understand why two files with the same OS and ACL security react differently. I am searching for an answer please.
