[linux-cifs-client] Re: CIFS bug

[Steven French]

> but the cifs module still is not able to copy large files (several
hundred Mo) from my linux
> box to a W2K3 server.  I have no problems to transfert "small" files.


Your log shows the tcp session died to the Windows 2003 server during the
copy, and reconnection failed.   A theory I had been pursuing for an
unrelated problem earlier was that in 2.6  the demultiplex thread which
handles the receives & demultiplexing of the tcp data from the server may
get hung (forever) in the Linux tcp stack  (it should timeout within a few
seconds and reconnect based on the socket options I set), but a more likely
theory based on the error in SessionSetup that was reported in the log (and
the lack of a reported error on the preceding frame - the SMB
NegotiateProtocol requeest) is that the password or user or domain
information that I am using to reconnect your session is incorrect since
these are the only interesting pieces of information that I send on the SMB
Session Setup request and they are sent from data saved in the cifs session
structure (which /proc/fs/cifs/DebugData will partially dump out).   After
those failed reconnection attempts the write operations themselves failed
which would be expected depending on the hard vs. soft mount option you
chose at mount time.   You can look at /proc/fs/cifs/DebugData to see if
the Tcp Session is connected but the SMB Session is not or vice versa.   I
would expect that /proc/fs/cifs/DebugData would show a valid tcp session
(which was succesfully reconnected by the corresponding "cifsd" kernel
thread - you should check that that thread still exists and is running) but
the smb session in disconnected state.     The rc = 5 is presumably access
denied (I will need to check when I get back to a computer with the source
tree installed).    I will try some experiments when I get back with
Windows 2003 reconnection but the thing to look for in the network trace
(or if the /proc/fs/cifs parm is enabled to trace cifs packets to the
kernel log) are are that the userid & domain on the SMBSessionSetup during
reconnection match the ones sent during the initial mount.    Checking that
the NTLM password hash matches is not easy to do but if the userid & domain
match on the two sessionsetups and one fails - that leaves the less likely
problem of an incorrectly saved NTLM password hash unless an obscure
problem with cifs packet signing (which should not be an issue until the
frame after SessionSetup completes so I discount that theory).

I don't have access to a Windows 2003 system here but I can try on Monday
to see if this can be artificially generated e.g. by dropping the a cifs
vfs mounted session to Windows 2003 by going to the server and doing "net
session \\a.b.c.d /delete"   (where a.b.c.d is your workstations ip
address) and then retrying some cifs vfs operation such as ls or stat of
the mounted directory from the client.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-------------- next part --------------
HTML attachment scrubbed and removed