mount.cifs on Win2k8 DFS servers

mount.cifs on Win2k8 DFS servers

[Gerlando Falauto]

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

Re: mount.cifs on Win2k8 DFS servers

[Jeff Layton]

On Mon, 17 Oct 2011 13:58:46 +0200
Gerlando Falauto <gerlando.falauto-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Jeff Layton <jlayton-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org>

Re: mount.cifs on Win2k8 DFS servers

[sean finney]

On Mon, Oct 17, 2011 at 01:58:46PM +0200, Gerlando Falauto wrote:
> my CIFS kernel module (linux 2.6.39.3) fails to mount DFS trees from
> Win2k8 servers.

> This is somewhat related to:
> 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...

> 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

-- 

Re: mount.cifs on Win2k8 DFS servers

[Gerlando Falauto]

Hi,


> 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

Re: mount.cifs on Win2k8 DFS servers

[sean finney]

Hiya,

On Mon, Oct 17, 2011 at 05:04:22PM +0200, Gerlando Falauto wrote:
> 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

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

> 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 :)

> 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

-- 

Re: mount.cifs on Win2k8 DFS servers

[Gerlando Falauto]

On 10/17/2011 07:11 PM, sean finney wrote:
> 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.

 > The reference doc was not entirely specific either IIRC.

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

> 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! :-)

>> 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