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 SPNEGO anyways.
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 Samba's". 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 all. Thank you, Mohammed Khallaf
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