Fwd: mount.cifs fails but smbclient succeeds

Fwd: mount.cifs fails but smbclient succeeds

[Wout Mertens]

Hi,

I need to mount a file server that I only have credentials for and
know nothing about.

I have a completely vanilla setup without /etc/smb.conf, nor any Samba
service running; only the samba client binaries are installed. The
credentials are domain, username, password; Kerberos is not being used
as confirmed by the smbclient debug output.

When I connect using

    smbclient -A credentials.txt //corp.local/mnt

it works fine. The name corp.local resolves using DNS and I can browse
the datastore.

When I mount using

 mount -vvvvv -t cifs //corp.local/mnt --verbose
-overs=3,credentials=credentials.txt,sec=ntlmssp /mnt

I see that I get a STATUS_BAD_NETWORK_NAME back. If I change the
credentials, I get a logon error, and if I change the mount name, I
get a missing file error. So it seems that the path and the
credentials are correct. If I change the version to 1, it fails in
some other way. If I change the sec to ntlm, it complains about
authentication.

Any suggestions? This is driving me crazy :-/

Many thanks!

Wout.

Re: mount.cifs fails but smbclient succeeds

[Steve French]

What kernel version? Note that we did make a change late last year in
how we report the server name component of the UNC name during tree
connection so could be useful to try with reasonably recent kernel -
perhaps 5.1 kernel if possible as an experiment

What server type?

On Mon, Jul 8, 2019 at 7:52 PM Wout Mertens <wout.mertens@gmail.com> wrote:
>
> Hi,
>
> I need to mount a file server that I only have credentials for and
> know nothing about.
>
> I have a completely vanilla setup without /etc/smb.conf, nor any Samba
> service running; only the samba client binaries are installed. The
> credentials are domain, username, password; Kerberos is not being used
> as confirmed by the smbclient debug output.
>
> When I connect using
>
>     smbclient -A credentials.txt //corp.local/mnt
>
> it works fine. The name corp.local resolves using DNS and I can browse
> the datastore.
>
> When I mount using
>
>  mount -vvvvv -t cifs //corp.local/mnt --verbose
> -overs=3,credentials=credentials.txt,sec=ntlmssp /mnt
>
> I see that I get a STATUS_BAD_NETWORK_NAME back. If I change the
> credentials, I get a logon error, and if I change the mount name, I
> get a missing file error. So it seems that the path and the
> credentials are correct. If I change the version to 1, it fails in
> some other way. If I change the sec to ntlm, it complains about
> authentication.
>
> Any suggestions? This is driving me crazy :-/
>
> Many thanks!
>
> Wout.



-- 
Thanks,

Steve

Re: mount.cifs fails but smbclient succeeds

[Wout Mertens]

Kernel is 4.19.57. I don't know what the file server is, any way I can
find out from protocol sniffing?

The system is an on-premise VM that I connect to over SSH, I'm worried
I'll kill my connectivity trying to boot it with a 5.1 kernel.

So I'll try running 5.1 locally and tunneling over SSH, and I'll report back.

Wout.

On Tue, Jul 9, 2019 at 5:05 AM Steve French <smfrench@gmail.com> wrote:
>
> What kernel version? Note that we did make a change late last year in
> how we report the server name component of the UNC name during tree
> connection so could be useful to try with reasonably recent kernel -
> perhaps 5.1 kernel if possible as an experiment
>
> What server type?
>
> On Mon, Jul 8, 2019 at 7:52 PM Wout Mertens <wout.mertens@gmail.com> wrote:
> >
> > Hi,
> >
> > I need to mount a file server that I only have credentials for and
> > know nothing about.
> >
> > I have a completely vanilla setup without /etc/smb.conf, nor any Samba
> > service running; only the samba client binaries are installed. The
> > credentials are domain, username, password; Kerberos is not being used
> > as confirmed by the smbclient debug output.
> >
> > When I connect using
> >
> >     smbclient -A credentials.txt //corp.local/mnt
> >
> > it works fine. The name corp.local resolves using DNS and I can browse
> > the datastore.
> >
> > When I mount using
> >
> >  mount -vvvvv -t cifs //corp.local/mnt --verbose
> > -overs=3,credentials=credentials.txt,sec=ntlmssp /mnt
> >
> > I see that I get a STATUS_BAD_NETWORK_NAME back. If I change the
> > credentials, I get a logon error, and if I change the mount name, I
> > get a missing file error. So it seems that the path and the
> > credentials are correct. If I change the version to 1, it fails in
> > some other way. If I change the sec to ntlm, it complains about
> > authentication.
> >
> > Any suggestions? This is driving me crazy :-/
> >
> > Many thanks!
> >
> > Wout.
>
>
>
> --
> Thanks,
>
> Steve

