When attempting to mount (mount.cifs version 7.0) a share using
$ mount -t cifs -o
vers=3.1.1,cred=/home/u/.secret.txt,uid=1000,gid=100
//smb.server.example.com/scans /home/u/mnt
it succeeds on 6.5.9:
mount("//smb.server.example.com/scans", ".", "cifs", 0,
"ip=192.168.5.43,unc=\\\\smb.server.example.com\\scans,vers=3.1.1,uid=1000,gid=100,user=u,pass=mypassword")
= 0
but fails on 6.0.0:
mount("//smb.server.example.com/scans", ".", "cifs", 0,
"ip=192.168.5.43,unc=\\\\smb.server.example.com\\scans,vers=3.1.1,uid=1000,gid=100,user=u,pass=mypassword")
= -1 ENOKEY (Required key not available)
(or ENOENT) though it still works with using the IP instead of the domain:
mount("//192.168.5.43/scans", ".", "cifs", 0,
"ip=192.168.5.43,unc=\\\\192.168.5.43\\scans,vers=3.1.1,uid=1000,gid=100,user=u,pass=mypassword")
= 0
Based on my reading ever since 348a04a ("smb: client: get rid of dfs
code dep in namespace.c") dfs_mount_share() is now calling
dns_resolve_server_name_to_ip() early and unconditionally. This can be
verified on a running system by enabling dns_resolver logging (echo 1
| sudo tee /sys/module/dns_resolver/parameters/debug + watch dmesg).
An additional DNS lookup is attempted in 6.0.0 that previously wasn't.
My best guess is that ENOENT is "didn't work" and ENOKEY means "didn't
work but cached".
On my system the request-key mechanism is not set up so this fails.
I'm no expert on SMB so I don't know if things just happened to work
previously by me relying on a bug but this change broke my setup. Is
this expected?
