Hi there I had a totally working Centos 4.4 system with a hand-built 2.6.18 kernel (don't ask). I used it to mount via cifs various Windows2K3 servers to share data, etc. I just tried upgrading first to 2.6.19.2 and then 2.6.20.7 (built the kernel using the 2.6.18 .config file), and have found that cifs is broken. What happens now is that the mount works, and some dirs are listable/etc, but there are some dirs where entire subdirectories no longer show up, and if I do a "ls -l bogus_file", I get the current directory listed instead of an error! e.g. Linux-2.6.18 mount -t cifs //server/share /mnt/smb -ousername=test,password=xxx ls -la /mnt/smb/dir|wc 74 659 3956 ----- Linux 2.6.20.7 mount t cifs //server/share /mnt/smb -ousername=test,password=xxx ls -la /mnt/smb/dir|wc 29 285 1525 I just tried this on my FC5 workstation with it's Redhat supplied 2.6.20-1.2307.fc5smp kernel - same problem! Has anyone else seen this? Any ideas what could be different that could cause that? It can't be a permission problem - I obviously mounted the same share as the same user on all three (four) kernels. Thanks (back to 2.6.18 for the time being)
Trying to clean out some older bugs, and just noticed this. Couple obvious questions (obviously this can't be too common problem or we would have seen it more). a) What version of cifs ("cat /proc/fs/cifs/DebugData") does your distro run (I don't have the list of cifs versions that match each of the kernels handy, and list of the bug fixes for cifs in fs/cifs/CHANGES are by cifs version not kernel version). b) Which file system on the server side (NTFS or FAT or UDF etc.)? c) Any chance that you could get a binary trace of the failure (see the instructions at http://wiki.samba.org/index.php/Capture_Packets for instructions if you are not used to diagnosing network problems with network traces)? Ideally a short trace (start just befor a command, and stop right after it, instead of tracing for a long time) is easier to read. Even better would be turning on cifs tracing for this period too. "dmesg -c" (clear the message log) "echo 7 > /proc/fs/cifs/cifsFYI" (turn on network tracing) reproduce the problem (e.g. "ls -l bogus_file") "dmesg > ~/trace-file-of-failed-ls.txt" (save the trace) "echo 0 > /proc/fs/cifs/cifsFYI" (turn off cifs tracing) d)
Great - BTW it's still a problem up to 2.6.22-rc7. I have a Win2K3SP2 server (nzc-ap-fsv-04) with a share (group) that has had "DFS Enabled" on it. The filesystem is NTFS. If I connect using mount -t cifs //nzc-ap-fsv-04/group /mnt/tmp -o username=xxx,workgroup=yyy it succeeds, but doing a "ls -la" on any directory shown under /mnt/tmp just shows the directory listing of /mnt/tmp again. -------------------- cat /proc/fs/cifs/DebugData shows Display Internal CIFS Data Structures for Debugging --------------------------------------------------- CIFS Version 1.49 Active VFS Requests: 0 Servers: 1) Name: 10.3.0.134 Domain: AP Mounts: 1 OS: Windows Server 2003 R2 3790 Service Pack 1 NOS: Windows Server 2003 R2 5.2 Capability: 0x1f3fd SMB session status: 1 TCP status: 1 Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0 MIDs: Shares: 1) \\nzc-ap-fsv-04.ap.trimblecorp.net\group Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x700ff PathComponentMax: 255 Status: 1 type: DISK [root@tnz-jhaar-lt ~]# -------------------------------------------- I'll add network traces in separate comments.
Created attachment 2837 [details] network and /proc traces of listing a directory
I'm having the exact same problem. Trying to "ls" any directory in the CIFS mount results in an "ls" of the CIFS mount root. [root@localhost /]# cat /proc/fs/cifs/DebugData Display Internal CIFS Data Structures for Debugging --------------------------------------------------- CIFS Version 1.50 Active VFS Requests: 0 Servers: 1) Name: 172.20.32.103 Domain: KCI Mounts: 1 OS: Windows Server 2003 3790 Service Pack 2 NOS: Windows Server 2003 5.2 Capability: 0x1f3fd SMB session status: 1 TCP status: 1 Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0 MIDs: Shares: 1) \\kci-dc02.kci.com\Corp-Projects Uses: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x700ff PathComponentMax: 255 Status: 1 type: DISK [root@localhost /]# uname -a Linux localhost.localdomain 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 i386 GNU/Linux
The problem with subdirectories showing up with contents of the root directory was fixed - see bug 4066 *** This bug has been marked as a duplicate of bug 4066 ***