Re: Fwd: mount.cifs fails but smbclient succeeds

[Aurélien Aptel]

"Wout Mertens" <wout.mertens@gmail.com> writes:
> Any suggestions? This is driving me crazy :-/

If you make a network capture of smbclient connecting and a capture of
mount.cifs failing you can use smbcmp [1] to compare them.

https://github.com/aaptel/smbcmp

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)

Re: Fwd: mount.cifs fails but smbclient succeeds

[Wout Mertens]

Thank you so much Aurélien, smbcmp was really helpful!

Is there a way to force mount.cifs to use DFS? (cifs-utils 6.8, kernel 4.19.57)

It turns out that when smbclient connects, it sends that it supports
DFS, but mount.cifs sends that it does NOT support DFS. Then smbclient
connects to the host and figures out the correct server to talk to,
and connects as needed, but mount.cifs just fails to do that.

What I did was to sniff the smbclient traffic for the server that has
the path I wanted, and then mount that directly using mount.cifs. That
works, but I'm worried that if they move things around it will break
again, or maybe they'll split the mount in two servers.

Here's the comparison: (-: smbclient, +: mount.cifs)
======
smbclient first  has an extra "Negotiate Protocol Request" + Response,
which the mount.cifs doesn't do. Then there's a common "Negotiate
Protocol Request" + Response,
> Session Setup Request, NTLMSSP_NEGOTIATE  (same with the subsequent NTLMSSP_AUTH)
         Server Component: SMB2
     SMB2Header Length: 64
-        Credit Charge: 1
+        Credit Charge: 0
         Channel Sequence: 0
         Reserved: 0000
         Command: Session Setup (1)
-        Credits requested: 8192
-        Flags: 0x00000010, Priority
+        Credits requested: 130
+        Flags: 0x00000000
             .... .... .... .... .... .... .... ...0 = Response: This
is a REQUEST
             .... .... .... .... .... .... .... ..0. = Async command:
This is a SYNC command
             .... .... .... .... .... .... .... .0.. = Chained: This
pdu is NOT a chained command
             .... .... .... .... .... .... .... 0... = Signing: This
pdu is NOT signed
-            .... .... .... .... .... .... .001 .... = Priority: This
pdu contains a PRIORITY
+            .... .... .... .... .... .... .000 .... = Priority: This
pdu does NOT contain a PRIORITY
             ...0 .... .... .... .... .... .... .... = DFS operation:
This is a normal operation
             ..0. .... .... .... .... .... .... .... = Replay
operation: This is NOT a replay operation
         Chain Offset: 0x00000000
-        Message ID: Unknown (2)
-        Process Id: 0x00000000
+        Message ID: Unknown (1)
+        Process Id: 0x000040fc
[...]
-        Security mode: 0x01, Signing enabled
-            .... ...1 = Signing enabled: True
-            .... ..0. = Signing required: False
-        Capabilities: 0x00000001, DFS
-            .... .... .... .... .... .... .... ...1 = DFS: This host
supports DFS
+        Security mode: 0x02, Signing required
+            .... ...0 = Signing enabled: False
+            .... ..1. = Signing required: True
+        Capabilities: 0x00000000
+            .... .... .... .... .... .... .... ...0 = DFS: This host
does NOT support DFS

After that, they both do

> Session Setup Response
> Tree Connect Request Tree: \\corp.local\IPC$
> Tree Connect Response

and then smclient does
> Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \corp.local\ib
but mount.cifs does
> Ioctl Request FSCTL_VALIDATE_NEGOTIATE_INFO
======

