Core SMB Share Access Based Share Enumeration Not Hiding Shares, Everyone Removed

[AdianIV]

I have a new TrueNAS Mini XL+ with 32GB of memory running TrueNAS-13.0-U1.1.

Problem
When accessing my TrueNAS via "\\truenas01" from a Windows 10 computer, shares to which the current user has neither share nor file permissions are visible despite Access Based Share Enumeration being enabled.

Setup
I have created two users:

1. test01
   1. Primary Group: builtin_administrators
2. test02
   1. Primary Group: builtin_users

Under the root of the pool, which is not itself shared, I created a dataset named Test03 with share type of SMB. File permissions are set to Restricted and I added the builtin_users group with the basic Modify permission. root:wheel was left as the owner of the dataset. User test01 has no file permissions to this dataset either directly or via a group.

I created a share named Test03 targeting the Test03 dataset:

The Share ACL is configured so that only the test02 account has access:

Troubleshooting
My understanding is that with the configuration above, user test01 should be able to access \\truenas01 and the Test03 share should not be presented. However:

And just as a sanity check, I evaluated the share permissions on the Test03 folder through Windows Explorer to confirm that no share permissions are present:

File permissions deny access to the share as expected.

Most of the posts that I have found are mis-configuring the share ACLs. I don't believe I'm doing that in this case. I also found reference to adding the 'hide unreadable = yes' parameter. I attempted this, even though I'd prefer not to have it configured, but still the share was visible to the test01 user.

I have noticed that despite not being configured in either share or file permissions, the Everyone user is present on all files and folders with no permissions:

When I attempt to remove this access, it is immediately re-applied.

I suspect this might be the root of my issue. If Everyone is being applied to all files and folders, despite having no permissions, SMB might consider that enough access to present the shares to members of Everyone. If true, this would effectively make Access Based Share Enumeration useless until the Everyone role is removed.

 

[anodos]

Windows caches the browse list for shares. Do you see the shares in output of smbclient -L //<server> -U <username>?

 

[AdianIV]

Yes, Test03 shows up there as well.

I'm having some issues copying all of the text out of the web shell, so instead I took a screenshot of the command and its output:

I'm not sure it matters, but this was run from the web shell of the same TrueNAS system where the shares reside.

 

[homer27081990]

Try removing the "Browsable to network clients". Perhaps it contradicts the access based enumeration because for *nix everyone is literally everyone and for Windows its \\ThisPC\Everyone. Maybe the nobody group is in everyone?

 

[AdianIV]

Try removing the "Browsable to network clients". Perhaps it contradicts the access based enumeration because for *nix everyone is literally everyone and for Windows its \\ThisPC\Everyone. Maybe the nobody group is in everyone?

Removing "browsable to network clients" did hide the share for test01. It also hid it for test02, though, which should be able to see it. My understanding is that this is the expected behavior. I don't think enumeration comes into play at all if the share isn't browsable in the first place.

Your explanation that *nix taking Everyone as literally everyone being the root cause for why SMB enumerates the share for all users makes sense to me. I would think this would have been tested when the checkbox for Access Based Share Enumeration was implemented in the UI, though. So it could still be something I've done wrong somewhere.

I saw an offhand comment in one of the threads I found before posting here (unfortunately, I have no link) that the inclusion of Everyone was an intentional design decision. I don't know how true that is or why that decision was made, and I haven't had a lot of luck finding documentation around it. It would explain why I am unable to remove it, though.

 

[Redcoat]

I saw an offhand comment in one of the threads I found before posting here (unfortunately, I have no link) that the inclusion of Everyone was an intentional design decision. I don't know how true that is or why that decision was made, and I haven't had a lot of luck finding documentation around it. It would explain why I am unable to remove it, though.

See post #2 at https://www.truenas.com/community/threads/setfacl-confusion.84118/#post-581614 for at leat one post by Sambassador @anodos adressing the topic.

 

[homer27081990]

