Confused about SMB share ACLs and browseable

[BriteLite]

So for the longest time I’ve been trying to control which group sees which share, confusingly thinking that “Access based enumeration” works on the filesystem permissions.

Only recently by mistake did i notice that share ACLs are a different entity altogether and those are what the aforementioned option works on. Or at least it should? Because it doesn’t.

So let’s take it from the top, this is what my parameters are

I have a dataset with unix permissions 770 owner root:media (a custom group i made, UID 5000). I create a smb share out of that, no preset, select " Browsable to Network Clients" and “Access Based Share Enumeration”

The media group is selected to be part of samba authentication. Now I edit the share ACLs (not filesystem ACLs!) and set them as such:

everyone@ - READ - DENIED
group - media - FULL - ALLOWED

Now, with these, i expect that this share will only appear to users who are part of the media group. But this is not the case, the share appears browseable in macos to any user, it’s just that users not in the media group cannot access it in any way

Are my assumptions just wrong, am I missing a step here or is this just not possible to achieve?

[crpb]

I would leave the “share-rights” just alone to read all.
Do proper permissions on the files if possible with ACLs.

If you don’t them(the users) to lock them each other out then don’t grant them rights which can tinkert with the owenership.

I ususally (well, with an AD/Ldap behind) only one group/share. additional admin users just in case (which won’t be using those shares intheir day-to-day work.
I could make some screenshots but not right now. Best i could give you are the getfacl outputs.

root@nas-01 /mnt/p1-25-8d-3.8t-z2/shares/di # getfacl marktplatz
# file: marktplatz
# owner: ADW\administrator
# group: ADW\grp_marktplatz
            group@:rwxpDdaARWc---:fd-----:allow
group:ADW\grp_marktplatz:rwxpDdaARWc---:fd-----:allow
user:ADW\administrator:rwxpDdaARWcCos:fd-----:allow
group:ADW\di_admins:rwxpDdaARWcCos:fd-----:allow
         everyone@:--------------:fd-----:allow

Obviously the marktplatz group are the users.

[BriteLite]

The question here isn’t about the actual ACLs on the share, but the visibility of the share itself

[awalkerix]

@BriteLite

everyone@ - READ - DENIED

• Generally you should never set denied ACEs on Everyone because they will take precedence. Not related to what you’re seeing, but for some reason we periodically have users do this.
• Clients may cache netshareenum responses and so you may not be seeing an up-to-date browse list.
• A redacted netshareenum response has zero impact on client ability to access a share.
• Share ACL is evaluated precisely once per SMB tree connection. If you’re making broad changes, make sure to restart the SMB server to force clients to make new connections.
• If you want to validate netshareenum responses cleanly then you can use rpcclient.

Sample rpcclient call (substitute relevant username to see their browse list):

root@truenas[/home/admin]# rpcclient //127.0.0.1 -U smbuser -c netshareenumall
Password for [WORKGROUP\smbuser]:
netname: IPC$
        remark: IPC Service (TrueNAS Server)
        path:   C:\tmp
        password:
netname: SHARE
        remark:
        path:   C:\mnt\dozer\SHARE
        password:

[BriteLite]

@awalkerix

Generally you should never set denied ACEs on Everyone because they will take precedence. Not related to what you’re seeing, but for some reason we periodically have users do this.

But in my case this would be what I want - correct? In the case of a share that would be browseable to only a specific group?
Edit: OH! Precedence like it would override any allow?

@awalkerix

Clients may cache netshareenum responses and so you may not be seeing an up-to-date browse list.

I was using smbclient on my end, but this is even better

@awalkerix

A redacted netshareenum response has zero impact on client ability to access a share.

Yeah, I understand that. This would be done by filesystem ACLs

Is there a command where I can query samba for the share ACL? This info is not stored in samba conf directly but in some tdb.

As I understand things should be set as such

Now, my user is not part of the homeassistant group

However, the share is still visible

So what’s wrong here? I’ve even tried putting in a specific READ DENY share ACL for the share for this user, and it still shows up

[bacon]

@BriteLite

Is there a command where I can query samba for the share ACL?

All shares:

• sudo sharesec --view-all

Specific shares:

• sudo sharesec -v NAMEOFSHARE

Also if you want to check the samba config:

• sudo testparm -s

Should have a access based share enum = Yes line on the share.

[BriteLite]

root@Quadrant[/mnt/SSD/Userhomes/movi]# sharesec -v Audiobooks 
REVISION:1
CONTROL:SR|DP
OWNER:
GROUP:
ACL:S-1-5-21-633110194-3904657170-3944594534-200128:ALLOWED/0x0/CHANGE
ACL:S-1-5-21-633110194-3904657170-3944594534-20082:DENIED/0x0/READ

[Audiobooks]
	access based share enum = Yes
	ea support = No
	path = /mnt/HDD/Media/Audiobooks
	posix locking = No
	read only = No
	smbd max xattr size = 2097152
	vfs objects = fruit streams_xattr acl_xattr zfs_core io_uring
	tn:vuid = 880e8c83-f0bd-4255-ba29-7be1bb1ecb46
	tn:path_suffix = 
	fruit:resource = stream
	fruit:metadata = stream
	fruit:time machine max size = 0
	fruit:time machine = False
	tn:home = False
	tn:purpose = NO_PRESET

Hmm, looks like it’s applied, but again, no dice

[bacon]

It worked on my end without any issues.

You do have a couple of different settings in your samba config. I presume based on your output that you have “Apple SMB2/3 protocol extension” enabled? Don’t know if that causes any changes in behaviour.

EDIT: also try restarting samba, just in case there was an error in reloading the config.

[awalkerix]

Run command net usersidlist let’s see the SIDs assigned to your users.

[awalkerix]

Oh. Your user is a member of the builtin_administrators group. That group has root-level permissions on SMB shares always. You should only do testing with non-administrator accounts, and definitely not assign out those permissions unnecessarily.

[BriteLite]

I will test it out shortly. Does the same apply to builtin_users?

@awalkerix

Run command net usersidlist let’s see the SIDs assigned to your users.

QUADRANT\movi
 S-1-5-21-633110194-3904657170-3944594534-20082
 S-1-1-0
 S-1-5-2
 S-1-5-11
QUADRANT\goose
 S-1-5-21-633110194-3904657170-3944594534-20083
 S-1-1-0
 S-1-5-2
 S-1-5-11
QUADRANT\hass
 S-1-5-21-633110194-3904657170-3944594534-20085
 S-1-1-0
 S-1-5-2
 S-1-5-11
QUADRANT\coreelec
 S-1-5-21-633110194-3904657170-3944594534-20086
 S-1-1-0
 S-1-5-2
 S-1-5-11

Btw I just found a bug in the UI - disabling a share from the sharelist does nothing, it goes back to enabled after a UI refresh. And disabling from the share properties sticks, but also doesn’t work from the samba side, testparm still has the share

[bacon]

@BriteLite

Btw I just found a bug in the UI - disabling a share from the sharelist does nothing, it goes back to enabled after a UI refresh.

That bug should be fixed in next release (24.10.1):
https://ixsystems.atlassian.net/browse/NAS-132227

[awalkerix]

@BriteLite

Does the same apply to builtin_users?

No. Users are users, not administrators.

[BriteLite]

Thanks, after adjusting my user it seems to work perfectly. Mystery solved