I saw that there were fixes in 5.0 regarding crediting and DFS
reconnect, would they make a difference?

Wout.

On Tue, Jul 9, 2019 at 9:38 AM Aurélien Aptel <aaptel@suse.com> wrote:
>
> "Wout Mertens" <wout.mertens@gmail.com> writes:
> > Any suggestions? This is driving me crazy :-/
>
> If you make a network capture of smbclient connecting and a capture of
> mount.cifs failing you can use smbcmp [1] to compare them.
>
> https://github.com/aaptel/smbcmp
>
> --
> Aurélien Aptel / SUSE Labs Samba Team
> GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
> SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)

Re: Fwd: mount.cifs fails but smbclient succeeds

[Wout Mertens]

I installed linux 5.1.19 but that doesn't make a difference. It still
sets the DFS bit to 0 on the NTLMSSP_NEGOTIATE and then when smbclient
does a FSCTL_DFS_GET_REFERRALS, mount.cifs does a "Tree connect
request tree" which fails with "STATUS_BAD_NETWORK_NAME". After that
failure, it does do a FSCTL_DFS_GET_REFERRALS but it doesn't mount.



Wout.

On Thu, Jul 25, 2019 at 3:24 PM Wout Mertens <wout.mertens@gmail.com> wrote:
>
> Thank you so much Aurélien, smbcmp was really helpful!
>
> Is there a way to force mount.cifs to use DFS? (cifs-utils 6.8, kernel 4.19.57)
>
> It turns out that when smbclient connects, it sends that it supports
> DFS, but mount.cifs sends that it does NOT support DFS. Then smbclient
> connects to the host and figures out the correct server to talk to,
> and connects as needed, but mount.cifs just fails to do that.
>
> What I did was to sniff the smbclient traffic for the server that has
> the path I wanted, and then mount that directly using mount.cifs. That
> works, but I'm worried that if they move things around it will break
> again, or maybe they'll split the mount in two servers.
>
> Here's the comparison: (-: smbclient, +: mount.cifs)
> ======
> smbclient first  has an extra "Negotiate Protocol Request" + Response,
> which the mount.cifs doesn't do. Then there's a common "Negotiate
> Protocol Request" + Response,
> > Session Setup Request, NTLMSSP_NEGOTIATE  (same with the subsequent NTLMSSP_AUTH)
>          Server Component: SMB2
>      SMB2Header Length: 64
> -        Credit Charge: 1
> +        Credit Charge: 0
>          Channel Sequence: 0
>          Reserved: 0000
>          Command: Session Setup (1)
> -        Credits requested: 8192
> -        Flags: 0x00000010, Priority
> +        Credits requested: 130
> +        Flags: 0x00000000
>              .... .... .... .... .... .... .... ...0 = Response: This
> is a REQUEST
>              .... .... .... .... .... .... .... ..0. = Async command:
> This is a SYNC command
>              .... .... .... .... .... .... .... .0.. = Chained: This
> pdu is NOT a chained command
>              .... .... .... .... .... .... .... 0... = Signing: This
> pdu is NOT signed
> -            .... .... .... .... .... .... .001 .... = Priority: This
> pdu contains a PRIORITY
> +            .... .... .... .... .... .... .000 .... = Priority: This
> pdu does NOT contain a PRIORITY
>              ...0 .... .... .... .... .... .... .... = DFS operation:
> This is a normal operation
>              ..0. .... .... .... .... .... .... .... = Replay
> operation: This is NOT a replay operation
>          Chain Offset: 0x00000000
> -        Message ID: Unknown (2)
> -        Process Id: 0x00000000
> +        Message ID: Unknown (1)
> +        Process Id: 0x000040fc
> [...]
> -        Security mode: 0x01, Signing enabled
> -            .... ...1 = Signing enabled: True
> -            .... ..0. = Signing required: False
> -        Capabilities: 0x00000001, DFS
> -            .... .... .... .... .... .... .... ...1 = DFS: This host
> supports DFS
> +        Security mode: 0x02, Signing required
> +            .... ...0 = Signing enabled: False
> +            .... ..1. = Signing required: True
> +        Capabilities: 0x00000000
> +            .... .... .... .... .... .... .... ...0 = DFS: This host
> does NOT support DFS
>
> After that, they both do
>
> > Session Setup Response
> > Tree Connect Request Tree: \\corp.local\IPC$
> > Tree Connect Response
>
> and then smclient does
> > Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \corp.local\ib
> but mount.cifs does
> > Ioctl Request FSCTL_VALIDATE_NEGOTIATE_INFO
> ======
>
> I saw that there were fixes in 5.0 regarding crediting and DFS
> reconnect, would they make a difference?
>
> Wout.
>
> On Tue, Jul 9, 2019 at 9:38 AM Aurélien Aptel <aaptel@suse.com> wrote:
> >
> > "Wout Mertens" <wout.mertens@gmail.com> writes:
> > > Any suggestions? This is driving me crazy :-/
> >
> > If you make a network capture of smbclient connecting and a capture of
> > mount.cifs failing you can use smbcmp [1] to compare them.
> >
> > https://github.com/aaptel/smbcmp
> >
> > --
> > Aurélien Aptel / SUSE Labs Samba Team
> > GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
> > SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)

