SOLVED SMB Access Based Enumeration SCALE 22.02

[Jadan1213]

Not sure if it's broken or i'm doing something wrong, but it appears that access based enumeration isn't working properly. I'm running TrueNAS-SCALE-22.02-RC.1-2.

Even with the option toggled ON, the directories in which a user does NOT have read access are still showing up in the directory listing.

 

[morganL]

I'd suggest documenting the ACLs you have set-up.. are you using NFSv4 ACLs

In general, if you want to hide the specific directories using access based enumeration, its recommended to make them explicit datasets and shares. Does that approach resolve your issues?

See: https://www.truenas.com/community/threads/smb-sharing-sub-folder-with-traverse.51427/

 

[Jadan1213]

I should have mentioned, I'm coming from CORE. All my permissions and the Access enumeration worked perfectly on CORE.

With the 'upgrade' I needed to go over all the permissions to get them working right. I have also tried using the new nfs4 acls (which admittedly i'm not familiar with), and am currently using basic POSIX permissions seeing as I don't really 'NEED' granular control of the permissions on any of my current datasets.

I am currently only hosting a single SMB share which is all that i need, and I mean no disrespect, but I don't feel splitting up the share into many shares is a viable answer. I do not want multiple shares, only a single share at the root of my pool (datastor). I have multiple docker containers that connect to the base pool over SMB and have access to multiple folder locations with different levels of permissions. This functionality worked perfectly in CORE but seems not to be working in SCALE. It's not a deal breaker if it's not working, but I do like the feature.

If there's an issue in how it's configured, I would love some assistance in correcting it, however I'm not sure it's an error on my part. I have toggled the access based enumeration checkbox, as well as tried putting 'access based share enum = yes' in the additional paramaters field.

 

[anodos]

I should have mentioned, I'm coming from CORE. All my permissions and the Access enumeration worked perfectly on CORE.

With the 'upgrade' I needed to go over all the permissions to get them working right. I have also tried using the new nfs4 acls (which admittedly i'm not familiar with), and am currently using basic POSIX permissions seeing as I don't really 'NEED' granular control of the permissions on any of my current datasets.

I am currently only hosting a single SMB share which is all that i need, and I mean no disrespect, but I don't feel splitting up the share into many shares is a viable answer. I do not want multiple shares, only a single share at the root of my pool (datastor). I have multiple docker containers that connect to the base pool over SMB and have access to multiple folder locations with different levels of permissions. This functionality worked perfectly in CORE but seems not to be working in SCALE. It's not a deal breaker if it's not working, but I do like the feature.

If there's an issue in how it's configured, I would love some assistance in correcting it, however I'm not sure it's an error on my part. I have toggled the access based enumeration checkbox, as well as tried putting 'access based share enum = yes' in the additional paramaters field.

Access based share enumeration is based on the SMB share ACL, not the filesystem permissions. These are stored in a tdb file (share_info.tdb) and are keyed based on the SID of the object (either user or group). Generally speaking, it's better to use groups for these things.

Generally speaking, it's not a good idea to share out your ix-applications dataset via SMB (which is what happens potentially if you set the SMB share to be the root of zpool).

 

[Jadan1213]

Access based share enumeration is based on the SMB share ACL, not the filesystem permissions.

In that case, would it be irrelevant as to POSIX or nfs4 on the ACLs? How would I access/enable/change the SMB ACL for the share in core? IIRC, in CORE, available SMB folders were updated immediately upon changing of the dataset/folder ACLs.

Generally speaking, it's not a good idea to share out your ix-applications dataset via SMB (which is what happens potentially if you set the SMB share to be the root of zpool).

an understandable precaution, however I am running this in a homelab environment and I am also using the 'veto files = /ix_applications/' option to remove that directory from the listing entirely.

also, i have noticed that some changes are requiring me to stop and start the SMB service before they take effect (such as enabling veto files). I don't recall if that was required on CORE as well.

 

[anodos]

In that case, would it be irrelevant as to POSIX or nfs4 on the ACLs? How would I access/enable/change the SMB ACL for the share in core? If IIRC, in CORE, available SMB folders were updated immediately upon changing of the dataset/folder ACLs.

Filesystem ACL type is irrelevant for access-based share enumeration. SMB share ACL is stored in /var/db/system/samba4/share_info.tdb. There's an "edit share ACL" button for SMB shares (as opposed to "edit filesystem ACL").

 

[anodos]

also, i have noticed that some changes are requiring me to stop and start the SMB service before they take effect (such as enabling veto files). I don't recall if that was required on CORE as well.

That's the way it always is in Samba. If you make changes and wish to see them reflected in current SMB sessions you may need to send message to reload config (or restart SMB server).

Generally speaking, if changes are made to services->SMB, then we restart the SMB server to make sure global changes applied to all sessions. If changes are made at share level, we don't restart. This is because this aspect of our product is generally geared for business / enterprise use-case where service interruptions should be avoid if at all possible.

 

[Jadan1213]

There's an "edit share ACL" button for SMB shares (as opposed to "edit filesystem ACL").

I found the setting for that, However I do believe in CORE, I had the SMB ACL set to allow everyone. I never put any restrictions based on the SMB ACL. I would have to spin up another CORE installation to verify this, but I'm fairly certain that the only things I ever changed, to which the shown smb folders would change as well, was the file system ACL permissions.

I do have all the datasets configured as nfsv4 (inherited from pool root). But changing to POSIX and back hasn't made any difference.

I think what I'll do is set up a VM using CORE and compare. I'm fairly sure that it should function the way I'm attempting. I'll get back to you.

 

[anodos]

I found the setting for that, However I do believe in CORE, I had the SMB ACL set to allow everyone. I never put any restrictions based on the SMB ACL. I would have to spin up another CORE installation to verify this, but I'm fairly certain that the only things I ever changed, to which the shown smb folders would change as well, was the file system ACL permissions.

I do have all the datasets configured as nfsv4 (inherited from pool root). But changing to POSIX and back hasn't made any difference.

I think what I'll do is set up a VM using CORE and compare. I'm fairly sure that it should function the way I'm attempting. I'll get back to you.

Access Based Share Enumeration only alters the response to NetShareEnum RPC on the SMB server's IPC$ share. It isn't related to whether files appear in shares.

By default the SHARE ACL is wide-open S-1-1-0/FULL. This means that access is determined by filesystem permissions, which are enforced by kernel, and cannot be avoided.

 

[Jadan1213]

Okay, I'm not sure how it was working in my original configuration, at one point I do know that I had multiple shares and then combined them into one, maybe that made a difference. But I've been toying around and discovered that to get the function I want, I need to add 'hide unreadable = yes' into the share's auxiliary parameters.

This confuses me quite a bit, because I'm fairly certain I didn't have that option applied prior to upgrading to SCALE. It's entirely possible that I have the memory of a hamster...

I have it working how I want now, and I have learned a little bit thanks to your help. I appreciate your time.

 

[rayzer]

Thank you very much for this feedback! I've been trying to get this to work for 16 hours without success (ABE), until I found your answer. I did several searches, this is the first one I found citing this parameter.
Basically hide unreadable = yes reproduces the behavior I would like to have with ABE. I can have a single share with multiple subfolders and each of them hidden from users who don't have access. This was the behavior I would have with ABE on Windows Server. Thanks!


And thank you anodos for explaining how ABE works with Share ACL.