sam_rids_to_names: possible deadlock - trying to lookup SID

[DaveF81]

Just a quick update. Seems that the Samba UNIX to Windows group mapping is broken after the upgrade. After clearing the group mappings and re-creating for my users group, this error is no longer displayed.

Obviously this isn't a recommended method and is a quick fix, so use this at your own discretion. You have been warned!

[root@freenas] ~# net groupmap list
users (S-1-5-21-3520457182-3639793677-2598286886-1001) -> users
[root@freenas] ~# net groupmap delete sid="S-1-5-21-1170145438-4009580803-3350505473-1001"
Sucessfully removed S-1-5-21-1170145438-4009580803-3350505473-1001 from the mapping db
[root@freenas] ~# net groupmap add unixgroup=users rid=1001
Successfully added group users to the mapping db as a domain group​

 

[diedrichg]

Just a quick update. Seems that the Samba UNIX to Windows group mapping is broken after the upgrade. After clearing the group mappings and re-creating for my users group, this error is no longer displayed.

Obviously this isn't a recommended method and is a quick fix, so use this at your own discretion. You have been warned!

[root@freenas] ~# net groupmap list
users (S-1-5-21-3520457182-3639793677-2598286886-1001) -> users
[root@freenas] ~# net groupmap delete sid="S-1-5-21-1170145438-4009580803-3350505473-1001"
Sucessfully removed S-1-5-21-1170145438-4009580803-3350505473-1001 from the mapping db
[root@freenas] ~# net groupmap add unixgroup=users rid=1001
Successfully added group users to the mapping db as a domain group​

Could you describe what is happening here and the possible repercussions, please.

 

[DaveF81]

Check out the Samba project documentation on 'net groupmap' .. https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/groupmapping.html

 

[diedrichg]

This issue is now preventing me from adding storage to jails. Can anyone reproduce?

 

[DaveF81]

I think you're going off on a tangent and the issue you're reporting is different. Try creating the mount point in your jail first, then map the storage. If you're still having trouble, suggest you start a new thread.

 

[diedrichg]

No. It's definitely related as I get an error stating that the storage can not be mounted because of the deadlock error.

 

[DaveF81]

Can you post your log?

Tried it myself. I don't have the mount point created in my jail, I get the error:

Jul 13 00:48:23 freenas manage.py: [middleware.exceptions:38] [MiddlewareError: The path could not be mounted /mnt/volume1/shared: Mount failed (64) -> mount: /mnt/volume1/jail/test/mnt/shared: No such file or directory ]​

I create the mount point in the jail, it maps without error. Mapping storage to jails have always been flaky at best.

 

[diedrichg]

Interesting. I did not browse the server from Windows Explorer - and therefore did not wake up CIFS. I was successful in mounting the storage for SAB.

To then test my error from last night I then browsed the server from Windows Explorer - getting the error in the log at the bottom of the screenshot - and then after attempting to set another storage point I then got the error at the top of the screen. See the attached screenshot.

 

[Robert Smith]

Hi, I am building my first production NAS from clean slate (not an upgrade), and I am also getting these errors.

I have not manually messed with ACLs at all. Nether have I manually changed any ACLs from [Windows] clients.

Are these errors safe to ignore or should I scratch the FreeNAS-9.2.1.6-RELEASE-x64 installation and try another version?

 

[DaveF81]

For me, they seem pretty save to ignore. I've not had any issues with my Samba shares as a result of this error. It's likely it will be fixed in the next version of FreeNAS as there is currently a bug open for it. See https://bugs.freenas.org/issues/5054

 

[Kuro Houou]

It's probably safe to ignore.. I would just stick with 9.2.1.5 for now though.. I am going to skip 9.2.1.6 myself. Will probably wait for 9.3 actually.

 

[JoelN]

The "deadlock" error returned pretty quickly for me as well. I too am ignoring the error and have noticed no other ill-effects.

 

[emptyBox]

