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.
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.
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.
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.
On the backup server, when I compared the Groups within the UI with the shell command net groupmap list, this is what I saw.
On the primary server, when I compared the Groups within the UI with the shell command net groupmap list, this is what I saw.
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?
My next step was to figure out what other options were available with net groupmap.
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!
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.
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.
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.
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.