Most recent kernel where this bug did not occur: 2.6.15 Distribution: Fedora 5 Hardware Environment: Sempron 2500/ide Software Environment: Linux version 2.6.16-rc5 gcc version 4.1.0 20060227 (Red Hat 4.1.0-0.30)) #6 PREEMPT Wed Mar 1 20:43:29 EET 2006 mount.cifs version: 1.10 Problem Description: I can create and remove files on cifs shares (server 2003 sp1), but I can't read files. Is it my misconfiguration or bug?? Steps to reproduce: # mount.cifs //server/folder /mnt/disk/ -o credentials=/etc/creds,iocharset=utf8,uid=0,gid=0,file_mode=0640,dir_mode=0750,domain=mydomain,nosetuids,noexec,noacl,noperm,nouser_xattr (I checked many different options) # ls -l test.txt -rw-r--r-- 1 root root 25 Mar 2 14:01 test.txt # cp test.txt /mnt/disk/ Debug: Mar 2 14:02:40 kernel: Status code returned 0xc0000034 NT_STATUS_OBJECT_NAME_NOT_FOUND # ls -l /mnt/disk/test.txt -rw-r----- 1 root root 25 Mar 2 14:02 /mnt/disk/test.txt # cp /mnt/disk/test.txt ./test2.txt cp: reading `/mnt/disk/test.txt': Permission denied Debug: Mar 2 14:04:20 kernel: Status code returned 0xc0000022 NT_STATUS_ACCESS_DENIED Mar 2 14:04:20 kernel: CIFS VFS: Send error in read = -13 Mar 2 14:04:20 kernel: Mar 2 14:04:20 kernel: Status code returned 0xc0000022 NT_STATUS_ACCESS_DENIED Mar 2 14:04:20 kernel: CIFS VFS: Send error in read = -13 # ls -l test2.txt -rw-r----- 1 root root 0 Mar 2 14:04 test2.txt # rm /mnt/disk/test.txt rm: remove regular file `/mnt/disk/test.txt'? y # ls -l /mnt/disk/test.txt ls: /mnt/disk/test.txt: No such file or directory
The server really is returning access denied. Two things that will help isolate this: 1) verify whether your smb ession was setup as guest (either via "net session" on the server side or by looking at the SecMode in /proc/fs/cifs/DebugData 2) cacls output (e.g. on the server "cacls c:\folder /T" which shows you the windows acl on the file
net session: \\myip.x.x.x <domain admin here> Linux version 2.6 0 00:00:12 /proc/fs/cifs/DebugData: Display Internal CIFS Data Structures for Debugging --------------------------------------------------- CIFS Version 1.40 Active VFS Requests: 0 Servers: 1) Name: serverip.x.x.x Domain: MYDOMAIN Mounts: 5 OS: Windows Server 2003 3790 Service Pack 1 NOS: Windows Server 2003 5.2 Capability: 0x1f3fd SMB session status: 1 TCP status: 1 Local Users To Server: 1 SecMode: 0xf Req On Wire: 0 MIDs: Shares: 1) \\server\folder Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x700ff PathComponentMax: 255 Status: 1 type: DISK cacls test.txt /T X:\folder\test.txt OFFICE\user1:C OFFICE\user2:R NT AUTHORITY\SYSTEM:F BUILTIN\AdminsGroup:F (i have russian server) cacls X:\folder D:\Documents BUILTIN\AdminsGroup:F OFFICE\user1:(OI)(CI)C OFFICE\user2:(OI)(CI)R OFFICE\Domain users:R NT AUTHORITY\SYSTEM:(OI)(CI)F BUILTIN\AdminsGroup:(OI)(CI)F OFFICE\user1:(OI)(CI)R PS. I checked before post issue in 2.6.15. That worked fine.
The failure for mount to windowsxp 64 bit was interesting and possibly different issue. I see smb return code 52 (probably "duplicate name" error depending on the category) - it would be helpful to see the smbtrace of this (ethereal or tcpdump or simpy "echo 1 > /proc/fs/cifs/traceSMB" before the mount - I would like to double check which smb status code is getting mapped to older smb error code 52 on the tree connection).
Created attachment 7710 [details] ethereal packet capture showing unsigned cifs read requests.
Steve: I had strange misconfiguration for Windows XP64 and it work fine now. I can mount and read files from that host. But I still can't read my Windows 2003 Server shared data :( Feel free to ask me any details/dumps/tests, etc.
Same problem connecting to shares on Windows 2003 domain controller. See the attached ethereal packet capture. Read requests are going out unsigned (signature field is all zeros). The problem seems to be in cifsencrypt.c:cifs_calc_signature2() which always returns -EOPNOTSUPP (see the /* FIXME */ next to the MD5Update() call).
Fix at: http://www.kernel.org/git/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=e9917a000fcc370408c8b7b83f2e85dba5fffbd4;hp=f1682e94a38b66ee2551f3a5e4b36259a561c411 This is a critically important fix so I may push up to mainline soon.
What about also submitting it for 2.6.16.2 after it went into Linus' tree?
I agree it should go in the 2.6.12.2 point release or equivalent as well - although not sure the process for that. I did also test a subsequent change (which allows writepages and other write routines to call the more efficient SMBwrite2, and thus also uses the new signing code) which would allow MUCH lower memory usage in the write path (as we see in the case when signing is disabled) and thus may improve cifs stability under low memory/memory pressure - but I am somewhat concerned how possible/likely it is to change a locked page (while in writepages) - after we have calculated the signature but before tcp sendmsg has copied it into the network buffer/adapter in order to send out. Probably very low probability of happening ... and we do retry (and the retry should work) but everytime that would happen (if it can happen) - the server would presumably kill the session and might log the bad signature error as a possible security event. In the midst of writepages, any of the pages is mmapped could be written but only if mmapped ... right? even though the page is locked?
sorry about the typo 2.6.16.2 not 2.6.12.2
The process for getting patches into 2.6.16.2 is described in Documentation/stable_kernel_rules.txt .
New version is working well. Steve -- thanks very much for fixing so quickly!