What is the difference between SMB ACLs and filesystem ACLs?

[troudee]

Why is there an extra option to edit a share's ACLs, extra to the option to edit the filesystem ACLs?

Isn't there any way to just use the filesystem ACLs for the share as well?

I've set up some shares with filesystem ACLs on the datasets, and TrueNAS seems to have created share ACLs in the type of "Allow everything":

This means, despite having "Access based share enumeration" switched on, a user is able to see a share he has no right to see (filesystem ACL) and is rejected after having clicked on it.

 

[anodos]

> Isn't there any way to just use the filesystem ACLs for the share as well?
As I have time I'm trying to improve some of our documentation regarding this. No. This isn't possible because they are separate things (even in Windows). If you have a windows server handy, you can see that there are separate tabs in "Computer Management" for Share and Security.

As a general rule of thumb, as with Windows, you really should be working with the filesystem ACL rather than the share one.

 

[troudee]

Thank you for your reply!

As a general rule of thumb, as with Windows, you really should be working with the filesystem ACL rather than the share one.

So the best thing to do is to set all restrictions and (what's the word for opposite of "restriction"? Allowances? Permissions?) permissions in the file system ACL manager and just ignore the share ACL manager option? When doing this, the "Access based share enumeration" has no effect?

 

[anodos]

Thank you for your reply!



So the best thing to do is to set all restrictions and (what's the word for opposite of "restriction"? Allowances? Permissions?) permissions in the file system ACL manager and just ignore the share ACL manager option? When doing this, the "Access based share enumeration" has no effect?

That would be the exception to the "general rule of thumb". If you want that particular feature to work, you will need to set permissions there as well.

You can view the share ACL as determining the maximum possible permissions for any user / group.

For example, if you set up the filesystem ACL so that everyone is read-only, and the share ACL grants everyone full control, the resulting permissions on the share will be read-only. If you grant everyone full_control at the filesystem level, but set MODIFY on the share, then everyone will be limited to the modify permissions set.

"access based share enumeration" evaluates the share ACL, and only adds the share to the list returned as a net_share_enum response if the caller has access to the share via the share ACL.

This means that if you want to define this, create the share and start the SMB server. This starts up winbindd which handles SID<->ID resolution, and then add your groups to the share ACL (and remove the everyone entry). FULL permissions works here.

 

[troudee]

Okay, then I think I will leave the share ACLs as they are auto generated and work with the file system ACLs only. The "Access based share enumeration" would be nice but it isn't necessary at all.

Thank you very much for your help!

 

[winnielinnie]

Is a "Share ACL" generated by default every time you create a new share? It's hard to tell by using the GUI. If you click "Edit Share ACL" it presents you with an entry of "FULL ALLOWED permission for Everyone". Is it reading that as an existing entry, or is it only proposing that entry before you click save?

 

[anodos]

Is a "Share ACL" generated by default every time you create a new share? It's hard to tell by using the GUI. If you click "Edit Share ACL" it presents you with an entry of "FULL ALLOWED permission for Everyone". Is it reading that as an existing entry, or is it only proposing that entry before you click save?

View attachment 43983

Like filesystems, shares always have an ACL. This is showing the default entry.

 

[winnielinnie]

Like filesystems, shares always have an ACL. This is showing the default entry.

Awesome. Thank you! So unless there's a specific need for the SMB Share to have more fine-tuned or particular permissions, it's best to leave it as is (i.e., Share ACL with full permission for everyone) and just use the dataset's ACL to restrict/permit different users that connect to the share from whatever client PCs?

 

[anodos]

Awesome. Thank you! So unless there's a specific need for the SMB Share to have more fine-tuned or particular permissions, it's best to leave it as is (i.e., Share ACL with full permission for everyone) and just use the dataset's ACL to restrict/permit different users that connect to the share from whatever client PCs?

Correct. For a typical home user, the easiest way to do this is to add a new entry for the filesystem ACL on the SMB share granting the existing group "builtin_users" FULL_CONTROL - INHERIT. Any user added through the GUI is automatically added to that group.

 

[winnielinnie]

Any user added through the GUI is automatically added to that group.

I just tested that out by creating a new user named newton, and it did not automatically add them to the "builtin_users" group. I checked the other user accounts I created in the past, and none of them are part of "builtin_users". Unless I misread your post?

Code:

# groups newton
newton
# getent group builtin_users
builtin_users:*:545
# |

 

[anodos]

works for me. User has to be an "smb" user.

Code:

root@homenas[~]# midclt call user.create '{"username": "newsmbuser", "full_name": "newsmbuser", "password": "abcd1234", "group_create": true}'
44
root@homenas[~]# getent group builtin_users
builtin_users:*:545:testuser,sofia,administrator,smbuser,alex,newsmbuser
root@homenas[~]# midclt call user.delete 44
44

 

[winnielinnie]

works for me. User has to be an "smb" user.

That's what did the trick, works for me now.

Interestingly, I wonder when this became the default? I created users back on FreeNAS 11.x, and I recall I checked the box "Samba Authentication", but they were never added to the "builtin_users" group. (Unless I enabled "Samba Authentication" after they were already created? Can't recall.)

 

[anodos]

That's what did the trick, works for me now.

Interestingly, I wonder when this became the default? I created users back on FreeNAS 11.x, and I recall I checked the box "Samba Authentication", but they were never added to the "builtin_users" group. (Unless I enabled "Samba Authentication" after they were already created? Can't recall.)

New default for new users in 12. Overall goal is to simplify setup and administration. There is also a new builtin group "builtin_administrators", and members of this group are basically super-users as far as Samba is concerned (builtin\administrators in windows parlance). They can take ownership of files, and use "Computer Management" to do various things on the server.

 

[winnielinnie]

Wanted to revisit this question again.

Like filesystems, shares always have an ACL. This is showing the default entry.

I have some SMB Shares where I unchecked "Enable ACL". According to the tooltip, this essentially deletes the ACL for the share. So now neither the share nor the dataset/path being referenced has an ACL. Yet, accessing the share from a Windows and Linux PC works exactly the same as before. What is fundamentally different in this scenario? How is it possible?

What is happening in that situation? Why is there even such an option if "shares always have an ACL"?

 

[anodos]

Wanted to revisit this question again.




View attachment 44077

I have some SMB Shares where I unchecked "Enable ACL". According to the tooltip, this essentially deletes the ACL for the share. So now neither the share nor the dataset/path being referenced has an ACL. Yet, accessing the share from a Windows and Linux PC works exactly the same as before. What is fundamentally different in this scenario? How is it possible?

What is happening in that situation? Why is there even such an option if "shares always have an ACL"?

Tooltip is wrong... I'll file a bug report about that. The checkbox disables NT ACL support (security tab in Windows), and puts us into a state where we fake up an Windows SD for internal purposes in samba based exclusively on the POSIX mode. Share access is denied if a non-trivial ACL (one that can be expressed as a POSIX mode without loss of information) is on the path, but we don't actively strip ACLs (because that's not safe).

To give a bit more detail. Suppose you have a situation where you're sharing the same dataset via NFSv3 and SMB. You want to coordinate permissions between the two of them from the client perspective. If you strip the ACL from the share, then POSIX mode gets presented to the NFS client via normal process and this accurately represents the state of permissions to the NFS client. If ACL is disabled on the SMB side, an SMB client _cant_ set something that isn't representable to the NFS client. In this case the inverse of the write bits are represented as the DOS "readonly" mode.

 

[winnielinnie]

To give a bit more detail. Suppose you have a situation where you're sharing the same dataset via NFSv3 and SMB. You want to coordinate permissions between the two of them from the client perspective. If you strip the ACL from the share, then POSIX mode gets presented to the NFS client via normal process and this accurately represents the state of permissions to the NFS client. If ACL is disabled on the SMB side, an SMB client _cant_ set something that isn't representable to the NFS client. In this case the inverse of the write bits are represented as the DOS "readonly" mode.

Thank you so much, that actually clears it up a ton! What the tooltip claimed was a real head-scratcher for me, so I'm glad it'll be fixed to reflect that it does not literally delete the ACL.