We like to mount a cifs share from a NetApp Filer (NetApp Release 7.2.3: Thu Jul 5 09:51:46 PDT 2007) from a SUSE Linux SLES 10.2. The mount command: mount -t cifs //filesrv/institut_share /mnt -o username=r31danre,domain=rzall,uid=r31danre,gid=ntp,file_mode=0770,dir_mode=0770 The mount works well and the File access works well too. But if I want to move one file out of the cifs share to the local Directory the mv command chrashes and stucks. A copy cp and a remove rm works well. mv /mnt/datei /tmp In var/log/messes: … Sep 3 15:38:05 applxsrv kernel: CIFS VFS: Bad protocol string signature header 4 Sep 3 15:38:05 applxsrv kernel: CIFS VFS: bad smb detected. The Mid=13 Sep 3 15:38:05 applxsrv kernel: Bad SMB: : dump of 48 bytes of data at 0xffff8105c8581540 Sep 3 15:38:05 applxsrv kernel: 00000040 00000004 00000032 80018800 @ . . . . . . . 2 . . . . . . . Sep 3 15:38:05 applxsrv kernel: 00000000 00000000 00000000 58b40040 . . . . . . . . . . . . @ . ´ X Sep 3 15:38:05 applxsrv kernel: 000d0800 0400020a 02000000 00003800 . . . . . . . . . . . . . 8 . . Sep 3 15:38:27 applxsrv kernel: CIFS VFS: server not responding Sep 3 15:38:27 applxsrv kernel: CIFS VFS: No response for cmd 50 mid 13 Sep 3 15:38:33 applxsrv kernel: CIFS VFS: Bad protocol string signature header 4 Sep 3 15:38:33 applxsrv kernel: CIFS VFS: bad smb detected. The Mid=17 Sep 3 15:38:33 applxsrv kernel: Bad SMB: : dump of 48 bytes of data at 0xffff8105c8581a80 Sep 3 15:38:33 applxsrv kernel: 00000040 00000004 00000032 80018800 @ . . . . . . . 2 . . . . . . . Sep 3 15:38:33 applxsrv kernel: 00000000 00000000 00000000 58b40040 . . . . . . . . . . . . @ . ´ X Sep 3 15:38:33 applxsrv kernel: 00110800 0400020a 02000000 00003800 . . . . . . . . . . . . . 8 . . Sep 3 15:38:57 applxsrv kernel: CIFS VFS: server not responding Sep 3 15:38:57 applxsrv kernel: CIFS VFS: No response for cmd 50 mid 17 … uname –a Linux applxsrv 2.6.16.60-0.27-smp #1 SMP Mon Jul 28 12:55:32 UTC 2008 x86_64 x86_64 x86_64 GNU/Linux mount.cifs -V mount.cifs version: 1.10-3.0.28-0.6-1787-SUSE-CODE10
Created attachment 3542 [details] Wire Shark trace of the mount and the mv command Filer IP= 137.193.14.36 Client IP= 137.193.7.22 Commands during the trace: mount -t cifs //filesrv/evntfs /mnt -o username=r31danre,domain=rzall,uid=r31danre,gid=ntp,file_mode=0770,dir_mode=0700 mv /mnt/zz1 /tmp
Created attachment 3646 [details] tcp dump while the mv command works Output of: tcpdump -w /tmp/filer.tcpdump -v -s 255 host <filer>
Created attachment 3647 [details] strace during the mv command Output of strace -fro /tmp/mv_cifs.strace mv /mnt/datei /tmp
The tcpdump does not reveal much. Can you please retry with -s 0 this time? Also, is it possible clear syslog buffer (dmesg -c) and then obtain cifs debug information by turing on echo 7 > /proc/fs/cifs/cifsFYI echoi 1 > /proc/fs/cifs/traceSMB trying the mv command and as soon as you encounter the problem, capture the syslog buffer (dmesg > <file_name>) and send that data along with tcpdump? I am not able to make anything out of the SMB dumped by cifs (I do not see SMB header) but I think cifs was expecting a response, received a malformed response and logged the error and now is complaining that the (expected) response not received and that is why server is not responding.
Your trace shows what looks like a server or network hardware bug - see frame 166 (which is an SMB Transact2 Query Path Info, requesting level 4 Query All Extended Attributes) and then the retry on frame 238 - in both cases the server fails to respond. Note that the server claims to be Windows 2000 (which seems unlikely) - see frame 90, but this may indicate an older server, claiming to be Windows 2000, but this might mean that updates are available for the server if 9 years old. Same bug in the other trace (tcpdump trace) see frames 8 and 24. Note that in both traces there is a corrupt frame that the server sends the client (wireshark labels it "NBSS Session Message" because it is missing the SMB header and is malformed) which immediately follows the SMB Transact2 Query Path Info request. Check with your server vendor for updates, but there may be a way to workaround this (since the server fails on the request to read extended attributes) if your version of the "mv" command has a way to disabling querying for acls or extended attributes
No response for quite a while, and traces show what looks like a server bug