Re: Fwd: mount.cifs fails but smbclient succeeds

[Steve French]

To clarify the differences you see:
1) on the smb2 session setup requests you see the working client
(smbclient) setting the SMB2_FLAGS_PRIORITY flags (this shouldn't make
any difference because it is SMB3.1.1 specific flag unless the server
negotiated smb3.1.1)
2) you see CAP_DFS (0x00000001) not CAP_EXTENDED_SECURITY (0x80000000)
set on the Capabilities field of the session setup response (the
negotiate protocol request if you specify vers=3 or vers=3.1 or
vers=3.1.1 or vers=3.0 should show these capabilities set on the
negotiate protocol request:

SMB2_GLOBAL_CAP_DFS | SMB2_GLOBAL_CAP_LEASING |
SMB2_GLOBAL_CAP_LARGE_MTU | SMB2_GLOBAL_CAP_PERSISTENT_HANDLES |
SMB2_GLOBAL_CAP_ENCRYPTION | SMB2_GLOBAL_CAP_DIRECTORY_LEASING

Would also be interesting to see if the signing required difference is related.

I could give you a patch that forces the Capabilities field to include
more flags on session setup - it is easy enough to change the line
(round line 1181 of smb2pdu.c) - see SMB2_sess_alloc_buffer

req->Capabilities = 0;

to req_capabilities = SMB2_GLOBAL_CAP_DFS;

On Thu, Jul 25, 2019 at 9:12 AM Wout Mertens <wout.mertens@gmail.com> wrote:
>
> Thank you so much Aurélien, smbcmp was really helpful!
>
> Is there a way to force mount.cifs to use DFS? (cifs-utils 6.8, kernel 4.19.57)
>
> It turns out that when smbclient connects, it sends that it supports
> DFS, but mount.cifs sends that it does NOT support DFS. Then smbclient
> connects to the host and figures out the correct server to talk to,
> and connects as needed, but mount.cifs just fails to do that.
>
> What I did was to sniff the smbclient traffic for the server that has
> the path I wanted, and then mount that directly using mount.cifs. That
> works, but I'm worried that if they move things around it will break
> again, or maybe they'll split the mount in two servers.
>
> Here's the comparison: (-: smbclient, +: mount.cifs)
> ======
> smbclient first  has an extra "Negotiate Protocol Request" + Response,
> which the mount.cifs doesn't do. Then there's a common "Negotiate
> Protocol Request" + Response,
> > Session Setup Request, NTLMSSP_NEGOTIATE  (same with the subsequent NTLMSSP_AUTH)
>          Server Component: SMB2
>      SMB2Header Length: 64
> -        Credit Charge: 1
> +        Credit Charge: 0
>          Channel Sequence: 0
>          Reserved: 0000
>          Command: Session Setup (1)
> -        Credits requested: 8192
> -        Flags: 0x00000010, Priority
> +        Credits requested: 130
> +        Flags: 0x00000000
>              .... .... .... .... .... .... .... ...0 = Response: This
> is a REQUEST
>              .... .... .... .... .... .... .... ..0. = Async command:
> This is a SYNC command
>              .... .... .... .... .... .... .... .0.. = Chained: This
> pdu is NOT a chained command
>              .... .... .... .... .... .... .... 0... = Signing: This
> pdu is NOT signed
> -            .... .... .... .... .... .... .001 .... = Priority: This
> pdu contains a PRIORITY
> +            .... .... .... .... .... .... .000 .... = Priority: This
> pdu does NOT contain a PRIORITY
>              ...0 .... .... .... .... .... .... .... = DFS operation:
> This is a normal operation
>              ..0. .... .... .... .... .... .... .... = Replay
> operation: This is NOT a replay operation
>          Chain Offset: 0x00000000
> -        Message ID: Unknown (2)
> -        Process Id: 0x00000000
> +        Message ID: Unknown (1)
> +        Process Id: 0x000040fc
> [...]
> -        Security mode: 0x01, Signing enabled
> -            .... ...1 = Signing enabled: True
> -            .... ..0. = Signing required: False
> -        Capabilities: 0x00000001, DFS
> -            .... .... .... .... .... .... .... ...1 = DFS: This host
> supports DFS
> +        Security mode: 0x02, Signing required
> +            .... ...0 = Signing enabled: False
> +            .... ..1. = Signing required: True
> +        Capabilities: 0x00000000
> +            .... .... .... .... .... .... .... ...0 = DFS: This host
> does NOT support DFS
>
> After that, they both do
>
> > Session Setup Response
> > Tree Connect Request Tree: \\corp.local\IPC$
> > Tree Connect Response
>
> and then smclient does
> > Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \corp.local\ib
> but mount.cifs does
> > Ioctl Request FSCTL_VALIDATE_NEGOTIATE_INFO
> ======
>
> I saw that there were fixes in 5.0 regarding crediting and DFS
> reconnect, would they make a difference?
>
> Wout.
>
> On Tue, Jul 9, 2019 at 9:38 AM Aurélien Aptel <aaptel@suse.com> wrote:
> >
> > "Wout Mertens" <wout.mertens@gmail.com> writes:
> > > Any suggestions? This is driving me crazy :-/
> >
> > If you make a network capture of smbclient connecting and a capture of
> > mount.cifs failing you can use smbcmp [1] to compare them.
> >
> > https://github.com/aaptel/smbcmp
> >
> > --
> > Aurélien Aptel / SUSE Labs Samba Team
> > GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
> > SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)



