I've been having some really weird problems involving authentication from Win98 clients to Samba. A closer look has turned up some really odd behavior that I believe is a bug somewhere, either in Win98 or Samba. I am using plaintext, non-encrypted passwords, and the clients have had the appropriate registry modifications made. Multiple clients running a variety of PC hardware have had this problem. Here's my problem: One of my Samba servers will fail to authorize users when they open the server from Network Neighborhood, but only sometimes. The message given is "\\server is not accessible. No permission to access this resource". On the server side, the logs list an authentication failure for the user. Windows never presents the user with a logon dialog for them to specify their password, however. We have several other Samba servers running here, and they all exhibit the correct behavior of presenting a logon dialog, all the time. This particular server is running Redhat 6.0, Samba 2.06, but I had the problem with 2.05a as well. The other server that works fine is running 2.04. After some testing, I found that entering a share name directly (//server/username) would usually cause a share window to open. At that point, the client has been authenticated and can then access the rest of the server via Network Neighborhood. I've observed this behavior on and off for months now and today I finally got a chance to troubleshoot some more. The first problem was that the error was tough to reproduce. I managed to find a machine it was happening on, and used a packet sniffer to examine the contents of the SMB packets in more detail. I set up the two servers so that they are using identical smb.conf files, with the exception of share names. When a connection attempt (via Network Neighborhood) to the "working" server is made, the following procedure was observed. SMBnegprot Request SMBnegprot Response Followed by a series of SMBsesssetupX packet pairs. In these packets, various username/password combinations were tried. username/<no password> was tried twice, followed by username/ALLCAPSPASSWORD, followed by username/MixedCasePassword, which is correct. After that the Share requests are processed normally. So clearly, Windows knows the right password for this server. If it doesn't (for example I change it), then it asks. Now, on the problematic server, I see two pairs of SMBsesssetupX packets Right away, we have no SMBnegprot Request sent by Windows, which is odd. The contents of the two setup packets have the following username pairs - username/<nopass> and username/<ALLCAPS> . After those are rejected, no more packets are sent and Windows returns the "\\server is not accessible" error. If I enter a share name directly from the RUN box, //server/username, I still get no SMBnegprot Request but now I get more sesssetupX packets before the connection works. First username<nopass>, then username/<ALLCAPS>, then finally the correct username/<MixedCase> password. At the point the share is loaded, and since the connection has been authenticated, the user can access the entire server. So, the questions are: Why does Win98 only send SMBnegprot packets to one server and not the other? Why is it sometimes sending mixed case passwords, and other times sending all caps, depending on which method of access you used? And why is there no logon box after the authentication failures on one server, but there is on the other server? Clearly Win98 is treating the different servers differently, but why? I guess the next step would be to upgrade one of the 2.04 servers to 2.05a and then 2.06 and test, but I'm wary of causing even more problems, as these are production machines that are in use by people right now. Any insight as to what's actually going on here would be really appreciated, as this has been driving me crazy. Thanks, -Richard