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 'email@example.com' 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.
Created attachment 13400 [details]
not working SMB2 mount request
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...
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
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.
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.
We can probably close this (I can't).
Let me finally appreciate your work on this! Didn't test it yet, but looking forward to do so.
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?
*** Bug 12951 has been marked as a duplicate of this bug. ***