SMB User Share Issues

TrueNAS General
1

I’ve consistently run into problems with SMB shares authenticating against active directory since installing TrueNAS over a year ago. It was working ok on Cobia and I recently switched trains to Dragonfish on my main NAS and adding users / changing users / doing anything in the GUI that references users is broken. Here’s a screenshot of one of my shares. As you can see the SID populates correctly but it doesn’t know that it’s a user. If I select user, it will figure out the UID and allow it in the user box (but not username) but when saved, it isn’t sticky. Selecting the share acl again looks exactly like the screenshot.

Screenshot from 2024-06-10 10-54-27
Screenshot from 2024-06-10 10-54-27860×1476 69.6 KB

All of the command line tools seem to work correctly. The AD bind is correct (although because of the number of user objects I need to turn off caching as building the cache never succeeds, another thing that is annoying).

Any suggestions? I have to make changes to this share and I currently cannot. And since I can’t just edit a config file the non-functionality of the interface in this regard is causing issues.

2

There was a time (maybe imagined) that I could put a username into the username search box and click save and it would look it up. That behavior no longer occurs. There is absolutely no way to add or change ACLs the way it sits now.

3

Is your AD bind healthy? Failure to resolve SIDs like this usually means we can’t communicate with AD. Are these local users or AD users?

4 
root@nas1[/home/admin]# wbinfo -u | wc
  53422   53422  588246

root@nas1[/home/admin]# wbinfo -i dstephans
dstephans:*:100266828:100000514::/var/empty:/bin/sh

root@nas1[/home/admin]# wbinfo -U 100266828
S-1-5-21-1489318479-843726199-1338259680-266827

Demonstrating the command line tools work.

5

yes, it shows healthy in the interface and as stated in the original post the command line tools have no problems.

6

Screenshot from 2024-06-10 11-17-33
Screenshot from 2024-06-10 11-17-33848×482 23.5 KB

If I select User it will populate the username field as shown in the screenshot with the UID. If I do that for all users on the share it will allow me to save it. As stated in the original post if I revisit the ACL after saving, it looks like the screenshot in the original post.

7

Note that this is for existing users on the share. I cannot add new ones because the User field never populates and will not “stick” with a manual entry.

8

What is output of midclt call idmap.convert_sids '["S-1-5-21-1489318479-843726199-1338259680-266827"]' | jq

9 
root@nas1[/home/admin]# midclt call idmap.convert_sids '["S-1-5-21-1489318479-843726199-1338259680-266827"]' | jq 
{
  "mapped": {
    "S-1-5-21-1489318479-843726199-1338259680-266827": {
      "id_type": "BOTH",
      "id": 100266828,
      "name": "ADS\\dstephans"
    }
  },
  "unmapped": {}
}
10

What is output of:

midclt call sharing.smb.getacl '{"share_name": <your share>}'
11 
root@nas1[/home/admin]# midclt call sharing.smb.getacl '{"share_name": "LIBRARY VIDEO ARCHIVE"}'
{"share_name": "LIBRARY VIDEO ARCHIVE", "share_acl": [{"ae_who_sid": "S-1-5-21-1489318479-843726199-1338259680-34123", "ae_type": "ALLOWED", "ae_perm": "FULL", "ae_who_id": {"id_type": "BOTH", "id": 100034124}, "ae_who_str": "mepstein"}, {"ae_who_sid": "S-1-5-21-1489318479-843726199-1338259680-105652", "ae_type": "ALLOWED", "ae_perm": "FULL", "ae_who_id": {"id_type": "BOTH", "id": 100105653}, "ae_who_str": "cpeterson"}, {"ae_who_sid": "S-1-5-21-1489318479-843726199-1338259680-266827", "ae_type": "ALLOWED", "ae_perm": "FULL", "ae_who_id": {"id_type": "BOTH", "id": 100266828}, "ae_who_str": "dstephans"}, {"ae_who_sid": "S-1-5-21-1489318479-843726199-1338259680-266937", "ae_type": "ALLOWED", "ae_perm": "FULL", "ae_who_id": {"id_type": "BOTH", "id": 100266938}, "ae_who_str": "msamudio"}, {"ae_who_sid": "S-1-5-21-1489318479-843726199-1338259680-304115", "ae_type": "ALLOWED", "ae_perm": "FULL", "ae_who_id": {"id_type": "BOTH", "id": 100304116}, "ae_who_str": "kbrooks"}]}

