Situational Deadlock in Samba 3.0.1

[Esh, Andrew]

Remember, the Windows client was left running, so it still thinks it has
a good connection, up to a point. I haven't looked into this too far
yet, so I haven't seen exactly what Windows is doing, but certainly
still has the share mapped through the host reboot.

I am working on the repro and collecting the information.

-----Original Message-----
From: vlendec at SerNet.DE [mailto:vlendec at SerNet.DE]On Behalf Of
Volker.Lendecke at SerNet.DE
Sent: Monday, January 26, 2004 10:25 AM
To: Esh, Andrew
Cc: samba-technical at lists.samba.org
Subject: Re: Situational Deadlock in Samba 3.0.1


On Mon, Jan 26, 2004 at 06:50:57AM -0800, Esh, Andrew wrote:
> 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.

This happens upon a Tree Connect? A tcon without a session setup before?

It sounds a bit strange that a Windows machine will set up a fresh tcp
connection and *not* do a normal smb session setup including negprot,
sesssetup
and tcon in that order.

What we would need is a complete debug level 10 log.smbd and a capture
of the
traffic between the windows machine and the Samba machine. The complete
traffic
might be important, as something in the way the former connection was
turned
down (or not properly turned down) might trigger that behaviour.

Volker