mount.cifs on Win2k8 DFS servers

Hi,

my CIFS kernel module (linux 2.6.39.3) fails to mount DFS trees from Win2k8 servers.

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

I believe this was fixed in 3.0. You should test a later kernel...

Jeff Layton <[email protected]>

hrm... i recognize that one :) reminds me i should go poke the samba team as it's still an issue afaik...

I think this should be fixed in later kernels... I worked with Jeff and Steve to get some patches in for what I think is the same issue you're describing, and iirc they landed just after 2.6.39 but before 3.0.

sean

Hi,

OK, thanks!!!

I doubted it could have gone unnoticed for such long a time. I had looked up the samba bugzilla but of course the bug report was on the kernel's one. :-)

So I guess you're talking about these two little fellas:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=dd61394586dbd9387fe53b325c6807f61734cf89
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c1508ca23653245266e2e3ab69a8dad464f7a569

Which I painlessly merged and tested on my 2.6.39.3 and are working fine (external behvaviour seems consistent with my ugly patch in that it retries after a regular mount).

Two newbie-like comments though:

1) I would've expected a more radical fix by skipping to DFS referal altogether when server has DFS capabilities, even before trying a regular connect, so to make it consistent with smbclient. Which (as far as I can tell) has been working like this for a looong time.

2) Shouldn't this/these patch/es also make it into earlier kernels as it is a (not-so-negligible) bugfix?

Thank you for your patience!
Gerlando

Hiya,

IIRC there were 3 or 4 more, though mostly cosmetic/cleanup. They should be right before or after those commits.

I don't think smbclient's behavior is correct either though. It's a ways back now, but at the time I compared the existing behavior of smbclient, a couple different windows clients, and cifs.ko, and none were really consistant with the other. The reference doc was not entirely specific either IIRC.

But based on what the module was already doing, it seemed "right enough" anyway, and with cleanup/refactoring was kept pretty clean in case someone wants to improve on it in the future :)

I don't think it's super trivial to backport it before 2.6.38, at least without massaging the patches and cherry picking a few more commits that cross paths and/or touch the relevant api's. But there've been enough other bugfixes in the cifs code that for our needs we just upgraded to a backported 2.6.38 kernel and dumped the pre-3.0 cifs commit history on top of it (we didn't go all the way to 3.0 for entirely uninteresting reasons, you should just do that if you have the ability).

sean

I didn't dive deep enough into this, but my XP client didn't even try connecting, it would just go straight to getting a DFS referral, and that seemed consistent with smbclient. How it made that decision, though, I really don't know.

I would be surprised if it were consistent, let alone specific... :-)

I see. Won't ask any more questions. Thanks for fixing it! :-)

It merged easily into my 2.6.39.3, and that'll do for now. :-)

Gerlando