Removing "browsable to network clients" did hide the share for test01. It also hid it for test02, though, which should be able to see it. My understanding is that this is the expected behavior. I don't think enumeration comes into play at all if the share isn't browsable in the first place.

Your explanation that *nix taking Everyone as literally everyone being the root cause for why SMB enumerates the share for all users makes sense to me. I would think this would have been tested when the checkbox for Access Based Share Enumeration was implemented in the UI, though. So it could still be something I've done wrong somewhere.

I saw an offhand comment in one of the threads I found before posting here (unfortunately, I have no link) that the inclusion of Everyone was an intentional design decision. I don't know how true that is or why that decision was made, and I haven't had a lot of luck finding documentation around it. It would explain why I am unable to remove it, though.

I think that the default way to use shares in TrueNAS is to map as a drive, anyway. If this browsing approach is mission-critical to you, then you could try a windows Group Policies, domains, and roaming profiles approach (does the mounting for you). All that, of course, without any knowledge as to the structure of your net or its users. Its up to you. From the TrueNAS and *nix side of things, I think that, well, there is only so much integration can be done. You could move the whole think to NextCloud, maybe? No need for any ACLs, windows authentication and the such then.

 

[homer27081990]

Since TrueNAS uses samba for SMB, (I don't know, though) could this be applicable here?

 

[Redcoat]

See post #2 at https://www.truenas.com/community/threads/setfacl-confusion.84118/#post-581614 for at leat one post by Sambassador @anodos addressing the topic.

There's another @anodos 'Sambassador special" here too: https://www.truenas.com/community/threads/methods-for-fine-tuning-samba-permissions.50739/

 

[AdianIV]

There's another @anodos 'Sambassador special" here too: https://www.truenas.com/community/threads/methods-for-fine-tuning-samba-permissions.50739/

Thank you very much for both of these links. The second does a good job of clearly laying out the different permission elements involved in SMB permission configuration, and I'm sure I'll be referring to it while I set up my permissions.

As for the link about the everyone@ addition, I'm clear about most of it but want to double-check my understanding.

1. The UI won't let you set an ACL without at least one inheritable ACE. This is because creating children with no permissions is generally unwanted for obvious reasons.
2. If an ACL lacks an inheritable special entry (owner@, group@, everyone@), then SMB adds entries equivalent to the default create (666) and directory (777) masks configured in smb4.conf. I assume the callout of the special entries is intentional, and an inheritable user:user1 for example wouldn't fulfill the requirement.
   1. To prevent this, an empty special entry for everyone@ is added at the share root with inheritance enabled. This is why it shows up everywhere and also why it can't be removed.

 

[AdianIV]

I think that the default way to use shares in TrueNAS is to map as a drive, anyway. If this browsing approach is mission-critical to you, then you could try a windows Group Policies, domains, and roaming profiles approach (does the mounting for you). All that, of course, without any knowledge as to the structure of your net or its users. Its up to you. From the TrueNAS and *nix side of things, I think that, well, there is only so much integration can be done. You could move the whole think to NextCloud, maybe? No need for any ACLs, windows authentication and the such then.

Thanks for the link, I'm going to look through it in more detail in the morning.

My TrueNAS setup is for fairly simple home use, so thankfully none of this is mission critical. I had been looking to configure Access Based Share Enumeration for two main reasons:

1. I come from a long background in Windows environments. There, at least in the systems I work with frequently, security trimming of libraries, folders, files, and even UI elements is commonplace. For both myself and the others that will be using this NAS, the thought process of "if I see it, I have access to it" is pretty ingrained. I figured since TrueNAS was giving me the option to configure it, I'd try.
2. I'm going to have some shares that only I will need access to for some of my jails. I figured enabling Access based enumeration for them would prevent others from always listing shares that they didn't need to care about.

Worst-case, as you said, I can just disable network browsing and directly map the shares that I need access to and nobody else does. I would still like to get this working if I can, though, especially since I see no indication anywhere that it shouldn't work.

 

[Redcoat]

but want to double-check my understanding.

Well, that's what I understand it to say, too, but I haven't any experience to confirm it. Hopefully @anodos will comment with any needed clarification.

 

[homer27081990]

Thanks for the link, I'm going to look through it in more detail in the morning.

My TrueNAS setup is for fairly simple home use, so thankfully none of this is mission critical. I had been looking to configure Access Based Share Enumeration for two main reasons:

1. I come from a long background in Windows environments. There, at least in the systems I work with frequently, security trimming of libraries, folders, files, and even UI elements is commonplace. For both myself and the others that will be using this NAS, the thought process of "if I see it, I have access to it" is pretty ingrained. I figured since TrueNAS was giving me the option to configure it, I'd try.
2. I'm going to have some shares that only I will need access to for some of my jails. I figured enabling Access based enumeration for them would prevent others from always listing shares that they didn't need to care about.

Worst-case, as you said, I can just disable network browsing and directly map the shares that I need access to and nobody else does. I would still like to get this working if I can, though, especially since I see no indication anywhere that it shouldn't work.

I think at this point, @Redcoat is right. I for one can't really be of much help

 

[Black_Duck]

I’m experiencing the same issue with TrueNAS Scale. I suspect the issue is with Samba - see this article….
Will do a little more digging.

 

[anodos]

We're fixing this issue in samba here: https://bugzilla.samba.org/show_bug.cgi?id=15266

But I already fixed for next release (shares being missing). There were actually several share enumeration bugs we've fixed in the past couple of weeks.

15265 – Access based share enum does not work in Samba 4.16+

bugzilla.samba.org

15267 – Crash during share enumeration

bugzilla.samba.org

Our fix for 15266 is slightly different than what metze is merging (we basically reverted the commit that broke it). 15266 only ever affected master (for like one day before I spotted the issue), but 15265 and 15267 affect 22.12.0.

15265 is reported in our release notes for 22.12.0. If you read them, you'll notice we even have a download link for a samba package that fixes the issue. I didn't bother creating a special package for 15267 as few users are impacted (but enough that I'm getting a steady trickle of bug reports from people who don't search before filing jira tickets :))

 

