sam_rids_to_names: possible deadlock - trying to lookup SID

[Knowltey]

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.

No, it still does.

 

[Kuro Houou]

Oh it does? Ok well guess ill hold off then.. thanks for letting me know so quickly :) I hope this bug gets fixed when 9.3 comes out... Seems like a rather big bug, although ill admit it doesn't really hurt to much.. very annoying though.

 

[Knowltey]

Oh it does? Ok well guess ill hold off then.. thanks for letting me know so quickly :) I hope this bug gets fixed when 9.3 comes out... Seems like a rather big bug, although ill admit it doesn't really hurt to much.. very annoying though.

Honestly I'd say upgrade to 9.2.1.7. I've been quite happy with it and the bug doesn't seem to be effecting any performance. Or you could upgrade and see if you like it and revert back if needed. Just don't do any zpool upgrade until you know you want to stick around. (I don't believe the new zpool features are anything major to concern yourself over anyways)

 

[Knowltey]

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​

Thanks, this did seem to workaround the issue of not being able to search for groups in the security control interfaces in windows for me. instead of doing the deletes one by one I just ran net groupmap cleanup and then went through and manually did the net groupmap add command for each of the groups I needed to add back again. I'm assuming it's not going to survive a reboot, but I'll wait until I cross that bridge. Either way it was four groups for me and I know a quick enough workaround as to not be too bothered by the issue now.

 

[l@e]

it went up again after reboot.
users still can access the shares but under permission tab in win explorer usernames are not resolved any more.
the owner is resolved properly

please any idea where is the mistake.


previous post:
same problem
sam_rids_to_names: possible deadlock - trying to lookup SID
i think this start showing when a file or folder is copied from another device that does not have in user permission user present in the freenas user list.

i did update permission for all shares including all the contents through my windows client.

it is not showing up the problem any more and im keeping an eye on the nas monitor if it repeats.

cyberjock please notify when you have your guide ready - it will be very helpful for all of us

 

[shanky22]

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.

Issue is still here for me, after 9.2.1.7 upgrade.

 

[Knowltey]

Issue is still here for me, after 9.2.1.7 upgrade.

Well yes, that is the version that the issue is in...

The version that the patch is going to be applied to for this issue hasn't been released yet.

it went up again after reboot.

please any idea where is the mistake.

Mistake is that you rebooted. The nature of this bug is that the SID mappings do not survive through reboots. Each time you reboot until this issue is patched you will either need to manually put in the workaround, or just duel with the issue.

If you already have most of your permissions set and you just need to go in and add a certain group to something then you can always just do the workaround listed earlier in the thread on just that one specific group so that you can play around with it in the security properties interface.

---

What I did for the workaround was ran

Code:

net groupmap cleanup

(that only removes groupmaps that the system is seeing as orphaned, so anything that it grabs isn't going to be helping with anything anyways.

After that I then proceeded to run

Code:

net groupmap add unixgroup="UserGroup" rid=1010

where UserGroup would be the name of whatever group you are wanting to map and 1010 would be whatever rid you have assigned to that group. (In the FreeNAS GUI groups interface)

So you can either choose to go down your list and fix all of them if you are confident that you won't be rebooting for a while. Or you can just go in on a case by case basis and map the groups that you need to work with before going through and setting ACls for those groups.

 

[l@e]

thank you, already passed them again and till now no reboot.

I noticed smth and in don't know if its true:

even the users were not resolved the permissions were still valid, so the shares and files could be accessed only by the permitted users. so if this is only mater of naming and not affecting file security I will leave like that till the new version is released.

Well yes, that is the version that the issue is in...

The version that the patch is going to be applied to for this issue hasn't been released yet.



Mistake is that you rebooted. The nature of this bug is that the SID mappings do not survive through reboots. Each time you reboot until this issue is patched you will either need to manually put in the workaround, or just duel with the issue.

If you already have most of your permissions set and you just need to go in and add a certain group to something then you can always just do the workaround listed earlier in the thread on just that one specific group so that you can play around with it in the security properties interface.

---

What I did for the workaround was ran

Code:

net groupmap cleanup

(that only removes groupmaps that the system is seeing as orphaned, so anything that it grabs isn't going to be helping with anything anyways.

After that I then proceeded to run

Code:

net groupmap add unixgroup="UserGroup" rid=1010

where UserGroup would be the name of whatever group you are wanting to map and 1010 would be whatever rid you have assigned to that group. (In the FreeNAS GUI groups interface)

So you can either choose to go down your list and fix all of them if you are confident that you won't be rebooting for a while. Or you can just go in on a case by case basis and map the groups that you need to work with before going through and setting ACls for those groups.

 

[Kuro Houou]

So I upgraded to 9.2.1.7, haven't had the deadlock issue yet, fingers crossed! But I get a lot more errors like
STATUS=daemon 'smbd' finished starting up and ready to serve connectionscreate_connection_session_info failed: NT_STATUS_ACCESS_DENIED

I know usually that means something tried to access it and failed.. but not sure why they all started happening right after the upgrade.. not a big deal, will try to track it down when I have some time. Better then the deadlock issue at least.

 

[Knowltey]

it went up again after reboot.

please any idea where is the mistake.


/QUOTE]

Mistake is that you rebooted. The nature of this bug is that the SID mappings do not survive through reboots. Each time you reboot until this issue is patched you will either need to manually put in the workaround, or just duel with the issue.

If you already have most of your permissions set and you just need to go in and add a certain group to something then you can always just do the workaround listed earlier in the thread on just that one specific group so that you can play around with it in the security properties interface.

So I upgraded to 9.2.1.7, haven't had the deadlock issue yet, fingers crossed! But I get a lot more errors like
STATUS=daemon 'smbd' finished starting up and ready to serve connectionscreate_connection_session_info failed: NT_STATUS_ACCESS_DENIED

I know usually that means something tried to access it and failed.. but not sure why they all started happening right after the upgrade.. not a big deal, will try to track it down when I have some time. Better then the deadlock issue at least.

If you upgraded to 9.2.1.7 but haven't rebooted the server yet since the upgrade it's unlikely that you would actually encountering said issue, since those were caused by the loss of the groupmap listing that get lost upon reboot. If you are still running on the first boot since you upgraded to 9.2.1.7 the bug hasn't been reproduced on your particular instance so to speak.

Yeah, I'm trying to figure those ones out as well. I did notice that they only really seem to be occurring at the time that you start up the CIFS service (unless you are encoutering other patterns in the occurrence of those errors?)

 

[cyberjock]

I think a diff file should be made for this. :P

 

[aaronadams]

Having read this whole thread, and having just experienced this issue for the first time myself – what's the workaround? Just restart the client computer?

 

[Knowltey]

Having read this whole thread, and having just experienced this issue for the first time myself – what's the workaround? Just restart the client computer?

No, it's just that the net groupmap isn't put in properly after a reboot, the workaround is that you have to manually recreate it if it's not working properly.

I made note of how I did the workaround here: http://forums.freenas.org/index.php...trying-to-lookup-sid.21982/page-3#post-136553

If you have a lot of groups though it may be easier for you to just apply the fix to the groups you need on a case-by-case basis. It will also be all lost again if you reboot the NAS. (until the bug patch comes out in a future release)

 

[demon_devil]

I used to have the deadlock on the first time I tried to access the server from a new windows session and I would just wait a bit and then enter my credential. Now I can't even enter my credential, I just can't have access.

The workaround did not work for me. My server is rendered useless :/

 

[Knowltey]

I used to have the deadlock on the first time I tried to access the server from a new windows session and I would just wait a bit and then enter my credential. Now I can't even enter my credential, I just can't have access.

The workaround did not work for me. My server is rendered useless :/

That would be caused by a different issue somewhere then, this one does not remove any access. You probably screwed up an ACL somewhere and need to go in and fix it.

 

[demon_devil]

semi-correct. Client was misbehaving by itself. Nothing to do with ACL or the server.

 

[Ismael Duarte]

Hi!
I've done the "net groupmap cleanup" and, after that I've opened my groups one by one in GUI.
Doing "net groupmap list" all groups are back and no more error.
Could this be another way to temporary fix this bug?

 

[diedrichg]

Hi!
I've done the "net groupmap cleanup" and, after that I've opened my groups one by one in GUI.
Doing "net groupmap list" all groups are back and no more error.
Could this be another way to temporary fix this bug?

Does it persist after a reboot?

 

[Ismael Duarte]

Does it persist after a reboot?

No, the only difference is that I don't have to add groups in CLI.

Enviado do meu GT-I9001 através de Tapatalk

 

[Knowltey]

Hi!
I've done the "net groupmap cleanup" and, after that I've opened my groups one by one in GUI.
Doing "net groupmap list" all groups are back and no more error.
Could this be another way to temporary fix this bug?

Hmm, perhaps, never though of that, but perhaps when you open the group in the GUI it adds it to the groupmap list?