Discussion:
mount.cifs on Win2k8 DFS servers
(too old to reply)
Gerlando Falauto
2011-10-17 11:58:46 UTC
Permalink
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
sean finney
2011-10-17 12:36:35 UTC
Permalink
Post by Gerlando Falauto
my CIFS kernel module (linux 2.6.39.3) fails to mount DFS trees from
Win2k8 servers.
https://bugzilla.samba.org/show_bug.cgi?id=8003
hrm... i recognize that one :) reminds me i should go poke the
samba team as it's still an issue afaik...
Post by Gerlando Falauto
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...
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

--
Gerlando Falauto
2011-10-17 15:04:22 UTC
Permalink
Hi,
Post by sean finney
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.
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
sean finney
2011-10-17 17:11:52 UTC
Permalink
Hiya,
Post by Gerlando Falauto
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
IIRC there were 3 or 4 more, though mostly cosmetic/cleanup. They should
be right before or after those commits.
Post by Gerlando Falauto
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.
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 :)
Post by Gerlando Falauto
2) Shouldn't this/these patch/es also make it into earlier kernels
as it is a (not-so-negligible) bugfix?
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

--
Gerlando Falauto
2011-10-18 09:18:20 UTC
Permalink
Post by sean finney
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.
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.
Post by sean finney
The reference doc was not entirely specific either IIRC.
I would be surprised if it were consistent, let alone specific... :-)
Post by sean finney
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 see. Won't ask any more questions. Thanks for fixing it! :-)
Post by sean finney
Post by Gerlando Falauto
2) Shouldn't this/these patch/es also make it into earlier kernels
as it is a (not-so-negligible) bugfix?
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).
It merged easily into my 2.6.39.3, and that'll do for now. :-)

Gerlando

Jeff Layton
2011-10-17 12:28:27 UTC
Permalink
On Mon, 17 Oct 2011 13:58:46 +0200
Post by Gerlando Falauto
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...
Post by Gerlando Falauto
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.
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.
=== 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
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jeff Layton <jlayton-vpEMnDpepFuMZCB2o+***@public.gmane.org>
Continue reading on narkive:
Loading...