Bug 6147
| Summary: | Cannot read files by cifs from server 2003 shared folder, but can write/remove files | ||
|---|---|---|---|
| Product: | File System | Reporter: | Maxim Britov (maxim.britov) |
| Component: | Other | Assignee: | Steve French (sfrench) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | bunk |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.16-rc5 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: | ethereal packet capture showing unsigned cifs read requests. | ||
|
Description
Maxim Britov
2006-03-02 04:16:55 UTC
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! |