Bug 9477 - CIFS VFS: Unexpected SMB signature, NULL inode in lookup
Summary: CIFS VFS: Unexpected SMB signature, NULL inode in lookup
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 2.6
Hardware: x86 Linux
: P5 critical
Target Milestone: ---
Assignee: Steve French
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-07 14:16 UTC by serge.conrad
Modified: 2014-02-27 20:00 UTC (History)
0 users

See Also:


Attachments
transfer.c for kernel 3.2 (23.99 KB, text/plain)
2014-02-27 19:56 UTC, Mayk
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description serge.conrad 2012-12-07 14:16:10 UTC
Hi,

The log are from 2.6.43.8-1.fc15.x86_64.
I see also the error CIFS VFS: Unexpected SMB signature with the same environnement on a 3.6.6-1.fc16.x86_64

I have a problem with users losing their connections from linux clients with cifs share. (Windows 2008) :CIFS VFS: Unexpected SMB signature
I am using two methods for mounting: pam_mount and autofs, both with same results.

I am using mount options nounix,noserverino

I am lauching cifs module on boot (rc.local) with
modprobe cifs
echo 0 > /proc/fs/cifs/OplockEnabled
echo 1 > /proc/fs/cifs/MultiuserMount
echo 7 > /proc/fs/cifs/cifsFYI

What happens :
in /var/log/messages
=====================
Dec 3 17:31:01 u1205-08l kernel: [ 3732.140040] CIFS VFS: Unexpected lookup error -512
Dec 3 17:31:01 u1205-08l kernel: [ 3732.334939] CIFS VFS: Unexpected SMB signature

This user was working since one hour with no problem :
Daemon log :
=============
Dec 3 16:29:35 u1205-08l cifs.upcall: key description: cifs.spnego;0;0;3f000000
;ver=0x2;host=figue;ip4=130.xxx.xxx.xxx;sec=krb5;uid=0x1000005;creduid=0x1000005;us
er=21206xxx;pid=0x65f
Dec 3 16:29:35 u1205-08l cifs.upcall: ver=2
Dec 3 16:29:35 u1205-08l cifs.upcall: host=figue
Dec 3 16:29:35 u1205-08l cifs.upcall: ip=130.xxx.xxx.xxx
Dec 3 16:29:35 u1205-08l cifs.upcall: sec=1
Dec 3 16:29:35 u1205-08l cifs.upcall: uid=16777221
Dec 3 16:29:35 u1205-08l cifs.upcall: creduid=16777221
Dec 3 16:29:35 u1205-08l cifs.upcall: user=21206xxx
Dec 3 16:29:35 u1205-08l cifs.upcall: pid=1631
Dec 3 16:29:35 u1205-08l cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_167
77221
Dec 3 16:29:35 u1205-08l cifs.upcall: find_krb5_cc: FILE:/tmp/krb5cc_16777221 i
s valid ccache

in dmesg
=========
fs/cifs/inode.c: Getting info on \21206xxx\TP9
[ 3735.419612] fs/cifs/transport.c: For smb_command 50
[ 3735.419615] fs/cifs/transport.c: Sending smb: total_len 104
[ 3735.420257] fs/cifs/connect.c: RFC1002 header 0x23
[ 3735.420261] fs/cifs/connect.c: invalid transact2 word count
[ 3735.422403] fs/cifs/transport.c: cifs_sync_mid_result: cmd=50 mid=37012 state=4
[ 3735.422406] CIFS VFS: Unexpected SMB signature
[ 3735.422408] Status code returned 0xc0000022 NT_STATUS_ACCESS_DENIED
[ 3735.422411] fs/cifs/netmisc.c: Mapping smb error code 0xc0000022 to POSIX err -13
[ 3735.422413] fs/cifs/cifssmb.c: Send error in QPathInfo = -13
[ 3735.422415] fs/cifs/dir.c: CIFS VFS: leaving cifs_lookup (xid = 76854) rc = -13
[ 3735.422424] fs/cifs/dir.c: CIFS VFS: in cifs_lookup as Xid: 76855 with uid: 16777221
[ 3735.422427] fs/cifs/dir.c: parent inode = 0xf14481f0 name is: TP9 and dentry = 0xf074e300
[ 3735.422429] fs/cifs/dir.c: NULL inode in lookup
[ 3735.422430] fs/cifs/dir.c: Full path: \21206xxx\TP9 inode = 0x (null)


I could try to do a network trace, but it could take some times. The bug don't appears often. About three times every day but not on the same machine.
Comment 1 Jeff Layton 2013-11-20 11:29:28 UTC
You may want to try a more recent kernel.

This message suggests that a lookup attempt caught a signal:

Dec 3 17:31:01 u1205-08l kernel: [ 3732.140040] CIFS VFS: Unexpected lookup error -512
Dec 3 17:31:01 u1205-08l kernel: [ 3732.334939] CIFS VFS: Unexpected SMB signature

It looks like your kernel needs a backport of commit ad313cb86dfba27f8f2306da304974ef17c91c56, which went into mainline in v3.10.
Comment 2 Jeff Layton 2013-11-20 11:40:49 UTC
Oh, and you might need 31efee60f489c759c341454d755a9fd13de8c03d too if the kernel has the NT_CANCEL code.
Comment 3 Jeff Layton 2014-02-04 18:40:05 UTC
No response in quite some time. Closing bug with the assumption that this is fixed. Please reopen if you're still seeing this with more recent kernels.
Comment 4 Mayk 2014-02-27 19:56:39 UTC
Created attachment 9733 [details]
transfer.c for kernel 3.2

builds fine, freezes up when using the cancle request
Comment 5 Mayk 2014-02-27 19:57:34 UTC
Comment on attachment 9733 [details]
transfer.c for kernel 3.2

can somebody help backporting ad313cb86dfba27f8f2306da304974ef17c91c56 to 3.2?
Comment 6 Mayk 2014-02-27 20:00:50 UTC
Comment on attachment 9733 [details]
transfer.c for kernel 3.2

2 of 5 insertions passed through with fuzz, 3 I had to adjust. Module builds fine, but it freezes when using the cancel code (ctr+c stroke during a cifs copy)