[anodos]

That said "access based shar enum" ONLY evaluates the ACL in share_info.tdb, and it _only_ evaluates whether the particular user token has READ privileges to the share.

samba/source3/rpc_server/srvsvc/srv_srvsvc_nt.c at 1fb4c3e59c494c4a6e28b5ccc2268175b126451e · truenas/samba

Contribute to truenas/samba development by creating an account on GitHub.

github.com

samba/source3/lib/sharesec.c at 1fb4c3e59c494c4a6e28b5ccc2268175b126451e · truenas/samba

Contribute to truenas/samba development by creating an account on GitHub.

github.com

And of course:

samba/libcli/security/access_check.c at 1fb4c3e59c494c4a6e28b5ccc2268175b126451e · truenas/samba

Contribute to truenas/samba development by creating an account on GitHub.

github.com

 

[Black_Duck]

Thanks andos.
Yes, I was aware that the share ACL controls visibility and had already confirmed that I had that configured correctly.
Glad to to read you guys are on top of it. Will wait patiently for 22.12.1

By the way, the Help on Domain in the Share ACL shows “freenas” when it should show “truenas“

 

[homer27081990]

That said "access based shar enum" ONLY evaluates the ACL in share_info.tdb, and it _only_ evaluates whether the particular user token has READ privileges to the share.

samba/source3/rpc_server/srvsvc/srv_srvsvc_nt.c at 1fb4c3e59c494c4a6e28b5ccc2268175b126451e · truenas/samba

Contribute to truenas/samba development by creating an account on GitHub.

github.com

samba/source3/lib/sharesec.c at 1fb4c3e59c494c4a6e28b5ccc2268175b126451e · truenas/samba

Contribute to truenas/samba development by creating an account on GitHub.

github.com

And of course:

samba/libcli/security/access_check.c at 1fb4c3e59c494c4a6e28b5ccc2268175b126451e · truenas/samba

Contribute to truenas/samba development by creating an account on GitHub.

github.com

I know I am a month late, but... You guys rock.