* Fwd: mount.cifs fails but smbclient succeeds [not found] <CAO3V83L1Q9jCLBsjHgFE1jw2PPi_sHtQz4geDKC4jEPWkhNYBg@mail.gmail.com> @ 2019-07-09 0:26 ` Wout Mertens 2019-07-09 3:05 ` Steve French 2019-07-09 7:38 ` Fwd: " Aurélien Aptel 0 siblings, 2 replies; 9+ messages in thread From: Wout Mertens @ 2019-07-09 0:26 UTC (permalink / raw) To: linux-cifs 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount.cifs fails but smbclient succeeds 2019-07-09 0:26 ` Fwd: mount.cifs fails but smbclient succeeds Wout Mertens @ 2019-07-09 3:05 ` Steve French 2019-07-09 7:31 ` Wout Mertens 2019-07-09 7:38 ` Fwd: " Aurélien Aptel 1 sibling, 1 reply; 9+ messages in thread From: Steve French @ 2019-07-09 3:05 UTC (permalink / raw) To: Wout Mertens; +Cc: CIFS 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount.cifs fails but smbclient succeeds 2019-07-09 3:05 ` Steve French @ 2019-07-09 7:31 ` Wout Mertens 0 siblings, 0 replies; 9+ messages in thread From: Wout Mertens @ 2019-07-09 7:31 UTC (permalink / raw) To: Steve French; +Cc: CIFS 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: mount.cifs fails but smbclient succeeds 2019-07-09 0:26 ` Fwd: mount.cifs fails but smbclient succeeds Wout Mertens 2019-07-09 3:05 ` Steve French @ 2019-07-09 7:38 ` Aurélien Aptel 2019-07-25 13:24 ` Wout Mertens 1 sibling, 1 reply; 9+ messages in thread From: Aurélien Aptel @ 2019-07-09 7:38 UTC (permalink / raw) To: Wout Mertens, linux-cifs "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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: mount.cifs fails but smbclient succeeds 2019-07-09 7:38 ` Fwd: " Aurélien Aptel @ 2019-07-25 13:24 ` Wout Mertens 2019-07-25 14:51 ` Wout Mertens 2019-07-25 18:51 ` Steve French 0 siblings, 2 replies; 9+ messages in thread From: Wout Mertens @ 2019-07-25 13:24 UTC (permalink / raw) To: Aurélien Aptel; +Cc: CIFS 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: mount.cifs fails but smbclient succeeds 2019-07-25 13:24 ` Wout Mertens @ 2019-07-25 14:51 ` Wout Mertens 2019-07-25 18:51 ` Steve French 1 sibling, 0 replies; 9+ messages in thread From: Wout Mertens @ 2019-07-25 14:51 UTC (permalink / raw) To: Aurélien Aptel; +Cc: CIFS 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: mount.cifs fails but smbclient succeeds 2019-07-25 13:24 ` Wout Mertens 2019-07-25 14:51 ` Wout Mertens @ 2019-07-25 18:51 ` Steve French 2019-07-25 20:58 ` Wout Mertens 1 sibling, 1 reply; 9+ messages in thread From: Steve French @ 2019-07-25 18:51 UTC (permalink / raw) To: Wout Mertens; +Cc: Aurélien Aptel, CIFS 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: mount.cifs fails but smbclient succeeds 2019-07-25 18:51 ` Steve French @ 2019-07-25 20:58 ` Wout Mertens 2019-07-25 23:22 ` Steve French 0 siblings, 1 reply; 9+ messages in thread From: Wout Mertens @ 2019-07-25 20:58 UTC (permalink / raw) To: Steve French; +Cc: Aurélien Aptel, CIFS 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: mount.cifs fails but smbclient succeeds 2019-07-25 20:58 ` Wout Mertens @ 2019-07-25 23:22 ` Steve French 0 siblings, 0 replies; 9+ messages in thread From: Steve French @ 2019-07-25 23:22 UTC (permalink / raw) To: Wout Mertens; +Cc: Aurélien Aptel, CIFS [-- 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-07-25 23:22 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAO3V83L1Q9jCLBsjHgFE1jw2PPi_sHtQz4geDKC4jEPWkhNYBg@mail.gmail.com> 2019-07-09 0:26 ` Fwd: mount.cifs fails but smbclient succeeds Wout Mertens 2019-07-09 3:05 ` Steve French 2019-07-09 7:31 ` Wout Mertens 2019-07-09 7:38 ` Fwd: " Aurélien Aptel 2019-07-25 13:24 ` Wout Mertens 2019-07-25 14:51 ` Wout Mertens 2019-07-25 18:51 ` Steve French 2019-07-25 20:58 ` Wout Mertens 2019-07-25 23:22 ` Steve French
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).