Share ACL confusion

[MountainMan]

I've read and experimented, but I'm still struggling to configure ACLs (filesystem and share) to accomplish what I'd like. I'm hoping someone has some insight -- or can tell me "it's not going to work because..." :)

I'll peel it back to a core example...

Given two users:

- james
- julie

And a pool named "Blackhole" with a dataset structure like:

Code:

Media
  Music
  Video
  Personal
    James
    Julie

I'd like to create two shares as follows:

• A share named "Media" for Blackhole/Media which is *only visible* to the user james, who would have full control of everything under it.
  
  
• A share named "Julie Media" for Blackhole/Media/Personal/Julie which is *only visible* to the user julie, who would have full control of everything under it.

I feel like I can get the filesystem ACL to handle/restrict things as needed (via full-control, traverse, etc for the users), but have really been struggling with the "visibility" part, which (as I understand it) is determined by the share ACLs and having "Access Based Share Enumeration" enabled(?).

So at this point my main questions are:

• Assuming share visibility is determined by share ACLs and having "Access Based Share Enumeration" enabled, that rules out share "Purposes" like "Default share parameters", yet options like "Private SMB Datasets and Shares" don't seem appropriate. What would be chosen here to start?
  
  
• As far as the Share ACLs would go, could someone share a simple example of how to limit one to be visible to a specific local Truenas user or group? I see the "Domain" note about using <netbios-name>\\smbusers but the SID note about setting it to "a Domain and Name" is a little cryptic for me and I have yet to be able to limit things.

Anyway, sorry for the length. Any thoughts, tips, etc would be appreciated!

-James (like the user ;) )

 

[anodos]

Generally speaking, don't touch the SMB share ACL unless you have _very_ specific reasons to do so and have a pretty good understanding of SMB.

If you're using the "private_datasets" preset, there will be a single share, but users will basically be chrooted into different paths depending on their username %U completion. If user path doesn't exist then new ZFS dataset will be created for them. In this case you would share "Personal" and datasets "julie" and "james will be created as users authenticate. Note lower-case. Usernames over SMB are not case-sensitive.

 

[MountainMan]

Generally speaking, don't touch the SMB share ACL unless you have _very_ specific reasons to do so and have a pretty good understanding of SMB.

Well, I seem to have demonstrated (at least to myself) that I don't have a "pretty good" understanding of share ACLs since I can't limit it to one local user. :) But they are the only way to limit the visibility of a share like "Media" to just one user correct? I can definitely use the filesystem ACLs to limit visibility and access inside the share, but would just prefer to not let others browse into an "empty" share, or be told they can't access something offered if possible.

If you're using the "private_datasets" preset, there will be a single share, but users will basically be chrooted into different paths depending on their username %U completion. If user path doesn't exist then new ZFS dataset will be created for them. In this case you would share "Personal" and datasets "julie" and "james will be created as users authenticate. Note lower-case. Usernames over SMB are not case-sensitive.

Yes, I have experimented with those a bit, and may end up having to settle with that for the Personal dataset shares. Was just trying to avoid having a personal share for myself also, since I'd have access through the upper level Media share already.

At this point I'm working with a fresh install and don't mind digging in to SMB share ACLs further to see what can be done. I see the SMB permissions overview link in your post which seems like a good place to start, unless you'd disagree? ;)

 

[MountainMan]

Well, after reading through that SMB Permissions Overview and various other links, I think I've got some answers and uncovered a couple quirks (?) along the way. So for anyone interested in the future, or anyone that sees something wrong here :) :

1) Don't test any share ACL based visibility restrictions using a user in the "Administrators Group" for Samba. They can *always* see everything, regardless of being directly denied via share ACL.

2) Since I don't want to use the "Private SMB datasets and shares" preset for some shares, the only option for adding "Access Based Share Enumeration" to the "Default share parameters" is by directly adding "access based share enum = yes" to the advanced settings for the share. Why that UI option is disabled and *locked* for that preset is still curious (and a little concerning) to me. ;)

3) When adding share ACL entries, entering a domain of "truenas" (although the info popup still says freenas?) and username will lookup and populate the SID for the user -- but I have yet to see *any* specific user based share ACL rule work. However, using direct SIDs for *groups* work every time for me. That's easy enough to work around, but does seem odd. Has anyone had luck using a user SID ?

4) You can find that user SIDs via "net usersidlist" and group SIDs via "net groupmap list" to use directly.

5) using "smbclient -L \\\\10.10.10.1 -U" (where 10.10.10.1 is the local Scale IP) to list visible shares is a good way to quickly test things without worrying about client caching, etc.

So I think I can get what I'm after with share ACLs as long as I add the share visibility option manually and stick to using group SIDs for share ACL rules for some reason. :)

 

[ip9]

thanks for that description... it really helped me figure out that "hide shares" part...
For my system the domain part (obviously truenas in your case) is my servers hostname (shortname only) (and yes, the mouse over tooltip shows freenas for me as well)

a different approach could be to add a $ at the end of the share's name - like in media$.
This will hide the share for all (Windows) clients (actually I needed to manually restart the smb service to take effect) - you can still access is via \\servername\media$

As for setting the access based enumeration thing directly in the gui - once I set "Purpose" to "No presets" I could set that option's checkbox.

 

[MountainMan]

thanks for that description... it really helped me figure out that "hide shares" part...
For my system the domain part (obviously truenas in your case) is my servers hostname (shortname only) (and yes, the mouse over tooltip shows freenas for me as well)

Yea.. for some reason my install would take either my short host name (quasar) or truenas as the domain and look up the user fine.

a different approach could be to add a $ at the end of the share's name - like in media$.
This will hide the share for all (Windows) clients (actually I needed to manually restart the smb service to take effect) - you can still access is via \\servername\media$

Interesting, I guess that's why the "IPC$" share only shows up when doing the smbclient command from the shell.

As for setting the access based enumeration thing directly in the gui - once I set "Purpose" to "No presets" I could set that option's checkbox.

Good to know! I totally missed that option above the "Default share parameters"

 

[Hakisak]

3) When adding share ACL entries, entering a domain of "truenas" (although the info popup still says freenas?) and username will lookup and populate the SID for the user -- but I have yet to see *any* specific user based share ACL rule work. However, using direct SIDs for *groups* work every time for me. That's easy enough to work around, but does seem odd. Has anyone had luck using a user SID ?

I made an account just to say "Thanks mate". after fiddling for over 6 hours your solution seemed to make everything work. I can now have private SMB's that aren't visible to eg; guest users, but only visible to users with the SID thing.

as for groups, I am not sure. But I only have a small network so its not an issue... yet.

Thanks again <3

 

[justonarnar]

Wanted to join in and say thank you for this info! Can confirm this all works on latest TrueNAS Scale (22.12).


Steps to hide a SMB share from all but listed user(s)

1. Open the SMB page > some share > Edit Share ACL
2. DELETE the default SID value
3. Domain: enter your TrueNAS hostname + domain name. eg. it might be "freenas", or "freenas.local" or something else, depending on your configuration.
4. Name: Account name in truenas that the user will connect with.
5. Set a permission, set type: Allowed
6. Save.
   1. Error? The Domain or Name probably aren't correct. Alternatively you can find the user's SID and domain name with "net usersidlist" in a shell.
7. Re-open the Edit Share ACL and make sure SID has been populated.
   1. Have the values been reset? You probably didn't delete the SID (likely S-1-1-0), which will override domain/name fields.
8. Open "Edit" dialog for the share > Advanced options > Access
9. Check "Browsable to Network Clients"
10. Check "Access Based Share Enumeration"

This should cause the share to only be LISTED if you are signed in as that user.