Bug 12917 - CIFS SMB2/SMB3 does not work for domain based DFS
Summary: CIFS SMB2/SMB3 does not work for domain based DFS
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 3.x
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Steve French
QA Contact:
: 12951 (view as bug list)
Depends on:
Reported: 2017-07-19 07:38 UTC by support
Modified: 2020-07-23 12:39 UTC (History)
6 users (show)

See Also:

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 ( 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...
Comment 3 Emanuel 2017-11-08 10:22:43 UTC

Same problem with me. I had our DFS shares mounted with the parameter "vers=3.0" but after the update it only worked with "vers=1.0".

If I try to mount against the domain. If I mount the server directly it still works with "vers=3.0".

I am using Samba 4.7.1-1 on a kernel 4.13.11-1
Comment 4 Aurélien Aptel 2018-01-18 10:49:18 UTC
I have sent a patch upstream to fix this. Any feedback from people having the issue is welcome. I have some minor things to change but this should already work.

Comment 5 Aurélien Aptel 2018-02-01 14:46:14 UTC
Fix was merged upstream and should be in the next kernel update. Ask your distribution maintainers to backport it. I'm doing it for SUSE products.
Comment 6 Aurélien Aptel 2018-02-08 15:59:56 UTC
We can probably close this (I can't).
Comment 7 support 2018-02-09 08:27:18 UTC
Let me finally appreciate your work on this! Didn't test it yet, but looking forward to do so.
Comment 8 Nathan Neulinger 2018-03-05 18:00:00 UTC
Aurélien Aptel, is there any possibility of you backporting the smb2/smb3 support to 4.4 series kernels to get compatibility with Ubuntu 16?
Comment 9 Aurélien Aptel 2020-07-23 12:39:12 UTC
*** Bug 12951 has been marked as a duplicate of this bug. ***