This version of Samba uses SPNego by default. This is bad, because Microosft's
implementation is different. If an NT-Based Windows user opens a Samba share
(using User Mode for Samba), and then tries to open another windows for the same
share and browse throgh it, the first window will give an error immediately. The
same goes for setup or file transfer over network, both will terminate with an
error indicating that the share no longer exists. The problem is with Samba's
SPNego. I think that Samba's SPNego is more secure, it checks for credentials
every while, but that does not suit Windows, as it closes all previous sessions
with the same Samba share.
I cannot reproduce any behavior similar to what you describe.
Please provide more details. Windows NT 4 doesn't support
Well, the problem happened with me like this:
1- I was using Mandrake Linux 10.0's Samba.
2- Three network shares were created. If you want the conf. file, I can list it.
3- While I was installing the Win32 TeX system - MikTeX - OVER NETWORK on windows
XP, the setup was interrupted with the error produced from the MikTeX
installer stating that some file cannot be opened. The same thing happened over
and over, even though the shared folder where MikTeX files are was still
seemlessly accessible "no username or password required as they are the same as
4- I tried to manipulate every setting that related to timeouts or
re-establishment of the session, but nothing changed.
5- Even more, if the setup is running - let's say - from \\pc\sh1 and I try to
open the RUN dialogue box in Windows XP or Windows 2000 and enter \\pc\sh2,
the setup stops immediately with the file not found error. The same thing
happens even if it is the same share - \\pc\sh1.
6- The only way things were back to normal is when I disabled SPNego. That's
Please attach a level 10 smbd debug log and an
ethereal trace. However, if this really is a bug
filed against Samba 3.0.2, please retest against
3.0.11 or later (the latest SAMBA_3_0 svn tree would
be good as well) to ensure you can reproduce the behavior
against the current code. 3.0.2 is really old.
closing. Fixed in current releases I expect with the rpc rewrite in 3.0.21