SOLVED Group SID resolution to friendly name fails

Joined
Jan 4, 2014
Messages
1,644
When viewing the permissions on a FreeNAS SMB share from a Windows PC, SIDs in the ACL are translated to a friendly display name. For example, this is a view of the permissions on the media share on my backup FreeNAS 11.1-U7 server.

screenshot.145.png


I've recently noticed that group SIDs are not being resolved to a Group name involving my primary FreeNAS 11.1-U7 server. It appears User SIDs are still being resolved. Here's a view of the permissions of the media share on that server.

screenshot.146.png


This is true for all SMB shares the primary FreeNAS server serves; User SID resolution is fine, but Group SID resolution fails. Something was broken, but I wasn't sure where to start looking.
 
Last edited:
Joined
Jan 4, 2014
Messages
1,644
So, this is the first step I took to isolate the issue. I knew it couldn't be a bug in FreeNAS 11.1-U7 as Group SID resolution was happening on one server, but not the other, with both servers on 11.1-U7. Could it be some corruption of the OS on a boot drive on the primary server? After all, I was using USB sticks for my boot drives and I had experienced several instances of the boot mirror degrading. I'd intended to replace the 8GB sticks I'd been using with 16GB sticks, and I hadn't been successful with in situ replacement of the sticks to date. So I decided to build a fresh copy of 11.1-U7 on a 16GB stick and restore the configuration file to it. The result... still no change. I still wasn't getting Group SID resolution with the fresh copy. At least, I was able to confirm that the OS copy wasn't corrupted. So it looks like the problem might be with some corruption of the configuration data.
 
Last edited:
Joined
Jan 4, 2014
Messages
1,644
On the backup server, when I compared the Groups within the UI with the shell command net groupmap list, this is what I saw.

screenshot.147.png
screenshot.149.png


So, I deduced from this, the net groupmap list displays all unique Groups that don't have matching entries in Users. I should expect to see something equivalent to this on the primary server.
 
Last edited:
Joined
Jan 4, 2014
Messages
1,644
On the primary server, when I compared the Groups within the UI with the shell command net groupmap list, this is what I saw.

screenshot.150.png
screenshot.151.png


The story is quite different here. The net groupmap list reveals there is an entry shirley that doesn't appear under Groups in the UI. This entry was deleted from the UI some time back. In addition, if I should only see unique Groups that do not have a matching User entry, then I shouldn't be seeing pvr or plex in the output of a net groupmap list command.

It appears there was some corruption in the groupmap. Where to from here?
 
Last edited:
Joined
Jan 4, 2014
Messages
1,644
As it's the weekend:
  1. The majority of forum members are asleep when I'm awake (I'm down under in Oz) or,
  2. Sensible forum members in my timezone are spending time with friends and family instead of being hunched over a computer terminal.
Given my impatience, I decided not to wait for the brains trust to come online, but to throw caution to the wind and proceed to try a few other things. My first stop was to figure out what other options were available with net groupmap.

screenshot.154.png


net groupmap cleanup caught my eye. I hoped that executing this command would remove the offending shirley entry and all my problems would be solved. Executing the command did the exact opposite. It removed everything else and left shirley! shirley was dug in like an Alabama tick.

screenshot.152.png


The next command I tried was net groupmap delete. I had to fossick around the net for a bit to figure out the correct syntax for this command, but once I got that, I managed to expunge shirley from the groupmap. The trouble was the groupmap was now empty.

screenshot.153.png
 
Last edited:
Joined
Jan 4, 2014
Messages
1,644
What to try next? The groups were still listed in the UI. I decided to remove the admins group, one of the unique groups, using the UI and re-add it making sure I associated the name with the same GID and taking note of which users were in the group. When I executed net groupmap list again, to my surprise all unique groups reappeared. Things were looking up.

screenshot.155.png


I did wonder whether restarting the SMB service would have achieved the same result? I was on a roll and decided to push forward.
 
Last edited:
Joined
Jan 4, 2014
Messages
1,644
My excitement was short-lived though. The group SIDs were still not being resolved when viewing the Windows ACLs. What I did notice though was that I could now check the unique group names against the server, which I previously couldn't do. Interestingly, the act of checking each of the unique group SIDs was sufficient to trigger SID resolution into friendly names for both unique group SIDs as well as non-unique group SIDs (those with group names that had matching user names in the Unix space). I didn't actually have to click OK in the dialogue box below.

screenshot.157.png


My primary server is back to resolving Group SIDs. Resolving the issue highlighted some curious and unexpected behaviour along the way. I'm guessing this arises because Windows and Unix namespaces don't mesh perfectly, and in the spaces where they don't play ball, weird things happen.

I hope the signposts I've provided will help anyone else experiencing a similar issue.
 
Last edited:

fletchowns

Cadet
Joined
Jun 25, 2020
Messages
2
Thanks so much for the detailed post. Appreciate the steps along the way as you figured it out as well, helped me learn some new things. I was facing the same issue and followed your steps. Unfortunately, I was still seeing the S-1-5-21 stuff everywhere. Fast forward a few days later, I checked the permissions again, and they still showed S-1-5-21 and then literally while I was looking at it with the window, it updated and resolved the correct username. Very strange!
 
Top