So it looks like the middleware client is working correctly as well. If there’s a way I can add users and change perms using midclt I’m happy to do it that way as well. However the interface isn’t working.

12

I’m trying to isolate whether this is a backend or UI issue.

13

We have in the backend a 5 second timeout on trying to use NSS to look up names based on Unix IDs (which gets performed separately from the bulk SID conversion). So the names may get omitted if DC isn’t particularly responsive. Slow DC responses would also possibly be root cause of cache fill taking forever.

We’re using NSS because some users opt to use the use_default_domain winbind option and we want to present the expected username rather than simply the AD username.

14

For large AD environments, enumeration (and UI cache) should be disabled (there is a checkbox for disabling the caching in the UI).

In UI fields where you would normally use a dropdown, you can manually type in the username or groupname.

How long does it take for getent passwd 100304116 to return? You may want to compare cached vs uncached. If it takes significant lengths of time to return then you may want to investigate ways to improve performance of communication with DCs (or significantly increasing cache lifetimes in winbind).

15 
root@nas1[/home/admin]# time getent passwd 100304116
kbrooks:*:100304116:100000514::/var/empty:/bin/sh
getent passwd 100304116  0.00s user 0.01s system 74% cpu 0.007 total

Extremely fast.

I have cache turned off (stated above). It doesn’t even successfully build the cache so there’s no point.

Also as I mentioned above I cannot just type the name in. I created a new share as a test and tried to change the ACL and I manually type the username (or the uid) into the User field and when I hover over the Save button I get the crossed “o” and I cannot save it. Something is not right.

16

Screenshot from 2024-06-10 14-04-16
Screenshot from 2024-06-10 14-04-16854×1438 53.2 KB

17

The above screenshot gives me the crossed out circle when I try to save.

18

Okay. That looks like a UI bug since the backend is returning expected values and performance seems normal. Please file a bug ticket in our jira.

19

midclt is simply a shell-based middleware client that can be used to call directly into our documented APIs.

sharing.smb.setacl is as follows:

    @accepts(Dict(
        'smb_share_acl',
        Str('share_name', required=True),
        List('share_acl', items=[
            Dict(
                'aclentry',
                SID('ae_who_sid', default=None),
                Dict(
                    'ae_who_id',
                    Str('id_type', enum=['USER', 'GROUP', 'BOTH']),
                    Int('id')
                ),
                Str('ae_perm', enum=['FULL', 'CHANGE', 'READ'], required=True),
                Str('ae_type', enum=['ALLOWED', 'DENIED'], required=True)
            ),
        ], default=[{'ae_who_sid': 'S-1-1-0', 'ae_perm': 'FULL', 'ae_type': 'ALLOWED'}]),
        register=True
    ), roles=['SHARING_SMB_WRITE'])
    @returns(Ref('smb_share_acl'))
    async def setacl(self, data):
        """
        Set an ACL on `share_name`. This only impacts access through the SMB protocol.
        Either ae_who_sid, ae_who_id must, ae_who_str be specified for each ACL entry in the
        share_acl. If multiple are specified, preference is in the following order: SID,
        unix id, name.

        `share_name` the name of the share

        `share_acl` a list of ACL entries (dictionaries) with the following keys:

        `ae_who_sid` who the ACL entry applies to expressed as a Windows SID

        `ae_who_id` Unix ID information for user or group to which the ACL entry applies.

        `ae_perm` string representation of the permissions granted to the user or group.
        FULL - grants read, write, execute, delete, write acl, and change owner.
        CHANGE - grants read, write, execute, and delete.
        READ - grants read and execute.

        `ae_type` can be ALLOWED or DENIED.
        """

As with any case with managing things in AD, you should ideally be granting rights to groups rather than individual users. Entire share ACL must be submitted in one go.

midclt call sharing.smb.setacl '{"share_name": "my share", "share_acl": [{"ae_who_id": {"id_type": "GROUP", "id": 8675309}, "ae_perm": "FULL", "ae_type": "ALLOWED"}, ...]}'