So I tried to return to 9.2.1.3 recently hoping to eliminate the sam_rids problem. I didn't notice many problems at first with the issue, but at times, it started to get to the point where connections seemed to really slow down when uploading or downloading data over the network.

So plugging in the previous thumb drive with 9.2.1.3 on it, rebooted, and sam_rids followed. I still haven't loaded my original config from before I tried to upgrade to 9216 on there, but I assume that it isn't going to change much.

So for you guys did the backup and restore, any problems when you went to restore data? I have an external HDD, and was about to plug it in to my freenas box, format the external to either zfs or ufs, and either take a snapshot, or somehow back up the data to the external. I've been needing to make a backup of my data anyway, besides the snapshots that reside on my freenas (I unfortunately don't have money for a second new freenas server). My question for you guys is, going this route, when I import the data, will the Sam_rids follow again? I'm just trying to figure out if the permission issue resides on the data files, or part of the file systems, such that when I import the data back into freenas, will this permission issue return? I suppose then I need to decide which version to go back to.

Any ideas or advice appreciated.

 

[Robert Smith]

Jul 4 21:30:30 freenas winbindd[8098]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-1901708109-570851903-2486881474

Did anybody notice that the SID it is trying to look up is truncated? There probably should be a dash and a few more digits in that SID.

 

[cyberjock]

Actually, I didn't notice that.. LOL! Interesting!

 

[Robert Smith]

Just a quick update. Seems that the Samba UNIX to Windows group mapping is broken after the upgrade. After clearing the group mappings and re-creating for my users group, this error is no longer displayed.

Obviously this isn't a recommended method and is a quick fix, so use this at your own discretion. You have been warned!

[root@freenas] ~# net groupmap list
users (S-1-5-21-3520457182-3639793677-2598286886-1001) -> users
[root@freenas] ~# net groupmap delete sid="S-1-5-21-1170145438-4009580803-3350505473-1001"
Sucessfully removed S-1-5-21-1170145438-4009580803-3350505473-1001 from the mapping db
[root@freenas] ~# net groupmap add unixgroup=users rid=1001
Successfully added group users to the mapping db as a domain group​

Here is a problem with this quick fix. If you let groupmap add create new SIDs, then you are orphaning the SIDs in the file and folder permissions, as well as the primary group SID of each of the users.

If one was, on the other hand, re-creating the mappings with exactly the same SIDs, then this method no longer fixes anything; look ups are still broken.

 

[Roger Wilco]

For me, they seem pretty save to ignore. I've not had any issues with my Samba shares as a result of this error. It's likely it will be fixed in the next version of FreeNAS as there is currently a bug open for it. See https://bugs.freenas.org/issues/5054

Ran into the same issue. I have a standalone box (no AD, no LDAP, no nothing). In my comment in #5054 I've written down how to fix it permanently (for a standalone box).

If I were you I would not say "For me, they seem pretty save to ignore. ..." Imagine the situation when there is a domain user Bob Marley with a loginname bobm and a non-domain user Bob Miller with a loginname bobm. Both try to connect to a share with rw access for bobm. Do you know what will happen? I don't. But I don't care - we don't have a bobm user account here ;)

 

[Knowltey]

Is anyone anywhere with this? I'd like to know if there might be an easy solution, like deleting users and setting them back up. I'm coming from 9.2.1.3. I just don't want to lose data, and I don't particularly want to back everything up and start from scratch.

Yes, I was having the issue, just on my groups though being unresolvable from the SID and causing a deadlock. I just created new ones and went around transferring the ACL settings to the new group instead of the other one. You'll have to give them a new never before used Group ID as well as never before used name on the NAS side though for it to work properly. I noticed that when I just deleted and created again using either the old Group ID or name it still wouldn't resolve unless both were brand new.

 

[Knowltey]

Hmm, nope. It's ability to lookup its group names disappeared after a reboot.

 

[Kuro Houou]

I've decided to give 9.2.1.7 a try, will see if that has the deadlock issue that 9.2.1.6 had.. Hopefully its been resolved with the latest release. I'll let everyone know how it goes.