On Mon, 17 Oct 2011 13:58:46 +0200 Gerlando Falauto <gerlando.falauto@xxxxxxxxxxx> wrote: > Hi, > > my CIFS kernel module (linux 2.6.39.3) fails to mount DFS trees from > Win2k8 servers. > I believe this was fixed in 3.0. You should test a later kernel... > Whereas upon "Tree Connect AndX Request"s (for a DFS tree) Win2k3 used > to reply with STATUS_PATH_NOT_COVERED, Win2k8 now answers with > STATUS_BAD_NETWORK_NAME, pretty much the same thing it would say about a > non-existing share. > > This is somewhat related to: > https://bugzilla.samba.org/show_bug.cgi?id=8003 > but in fact only affects cifs-fs and NOT smbclient which works fine for me. > > In fact, Windows machines (and smbclient, for that matter) don't ever > try connecting the tree, as they both start off with a "Trans2 Request" > GET_DFS_REFERRAL. > > Excerpt from source3/libsmb/clidfs.c: > === CUT === > /* here's the fun part....to support 'msdfs proxy' shares > (on Samba or windows) we have to issues a TRANS_GET_DFS_REFERRAL > here before trying to connect to the original share. > cli_check_msdfs_proxy() will fail if it is a normal share. */ > > if ((cli_state_capabilities(c) & CAP_DFS) && > === CUT === > > Now, I came up with a workaround (which I would not post here in order > not to be yelled at...) for cifs-fs which simply treats > NT_STATUS_BAD_NETWORK_NAME as NT_STATUS_PATH_NOT_COVERED, but I guess we > need a better solution. > > What should be the be best approach for facing this? > Detecting the server has DFS capabilities and start getting DFS > referrals to begin with? > Has this been discussed in the past? I find it hard to believe that no > one has reported this problem before... > > Thanks! > Gerlando > -- > To unsubscribe from this list: send the line "unsubscribe linux-cifs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html