-- 
Thanks,

Steve

Re: Fwd: mount.cifs fails but smbclient succeeds

[Wout Mertens]

Thanks! I'll give that a try and let you know.

Wout.

On Thu, Jul 25, 2019 at 8:51 PM Steve French <smfrench@gmail.com> wrote:
>
> To clarify the differences you see:
> 1) on the smb2 session setup requests you see the working client
> (smbclient) setting the SMB2_FLAGS_PRIORITY flags (this shouldn't make
> any difference because it is SMB3.1.1 specific flag unless the server
> negotiated smb3.1.1)
> 2) you see CAP_DFS (0x00000001) not CAP_EXTENDED_SECURITY (0x80000000)
> set on the Capabilities field of the session setup response (the
> negotiate protocol request if you specify vers=3 or vers=3.1 or
> vers=3.1.1 or vers=3.0 should show these capabilities set on the
> negotiate protocol request:
>
> SMB2_GLOBAL_CAP_DFS | SMB2_GLOBAL_CAP_LEASING |
> SMB2_GLOBAL_CAP_LARGE_MTU | SMB2_GLOBAL_CAP_PERSISTENT_HANDLES |
> SMB2_GLOBAL_CAP_ENCRYPTION | SMB2_GLOBAL_CAP_DIRECTORY_LEASING
>
> Would also be interesting to see if the signing required difference is related.
>
> I could give you a patch that forces the Capabilities field to include
> more flags on session setup - it is easy enough to change the line
> (round line 1181 of smb2pdu.c) - see SMB2_sess_alloc_buffer
>
> req->Capabilities = 0;
>
> to req_capabilities = SMB2_GLOBAL_CAP_DFS;
>
> On Thu, Jul 25, 2019 at 9:12 AM Wout Mertens <wout.mertens@gmail.com> wrote:
> >
> > Thank you so much Aurélien, smbcmp was really helpful!
> >
> > Is there a way to force mount.cifs to use DFS? (cifs-utils 6.8, kernel 4.19.57)
> >
> > It turns out that when smbclient connects, it sends that it supports
> > DFS, but mount.cifs sends that it does NOT support DFS. Then smbclient
> > connects to the host and figures out the correct server to talk to,
> > and connects as needed, but mount.cifs just fails to do that.
> >
> > What I did was to sniff the smbclient traffic for the server that has
> > the path I wanted, and then mount that directly using mount.cifs. That
> > works, but I'm worried that if they move things around it will break
> > again, or maybe they'll split the mount in two servers.
> >
> > Here's the comparison: (-: smbclient, +: mount.cifs)
> > ======
> > smbclient first  has an extra "Negotiate Protocol Request" + Response,
> > which the mount.cifs doesn't do. Then there's a common "Negotiate
> > Protocol Request" + Response,
> > > Session Setup Request, NTLMSSP_NEGOTIATE  (same with the subsequent NTLMSSP_AUTH)
> >          Server Component: SMB2
> >      SMB2Header Length: 64
> > -        Credit Charge: 1
> > +        Credit Charge: 0
> >          Channel Sequence: 0
> >          Reserved: 0000
> >          Command: Session Setup (1)
> > -        Credits requested: 8192
> > -        Flags: 0x00000010, Priority
> > +        Credits requested: 130
> > +        Flags: 0x00000000
> >              .... .... .... .... .... .... .... ...0 = Response: This
> > is a REQUEST
> >              .... .... .... .... .... .... .... ..0. = Async command:
> > This is a SYNC command
> >              .... .... .... .... .... .... .... .0.. = Chained: This
> > pdu is NOT a chained command
> >              .... .... .... .... .... .... .... 0... = Signing: This
> > pdu is NOT signed
> > -            .... .... .... .... .... .... .001 .... = Priority: This
> > pdu contains a PRIORITY
> > +            .... .... .... .... .... .... .000 .... = Priority: This
> > pdu does NOT contain a PRIORITY
> >              ...0 .... .... .... .... .... .... .... = DFS operation:
> > This is a normal operation
> >              ..0. .... .... .... .... .... .... .... = Replay
> > operation: This is NOT a replay operation
> >          Chain Offset: 0x00000000
> > -        Message ID: Unknown (2)
> > -        Process Id: 0x00000000
> > +        Message ID: Unknown (1)
> > +        Process Id: 0x000040fc
> > [...]
> > -        Security mode: 0x01, Signing enabled
> > -            .... ...1 = Signing enabled: True
> > -            .... ..0. = Signing required: False
> > -        Capabilities: 0x00000001, DFS
> > -            .... .... .... .... .... .... .... ...1 = DFS: This host
> > supports DFS
> > +        Security mode: 0x02, Signing required
> > +            .... ...0 = Signing enabled: False
> > +            .... ..1. = Signing required: True
> > +        Capabilities: 0x00000000
> > +            .... .... .... .... .... .... .... ...0 = DFS: This host
> > does NOT support DFS
> >
> > After that, they both do
> >
> > > Session Setup Response
> > > Tree Connect Request Tree: \\corp.local\IPC$
> > > Tree Connect Response
> >
> > and then smclient does
> > > Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \corp.local\ib
> > but mount.cifs does
> > > Ioctl Request FSCTL_VALIDATE_NEGOTIATE_INFO
> > ======
> >
> > I saw that there were fixes in 5.0 regarding crediting and DFS
> > reconnect, would they make a difference?
> >
> > Wout.
> >
> > On Tue, Jul 9, 2019 at 9:38 AM Aurélien Aptel <aaptel@suse.com> wrote:
> > >
> > > "Wout Mertens" <wout.mertens@gmail.com> writes:
> > > > Any suggestions? This is driving me crazy :-/
> > >
> > > If you make a network capture of smbclient connecting and a capture of
> > > mount.cifs failing you can use smbcmp [1] to compare them.
> > >
> > > https://github.com/aaptel/smbcmp
> > >
> > > --
> > > Aurélien Aptel / SUSE Labs Samba Team
> > > GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
> > > SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
>
>
>
> --
> Thanks,
>
> Steve

Re: Fwd: mount.cifs fails but smbclient succeeds

[Steve French]

[-- Attachment #1: Type: text/plain, Size: 6064 bytes --]

Here is a patch to try


On Thu, Jul 25, 2019 at 3:59 PM Wout Mertens <wout.mertens@gmail.com> wrote:
>
> Thanks! I'll give that a try and let you know.
>
> Wout.
>
> On Thu, Jul 25, 2019 at 8:51 PM Steve French <smfrench@gmail.com> wrote:
> >
> > To clarify the differences you see:
> > 1) on the smb2 session setup requests you see the working client
> > (smbclient) setting the SMB2_FLAGS_PRIORITY flags (this shouldn't make
> > any difference because it is SMB3.1.1 specific flag unless the server
> > negotiated smb3.1.1)
> > 2) you see CAP_DFS (0x00000001) not CAP_EXTENDED_SECURITY (0x80000000)
> > set on the Capabilities field of the session setup response (the
> > negotiate protocol request if you specify vers=3 or vers=3.1 or
> > vers=3.1.1 or vers=3.0 should show these capabilities set on the
> > negotiate protocol request:
> >
> > SMB2_GLOBAL_CAP_DFS | SMB2_GLOBAL_CAP_LEASING |
> > SMB2_GLOBAL_CAP_LARGE_MTU | SMB2_GLOBAL_CAP_PERSISTENT_HANDLES |
> > SMB2_GLOBAL_CAP_ENCRYPTION | SMB2_GLOBAL_CAP_DIRECTORY_LEASING
> >
> > Would also be interesting to see if the signing required difference is related.
> >
> > I could give you a patch that forces the Capabilities field to include
> > more flags on session setup - it is easy enough to change the line
> > (round line 1181 of smb2pdu.c) - see SMB2_sess_alloc_buffer
> >
> > req->Capabilities = 0;
> >
> > to req_capabilities = SMB2_GLOBAL_CAP_DFS;
> >
> > On Thu, Jul 25, 2019 at 9:12 AM Wout Mertens <wout.mertens@gmail.com> wrote:
> > >
> > > Thank you so much Aurélien, smbcmp was really helpful!
> > >
> > > Is there a way to force mount.cifs to use DFS? (cifs-utils 6.8, kernel 4.19.57)
> > >
> > > It turns out that when smbclient connects, it sends that it supports
> > > DFS, but mount.cifs sends that it does NOT support DFS. Then smbclient
> > > connects to the host and figures out the correct server to talk to,
> > > and connects as needed, but mount.cifs just fails to do that.
> > >
> > > What I did was to sniff the smbclient traffic for the server that has
> > > the path I wanted, and then mount that directly using mount.cifs. That
> > > works, but I'm worried that if they move things around it will break
> > > again, or maybe they'll split the mount in two servers.
> > >
> > > Here's the comparison: (-: smbclient, +: mount.cifs)
> > > ======
> > > smbclient first  has an extra "Negotiate Protocol Request" + Response,
> > > which the mount.cifs doesn't do. Then there's a common "Negotiate
> > > Protocol Request" + Response,
> > > > Session Setup Request, NTLMSSP_NEGOTIATE  (same with the subsequent NTLMSSP_AUTH)
> > >          Server Component: SMB2
> > >      SMB2Header Length: 64
> > > -        Credit Charge: 1
> > > +        Credit Charge: 0
> > >          Channel Sequence: 0
> > >          Reserved: 0000
> > >          Command: Session Setup (1)
> > > -        Credits requested: 8192
> > > -        Flags: 0x00000010, Priority
> > > +        Credits requested: 130
> > > +        Flags: 0x00000000
> > >              .... .... .... .... .... .... .... ...0 = Response: This
> > > is a REQUEST
> > >              .... .... .... .... .... .... .... ..0. = Async command:
> > > This is a SYNC command
> > >              .... .... .... .... .... .... .... .0.. = Chained: This
> > > pdu is NOT a chained command
> > >              .... .... .... .... .... .... .... 0... = Signing: This
> > > pdu is NOT signed
> > > -            .... .... .... .... .... .... .001 .... = Priority: This
> > > pdu contains a PRIORITY
> > > +            .... .... .... .... .... .... .000 .... = Priority: This
> > > pdu does NOT contain a PRIORITY
> > >              ...0 .... .... .... .... .... .... .... = DFS operation:
> > > This is a normal operation
> > >              ..0. .... .... .... .... .... .... .... = Replay
> > > operation: This is NOT a replay operation
> > >          Chain Offset: 0x00000000
> > > -        Message ID: Unknown (2)
> > > -        Process Id: 0x00000000
> > > +        Message ID: Unknown (1)
> > > +        Process Id: 0x000040fc
> > > [...]
> > > -        Security mode: 0x01, Signing enabled
> > > -            .... ...1 = Signing enabled: True
> > > -            .... ..0. = Signing required: False
> > > -        Capabilities: 0x00000001, DFS
> > > -            .... .... .... .... .... .... .... ...1 = DFS: This host
> > > supports DFS
> > > +        Security mode: 0x02, Signing required
> > > +            .... ...0 = Signing enabled: False
> > > +            .... ..1. = Signing required: True
> > > +        Capabilities: 0x00000000
> > > +            .... .... .... .... .... .... .... ...0 = DFS: This host
> > > does NOT support DFS
> > >
> > > After that, they both do
> > >
> > > > Session Setup Response
> > > > Tree Connect Request Tree: \\corp.local\IPC$
> > > > Tree Connect Response
> > >
> > > and then smclient does
> > > > Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \corp.local\ib
> > > but mount.cifs does
> > > > Ioctl Request FSCTL_VALIDATE_NEGOTIATE_INFO
> > > ======
> > >
> > > I saw that there were fixes in 5.0 regarding crediting and DFS
> > > reconnect, would they make a difference?
> > >
> > > Wout.
> > >
> > > On Tue, Jul 9, 2019 at 9:38 AM Aurélien Aptel <aaptel@suse.com> wrote:
> > > >
> > > > "Wout Mertens" <wout.mertens@gmail.com> writes:
> > > > > Any suggestions? This is driving me crazy :-/
> > > >
> > > > If you make a network capture of smbclient connecting and a capture of
> > > > mount.cifs failing you can use smbcmp [1] to compare them.
> > > >
> > > > https://github.com/aaptel/smbcmp
> > > >
> > > > --
> > > > Aurélien Aptel / SUSE Labs Samba Team
> > > > GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
> > > > SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> > > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
> >
> >
> >
> > --
> > Thanks,
> >
> > Steve



-- 
Thanks,

Steve

[-- Attachment #2: 0001-smb3-send-CAP_DFS-capability-during-session-setup.patch --]
[-- Type: text/x-patch, Size: 1118 bytes --]

From 182c806c3d96adf57c32842178db06e44b46d247 Mon Sep 17 00:00:00 2001
From: Steve French <stfrench@microsoft.com>
Date: Thu, 25 Jul 2019 18:13:10 -0500
Subject: [PATCH] smb3: send CAP_DFS capability during session setup

We had a report of a server which did not do a DFS referral
because the session setup Capabilities field was set to 0
(unlike negotiate protocol where we set CAP_DFS).  Better to
send it session setup in the capabilities as well (this also
more closely matches Windows client behavior).

Signed-off-by: Steve French <stfrench@microsoft.com>
---
 fs/cifs/smb2pdu.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 53f889783e59..ee5d74988a9f 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1196,7 +1196,12 @@ SMB2_sess_alloc_buffer(struct SMB2_sess_data *sess_data)
 	else
 		req->SecurityMode = 0;
 
+#ifdef CONFIG_CIFS_DFS_UPCALL
+	req->Capabilities = cpu_to_le32(SMB2_GLOBAL_CAP_DFS);
+#else
 	req->Capabilities = 0;
+#endif /* DFS_UPCALL */
+
 	req->Channel = 0; /* MBZ */
 
 	sess_data->iov[0].iov_base = (char *)req;
-- 
2.20.1