Bug 12917 - CIFS SMB2/SMB3 does not work for domain based DFS
CIFS SMB2/SMB3 does not work for domain based DFS
Status: NEW
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
3.x
All All
: P5 normal
: ---
Assigned To: Steve French
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-19 07:38 UTC by support
Modified: 2017-09-25 13:12 UTC (History)
3 users (show)

See Also:


Attachments
working SMB1 mount request (14.61 KB, application/vnd.tcpdump.pcap)
2017-07-19 07:38 UTC, support
no flags Details
not working SMB2 mount request (3.57 KB, application/vnd.tcpdump.pcap)
2017-07-19 07:39 UTC, support
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description support 2017-07-19 07:38:17 UTC
Created attachment 13399 [details]
working SMB1 mount request

I am having problems mounting a domain based DFS share using mount.cifs with the parameter vers=2.0 or vers=3.0, even though it works with the deprecated version vers=1.0.

My test setup includes two separated Windows 2016 servers (180days eval iso), with the following roles:

* on the first I'm running the domain controller (DC)
* on the second VM I installed the DFS Namespace Root role (DFSN) and this VM also serves the actual shares

Now, when trying to mount, the following error occurs:

mount //rwe.corp3/files/sales /smb -o user=Administrator,password=xxxxxx,vers=3.0

CIFS VFS: BAD_NETWORK_NAME: \\rwe.corp3\files CIFS VFS: session ffff88003bd0c000 has no tcon available for a dfs referral request CIFS VFS: cifs_mount failed w/return code = -2

It's working fine, with SMB1. It does also work, when I specify the DFSN server directly:

mount //filer3/files/sales /smb -o user=Administrator,password=xxxxxx,vers=3.0

From my point of view it looks like there is no resolution attempt of resolving the domain based UNC (//rwe.corp3/files) into the actual dfsroot representation.

Since my domain controller doesn't host the dfsroot structure, any attempts resolving on it directly will fail.

I tried initially with Kernel 4.11 but also build a recent 4.13 with the same issues.
Latest keyutils (/sbin/key.dns_resolver) are in place and configured on the system.

Do you need any further scripts/explanations how I set up the test servers? It's nothing special, everything sticks to the defaults.


This report is a copy of the original message to 'linux-cifs@vger.kernel.org' http://marc.info/?l=linux-cifs&m=150037483209870&w=2
I just adapted the host and domain name, to be aligned with the network capture.
Comment 1 support 2017-07-19 07:39:09 UTC
Created attachment 13400 [details]
not working SMB2 mount request
Comment 2 Aurélien Aptel 2017-09-25 13:12:34 UTC
Updating with my mailing list reply ( https://marc.info/?l=linux-cifs&m=150100251526241 )

  In both traces cifs.ko connects to the DC and tries to connect to the
  "files" share. Since the "files" share is not hosted on the DC, the
  server replies with BAD_NETWORK_NAME error. It then connects to the IPC$
  share regardless of the result (in get_dfs_path() I suspect).

  SMB1 uses IPC$ to make the request whereas SMB2 does a ioctl on any
  valid tcon object from the session. It finds none since the connection
  to the share "files" failed.

  I'm surprised it even works for SMB1 since you are saying the DFSN
  server is not on the DC. In the SMB1 trace we can see cifs.ko connects
  to the DC (10.0.9.56) and sends a DFS request to it (in #17) which the
  DC sucessfully replies to (#18).

  In order for the SMB2 code to be able to use the IPC$ share aswell we
  need to make SMB2_ioctl() work when tcon is NULL and use_ipc is true
  (probably by passing a session pointer as an extra arg). Looks like a
  nasty refactoring is needed...