TrueNAS-24.04.2 Scale
Got strange view of SMB share ACL settings. There is “unknown” in “Who*” section and some numericals ID in value.
I got human readable parameters like AD groups and AD user while ACL initial setup. But now they’re unreadable.
This typically means that we’re not properly communicating with AD.
Well. AD server located in same network (same subnet). I can see human readable names when setting up ACL. Then save settings. Open it again and get ID’s of these ACLs
I am experiencing a similar issue and I think it is causing some authentication issues when trying to connect to the shares. I am running TrueNAS Scale 24.10 and my share ACLs that include an AD domain user show the type as “Unknown”. I can change it to user, select the domain user, save, then go back into the share ACL and it shows as “unknown” again. User accounts and groups are populating properly from AD and I don’t have any errors in the join process or anything else.
In my experience this can sometimes mean an IDMAP mismatch. Is this a new server? Have you replicated data from one server to another?
PS: sorry just noticed this is Share ACLs and not filesystem ACLs correct? Out of interest why are changing the defaults?
Security purposes and best practice. Either way, trying to determine if this is just a display bug or something going wrong with how the system is supposed to operate.
Have you considered securing access via filesystem ACLs which is more common and leaving the share ACLs as default? This is how I secure access in my Enterprise?
Yes, and I do. Also some enterprises have security requirements where they need to be defined in both ACLs.
However, I am more concerned if this is a visual bug only or if there is an actual issue when it comes to an AD connection or something with resolving SIDs or something.
You can double-check what backend is returning to UI by running command midclt call sharing.smb.getacl '{"share_name": "SHARE"}' | jq
If we can resolve it internally ae_who_str will be populated.
If the SID in the ACL can’t be resolved then it will have a null value.
1 Like
The impact of an unmapped SID is minimal if you’re using ALLOWED entries. It just means someone won’t get access who probably should. But from description it may be a UI bug.
Interesting, I’ve never seen that before.
Come to think of it we use DFS and lock down who can see a given share within the namespace based on AD group membership so I guess it’s a similar idea.
If the share ACL is left to default everyone-allow then any client can technically connect to the share TCON (even if they can’t access the data in it – blocked by filesystem ACL). Setting a share ACL also can be a mechanism to limit what operations a user can perform by virtue of being a file’s owner.
1 Like