When mounting a Samba share using mount.cifs, the share root's contents are shown in place of a subdirectory's contents. Subdirectories off of this pseudo-root work as usual. In other words: "ls /smb/ashley/directory" shows the contents of the root of \\ashley\directory, as expected. "ls '/smb/ashley/directory/Fall 2006/Directory'" also shows the contents of the root of \\ashley\directory, which is incorrect. "ls '/smb/ashley/directory/Fall 2006/Directory/Fall 2006/Directory'" shows the contents of \\ashley\directory\Fall 2006\Directory. Both client and server are running Linux (CentOS 4.3) with Samba 3.0.23b.
Created attachment 2111 [details] Packet trace of "ls '/smb/ashley/directory/Fall 2006/Directory'"
Created attachment 2112 [details] Level 10 debug log of "ls '/smb/ashley/directory/Fall 2006/Directory'"
Created attachment 2113 [details] Packet trace of "ls '/smb/ashley/directory/Fall 2006/Directory/Fall 2006/Directory'"
Created attachment 2114 [details] Level 10 debug log of "ls '/smb/ashley/directory/Fall 2006/Directory/Fall 2006/Directory'"
handing this to Steve as I'm skeptical it is a server bug.
Upon further investigation, from what I can tell with my extremely limited knowledge of CIFS: The bug does indeed appear to be with the linux-cifs client. The linux-cifs client passes only the directory path ("\Fall 2006\Directory\..."), rather than server + share + directory path. The Samba server tries to resolve \Fall 2006\Directory\... as a DFS share, so it parses out Fall 2006 as a nonexistent server, Directory as the share name, and the rest of the path as relative to the root of the Directory share. A workaround is to disable DFS; the fix would be to have the linux-cifs client always include the hostname and share in filename requests while DFS is enabled.
I get the same problem with mount.cifs 1.10 and a Win2003 server with DFS. To get access to \\myserver\myshare\myfile mounted on /mnt, I have to use /mnt/x/x/myfile (where "x" can be any random string)
This is a "me too" - but with a twist. We have a Win2K3 DFS server that maps ONE directory "/server1/share/archive" to another server "//server2/share2/archive". All the rest of server1 is local. However, if I connect using mount.cifs under 2.6.19+, I can't correctly list/access any directory under //server1/share/ - i.e. "ls -l /server1/share/dir/" returns the dir listing from "/server1/share". The twist is that it works fine with a 2.6.18 kernel - only the newer ones have this problem. I can reboot into 2.6.18, do the listing successfully, then reboot into a pure 2.6.20 kernel and the listing will be incorrect. Sounds like some changes occurred in 2.6.19+ that broke this? Thanks Jason
The bugs (the fixes for either of which should resolve your problem) are: Linux CIFS client was setting SMBFLG2_DFS when server claimed to support it, but we weren't sending a path beginning with a UNC name (ie we should have been sending \\server\share\path) - some server handle it but not this version of Samba. Samba 3.0 server was not recognizing a path coming in with the DFS flag but that lacked the path prefix (I believe that the server is also fixed now).
The fix in mainline for this was: commit 646dd539878a194bc14b104621c0b2b33587e40f Author: Steve French <sfrench@us.ibm.com> Date: Thu May 15 01:50:56 2008 +0000 [CIFS] Fix paths when share is in DFS to include proper prefix Some versions of Samba (3.2-pre e.g.) are stricter about checking to make sure that paths in DFS name spaces are sent in the form \\server\share\dir\subdir ... instead of \dir\subdir Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
This was fixed on the cifs kernel client in 2.6.26 (version 1.53 of cifs.ko), 2.6.26-rc4 to be precise. IIRC a Samba server workaround for this was also fixed/added in late May so that the server (as it used to do) no longer tried to parse server names out of DFS paths when they look wrong. For older cifs, an easy fix for this would be to simply turn off the DFS flag on SMB requests on older cifs (current cifs since 2.6.26 kernel supports DFS). See attached patch for a quick fix for a fix for older (pre-2.6.26 kernel version of cifs) cifs versions.
Forgot to mention another workaround - if the server (as Samba does by default via smb.conf) can be configured to report that it does not support DFS then this also avoids the problem.
Created attachment 3514 [details] workaround patch for older cifs.ko (turns off DFS flag in request)
Fixed in 2.6.26-rc4 and later. Workarounds provided. Patch for older cifs provided. Server workaround fix also available for some servers.
*** Bug 5176 has been marked as a duplicate of this bug. ***
*** Bug 5534 has been marked as a duplicate of this bug. ***
*** Bug 4525 has been marked as a duplicate of this bug. ***