Samba Access Based Share Enumeration issue

Hello, I am in the process of migrating from Core to Scale. On my Core in production I have a pool, datasets (with NFSv4 ACLs) and Samba shares (but no NFS shares) with users from a Samba AD.
I replicated the datasets from Core to Scale without problem and added Samba shares on the Scale side to test.
Sharing and ACL restrictions work except for one detail: on the Core, users do not see the directories to which they do not have access, which is practical; on the Scale, all directories appear regardless of the rights (by clicking on the directory you have a denial access but that is not user-friendly).
Option Access Based Share Enumeration is checked.

Here is the config on Core:

[data]
        ea support = No
        kernel share modes = No
        path = /mnt/vol1/xxxx/data 
        posix locking = No
        read only = No
        smbd max xattr size = 2097152 
        vfs objects = streams_xattr shadow_copy_zfs ixnas zfs_core aio_fbsd full_audit
        nfs4:chown = true
        ixnas:dosattrib_xattr = false

root@yyyy:/mnt/vol1/xxxx # getfacl data
 file: data
 owner: nasadmin
 group: nasadmin
     user:nasadmin:rwxpDdaARWcCo-:fd-----:allow
            owner@:rwxpDdaARWcCo-:fdi----:allow
    group:nasadmin:rwxpDdaARWcCo-:fd-----:allow
            group@:rwxpDdaARWcCo-:fdi----:allow
         everyone@:r-x---a-R-c---:f------:allow

Here is the config on Scale:

[data]
        access based share enum = Yes
        ea support = No
        kernel oplocks = Yes
        path = /mnt/vol1/xxxx/data
        smbd max xattr size = 2097152
        vfs objects = truenas_audit streams_xattr shadow_copy_zfs ixnas zfs_core io_uring
        tn:path_suffix = 
        tn:purpose = MULTI_PROTOCOL_NFS
        tn:vuid = f1526360-07bf-4481-bbda-664b7219cbd5
        fruit:time machine max size = 0
        fruit:time machine = False
        tn:home = False
        nfs4:chown = True

root@zzzz[/mnt/vol1/xxxx]# nfs4xdr_getfacl data
 File: data
 owner: 999
 group: 999
 mode: 0o40775
 trivial_acl: false
 ACL flags: auto-inherit:
      user:netdata:rwxpDdaARWcCo-:fd-----:allow
            owner@:rwxpDdaARWcCo-:fdi----:allow
      group:docker:rwxpDdaARWcCo-:fd-----:allow
            group@:rwxpDdaARWcCo-:fdi----:allow
         everyone@:r-x---a-R-c---:f------:allow

I read that there is a link with the Everyone ACL on the share link, I checked and it is the same on both servers: Everyone, Full, Allowed

Or it is the zfs ACL but It is the same on both servers as the dataset is replicated, so why Core server shows only reachable folders and Scale shows all folders ?

The option “Access Based Share Enumeration” only affects visibility of the share during share enumeration. It does not affect visibility of files or folders within the share.

There is a samba option called “hide unreadable” which is more akin what you are describing. But it does come with a negative performance impact. It’s not user friendly when users try to create files or folders that already exist but they can’t see. As far as I can tell it’s not possible to set this option in TrueNAS Scale.

I don’t know about the samba differences between core and scale. In general, having to evaluate ACL during directory listing does slow things down.

2 Likes

One more note: The “Access Based Share Enumeration” is based on the Share ACL which is separate from the Filesystem ACL. If you want to hide individual shares you can do this with the “Edit Share ACL” button on the Shares screen.

You’re right I misread documentation, access based share enum is only used to display the share to users. I parsed all the parameters from man smb.conf and indeed the hide unreadable is the needed parameter.

By the way I don’t understand why the Additional Parameters String box in Advanced Options on the shares is always non-editable, whatever is the chosen preset… As shares definitions are stored in the registry I tried this:
# net conf setparm myshare "hide unreadable" Yes
and indeed it works as expected, I only see directories which I have access to.

Your remark is correct about users unable to create an already existing and hidden directory but it does not apply there. We have on the first level of the dataset about 40 first level directories. Each one has ACL to limit access to groups and nobody can write in the root of the share. Usually people see only a dozen of directories based on their groups (since many years). If I change that and 40 directories appears, with many unreachable, it will not be accepted :frowning:

What I really don’t understand is that this parameter is set to No on the Truenas Core and it behaves as if it were set to Yes !

I suppose I have to find a way to automate the net conf call either on configuration change or server reboot…

I think I found the answer there: Reddit - Dive into anything

You can use the CLI using midclt command. Example: midclt call sharing.smb.query | jq to show all the Samba shares and midclt call sharing.smb.update ‘{“auxsmbconf”: “”}’ for changing it. Where ID is the ID of the share and the "” replaced with hide unreadable = yes. So for example midclt call sharing.smb.update 4 ‘{“auxsmbconf”: “hide unreadable = yes”}’ .

And I agree with this opinion:

For users it is really annoying if they see a lot of directories but only can access a few and if they click a wrong directory that a message will popup in Windows. I hope the team of Truenas will make this option available through the GUI somedays.

This may be of interest Difference in SMB Share Behaviour Between CORE and SCALE - #30 by Johnny_Fartpants

1 Like