Note: see also https://bugzilla.samba.org/show_bug.cgi?id=8003 It seems that w2k8 behaves slightly differently than w2k3 and prior when it comes to DFS, at least when it comes to the various linux client implementations. We have a DFS shared folder at \\ourcorp.net\sharename\project. ourcorp.net is round-robin load-balanced between about 20 servers, of which maybe 20% are running w2k8. From what I can tell, a mount request from mount.cifs sends out an immediate TreeConnectAndXRequest to \\ourcorp.net\sharename. The w2k3 servers will respond with STATUS_PATH_NOT_COVERED, and the client will then do a TreeConnectAndX to ICP$ and ask with a GET_DFS_REFERRAL for \ourcorp.net\sharename\project, which gets a response and everything seems to work. However, to a 2k8 server, the server will respond with NT_STATUS_BAD_NETWORK_NAME, and the cifs support in the kernel will just bail out with errno = -6. The end result is that mount.cifs works about 80% of the time at our site :/ From some observations with wireshark it seems that a windows 7 client will immediately try to connect to the IPC$ connect and ask for the dfs referrals for \ourcorp.net\sharename (no \project). It will then follow these referrals, and re-append \project when querying the next server. The patch I submitted in https://bugzilla.samba.org/show_bug.cgi?id=8003 (which has not yet been reviewed, but it's just a couple hours old :) basically falls back to asking for referrals for \site\share when \site\share\project doesn't work. I don't think that is sufficient here though, as you don't seem to be initially asking for the referrals like the samba client and windows client does. So I guess you'd need this, plus an initial DFS query. I will attach some cifsFYI / traceSamba output after I can sanitize the data to protect the names of the innocent. :)
Oh and before I go sanitizing: this was seen both on 2.6.32 and 2.6.35. I took a look in git from 2.6.35..HEAD and it doesn't seem like anything relevant has changed since then.
okay after looking at what's in dmesg, I'm not sure that sanitizing will really produce anything more than a more verbose version of what i stated above. If someone needs more detailed packet dumps, etc, please let me know how I can get it to you out-of-band, as the dumps contain sensitive data in them. one other thing I've noticed, is that in both cases, the client is sending a tree-disconnect request to which the server responds INVALID_TREE, though I don't think it's relevant to this bug.
Created attachment 51172 [details] Proposed fix From the patch comments: Windows 2008 CIFS servers do not always return PATH_NOT_COVERED when attempting to access a DFS share. Therefore, when checking for remote shares, unconditionally ask for a DFS referral for the UNC (w/out prepath) before continuing with previous behavior of attempting to access the UNC + prepath and checking for PATH_NOT_COVERED.
A patch referencing this bug report has been merged in v3.0-rc1: commit c1508ca23653245266e2e3ab69a8dad464f7a569 Author: Sean Finney <seanius@seanius.net> Date: Mon Apr 11 13:19:31 2011 +0000 cifs: Add support for mounting Windows 2008 DFS shares