I’m trying to understand how ACLs are designed to work in TN.
I just need SIMPLE permissions to SMB shares, no complicated/detailed ACLs.
I have been able to specify (individual) user Share ACLs to an SMB share & have said share visible & available on Win.
HOWEVER if I use a UserGroup to specify Share permissions, permissions are NOT granted.
The following GUI info indicates that FILESYSTEM level ACLs have predecence over SHARE level ACLs.
With DATASTORE group given access to the DATASTORE share, DATASTORE is NOT visible/avail on Win.
If I give Usergroup DATASTORE Filesystem level access to DATASTORE share, then DATASTORE share IS visible/avail on Win.
What I really want is to be able to allow user access to SMB Shares via UserGroups. I really don’t need Filesystem level ACLs.
This does not seem to be supported.
In fact, the precedence of Filesystem ACLs over Share ACLs appears to be OPPOSITE of logic.
Would it not be EASIER to provide basic access/ACLs via Share ACLs, then extend/fine-tune those permissions via Filesystem ACLs?
Or is my problem that “user” specified SHARE ACLs are supported, but “UserGroup” specified SHARE ACLs are NOT supported?
Confused…
Talk to Microsoft… they create the SMB rules. TrueNAS has to comply.
For what you want, the AI bot in docs gave me an answer… but it was complex and unverified.
Read the “permission” page… it might give you some ideas of how to set it up.
Generally speaking you should leave share ACLs as default. Access should be controlled by filesystem ACLs which you can configure within the dataset all via the TrueNAS UI.
1 Like
Ok tnx for confirming that.
Seems counter-intuitive, but if that’s how TN/SMB is designed, at least i now know.
That’s not a TN/SMB thing. This is how permissions work for all servers that implement the SMB protocol.
When admins configure an SMB share on Windows for instance, they typically leave the share ACL open, and then configure the filesystem (NTFS) ACL.
If we did otherwise (ignored filesystem ACL in favor of the share ACL – disregarding that the kernel / filesytem enforces permissions checks), it would be a CVE in the product.
Incorrect.
I don’t know Windows servers, I’m comparing to QNAP SMB… Where ACLs actually need to be enabled as an EXTRA. The QNAP norm is to specify share level permissions via user or group.
Okay. So they are advertising over SMB protocol that the filesystem doesn’t support permissions. This is equivalent on Windows to sharing a FAT filesystem.
This also means that they’re breaking support for SMB3 POSIX extensions (which allow for chmod / setting ACLs) and obscuring the what permissions are on the underlying filesystem (or doing something quite insecure at the OS level).
In the SMB protocol the way to manipulate filesystem permissions in general is through the ACL. Regardless of OS serving SMB (MacOS, Windows, etc) the local filesystem permissions are encoded into an NT ACL and returned to SMB client. The client can then also set the permissions.
Consider the case where you share the same path via SMB and NFS. The NFS client can chmod a file, but if you have SMB lie that filesystem permissions don’t exist then the SMB client gets access denied errors for unclear reasons.
Tnx for the detail, was helpful.
It seems that TN is using pure SMB, the MS method. Which is good.
As you added, ACLs are also the way Linux handles file permissions.
Not at all surprised that QNAP seems to be cutting corners to simplify their OS/GUI.
Apparently QNAP also have a very non-std ZFS implementation.
OK, so after a little testing/trying… I’ve found the following experience with my Share & Filesystem ACLs & permissions…
I deleted all Share ACLs for each share, however I found that after a deletion, a default Share ACL of “Everyone/Full Access” was auto added.
Scenario 1
- I changed the “Everyone” Share ACL to All/Denied.
- Filesystem ACL set to “UserGroup/Full Access”.
Scenario 1 Result:
SMB/Share access denied in Win.
Scenario 2:
- Share ACL to “Everyone / Read Allow”
- Filesystem ACL left on “Usergroup / Full Access”
Scenario 2 Result :
Could see Share Filesystem, but NOT create anything new.
Scenario 3 :
- Share ACL to “UserGroup / Full Access”
- FileSystem ACL left on “UserGroup / Full Access”
Scenario 3 Result :
Finally Full Read/Write access to all Shares on Server.
So… It seems that ACL rights have to be given at BOTH the Share & Filesystem levels… Interesting.
1 Like
I changed the “Everyone” Share ACL to All/Denied.
This should never be set. Deny entries take precedence and so it will prevent ALL access by EVERYONE to the share. The share ACL will define the maximum permissions any user / group can get to the share.
Typically (in the Windows world and elsewhere) you grant FULL control via share ACL and define permissions via filesystem (NTFS) ACL.
They are focussed on the low-end market… TrueNAS is designed for Enterprises and secure Government organizations. We just make the software free for community adoption.
Ah!
I would never have guessed this, or found this in any documentation.
Appreciate the insight.
