Situational Deadlock in Samba 3.0.1

Esh, Andrew Andrew_Esh at adaptec.com
Mon Jan 26 14:50:57 GMT 2004


I have a repeatable test which gets an smbd process stuck in a condition where it won't ever let a client reconnect. The test reboots a host that is running Samba, and leaves a Windows client running which had been connected to the host. Afterward, the Windows client appears to have retained some connection state which Samba is unaware of, and Samba won't accept the state. Here is the log message I am seeing:

[2004/01/22 15:46:17, 2, pid=4193, effective(0, 0), real(0, 0)] smbd/uid.c:change_to_user(141)
  change_to_user: Invalid vuid used 101 or vuid not permitted access to share.

I have reviewed the code at that point, and an invalid vuid should be rejected. It is being checked against a list, which I assume is built during the run life of the smbd. Rebooting the host explains why it was cleared.

The problem is: There is does not appear to be anything which begins the process of recovering the communications state. Windows is never prompted to renegotiate, and the smbd process is not restarted. This state continues until the share is disconnected and remapped.

If I kill the smbd, the next connection from the Windows client will cause a new session to be negotiated, and the connection is restored. Since this is exactly what should have happened the first time smbd was started after the reboot, then this must be a race condition. In other words, the Windows client happens to contact the first smbd process at just the right time to decide that the communications state does NOT need to be recovered, but not late enough to actually get the right answer that it DOES need to be recovered. I am also pretty certain this is a race condition because there is another host rebooted during this test, and it does not deny the Windows client reconnection.

I was thinking of simply putting a clean exit where the log message is printed. Is there something else that would be better? Is there a flag I can set or exit value I can return to Windows which will restart the negotiation process from the beginning?

Is there anything in particular I can send to the list which will explain better what state the smbd process is in?

---
Andrew C. Esh                mail:Andrew_Esh[at]adaptec.com
Adaptec, Inc.
2905 Northwest Blvd., Suite 20        763-557-9005 (main)
Plymouth, MN 55441-2644 USA      763-551-6418 (direct)




More information about the samba-technical mailing list