10

I am working in a primarily Windows environment.

I need to access a Windows shared drive which is known among my colleagues as "the L drive". Running net use on a Windows machine shows the UNC path of the shared drive:

Status Local Remote Network ------------------------------------------------------------------------------- L: \\ad.company.com\shared\Sites\BLAH Microsoft Windows Network

Connecting with smbclient

I'm able to browse this shared drive using smbclient (version 4.19.5-Ubuntu) with a command like the following:

$ smbclient -g -U 'COMPANY/USERNAME%PASSWORD' \ //ad.company.com/Shared -D Sites/BLAH

Adding --debuglevel 3, I'm able to verify from the verbose logs that smbclient is using normal/modern DNS-based host lookup (not NetBIOS), ntlmssp challenge-based authentication (not Kerberos), and connecting on port 445 (not the legacy port 139):

… Connecting to 10.0.12.34 at port 445 convert_string_handle: E2BIG: convert_string(UTF-8,CP850): srclen=29 destlen=16 error: No more room Connecting to 10.246.225.180 at port 139 Kinit for username@COMPANY to access SOME.OTHER.HOSTNAME failed: Cannot contact any KDC for requested realm Got challenge flags: Got NTLMSSP neg_flags=0x62898215

And indeed, I can make the connection start up little bit faster by adding these flags to the command line: smbclient -R host --port 445 --use-kerberos=off ….

Mounting with mount.cifs

Since I can browse this shared drive using smbclient, I ought to be able to mount it with mount.cifs (version 7.0).

So I try the following:

$ sudo mount --verbose -t cifs \ -o 'domain=COMPANY,username=USERNAME,prefixpath=Sites/BLAH,password=PASSWORD' \ '//ad.company.com/Shared' /mnt/l mount.cifs kernel mount options: ip=10.0.12.34,unc=\\ad.company.com\Shared,prefixpath=Sites/BLAH,user=USERNAME,domain=COMPANY,pass=******** mount error(126): Required key not available

About 80% of the time I get error(126): Required key not available, and 20% of the time running an identical command I get error(2): No such file or directory.

I'm certain that the credentials are being accepted, because I get a different error(13): Permission denied if I use incorrect credentials.

I've tried adding various other options including:

  • Adding sec=ntlmssp to explicitly set the authentication method used.
  • Adding vers=3, vers=2.1 to try specific SMB versions.
  • Removing the prefixpath=Sites/BLAH, so that I am mounting the top-level Windows share //ad.company.com/shared rather than a subdirectory thereof.
  • Removing the prefixpath, and adding it to the end of the complete UNC path, e.g. //ad.company.com/shared/Sites/BLAH; per the docs, this is simply a syntactic variant.

… but none of this makes any difference. I consistently get either Required key not available or No such file or directory.

I've checking the kernel log messages with dmesg, but they don't show anything other than the same error codes.

Question

What is smbclient doing that allows it to succeed where mount.cifs fails? How can I get mount.cifs to mount this share successfully?

Additional bits of information:

  • There are other Windows shares (on other servers) that I can mount successfully with a similar command-line, and the same credentials.
  • The variation in the error message from mount.cifs suggests to me that there's some kind of race condition happening here.

Other sources consulted

Improve this question
11
  • 1
    //ad.company.com/shared vs //ad.company.com/Shared - I know windows in most part is case insensitive, but, it's still a difference in what you are doing Commented Sep 24 at 21:51
  • @Bravo, I've tested various casing combinations with both smbclient and with mount -t cifs, and they don't appear to affect the observed behavior. For example, smbclient still works if I spell it as sHaReD, and mount -t cifs still fails in the same way. Commented Sep 24 at 23:09
  • 1
    @ChrisDavies, yes, I tried that too (as described above, "Removing the prefixpath=Sites/BLAH") and I get the same error(s) from mount.cifs: random variation between Required key not available or No such file or directory. Added a few more details to clarify that I tried these already. Commented Sep 25 at 16:36
  • 1
    are there any additional messages in dmesg? (might require CONFIG_CIFS_DEBUG to be set in kernel configuration) Commented Sep 29 at 19:22
  • 1
    are you by chance using 6.6 kernel? github.com/NixOS/nixpkgs/issues/265521 (or more generic, perhaps an issue with your dns resolver?) Commented Sep 29 at 20:05

1 Answer 1

Reset to default
6
+200

You're connecting to a domain‑based DFS namespace:

\\ad.company.com\Shared\Sites\BLAH

smbclient follows DFS referrals in user space, so it happily walks from the DFS root (\\ad.company.com\Shared) to the real fileserver that actually hosts Sites\BLAH. The kernel CIFS client used by mount.cifs must follow that DFS referral too, but on Linux it relies on keyutils + cifs.upcall for the DFS DNS resolver/SPNEGO upcalls. When those helpers aren’t available or not configured, you get:

  • mount error(126): Required key not available: the kernel asked the keyring for a dns_resolver/SPNEGO key and none was provided (ENOKEY).
  • mount error(2): No such file or directory: you reached the DFS root on the domain controller, but since the referral wasn’t followed the subpath Sites/BLAH doesn’t exist on that server.

That matches your symptoms exactly and also explains why other non‑DFS shares mount fine. Whether you hit (126) or (2) depends on how far the mount got before the missing upcall bit it. With DFS upcalls enabled, the kernel will resolve the referral and both errors should disappear.

Improve this answer
6
  • Thanks, this is interesting! In the smbclient debug logs I do see it "redirecting" to other fileservers, eventually ending up at \\SERVERFILE01.AD.COMPANY.COM\shared\Sites\Blah. However, if I use that UNC path with mount -t cifs, I still get the same error. Am I missing some other step here 🤔? Commented Sep 29 at 22:22
  • I have also tried guides like this one, putting create cifs.spnego * * /usr/sbin/cifs.upcall -c %k in my /etc/request-key.conf, as well as trying it with cifs.upcall -t. Neither of those appears to make any difference. Commented Sep 29 at 22:23
  • 1
    One possibility is your request‑key config is incomplete/outdated. The lines you tried only mention cifs.spnego and even use -c, which the current cifs.upcall ignores entirely. You also need a rule for the dns_resolver key type, because the kernel CIFS client asks userspace to resolve DFS referrals via that key. Without it you get the classic mount error(126): Required key not available. See manpage. - manpages.ubuntu.com/manpages/jammy/man8/cifs.upcall.8.html Commented Sep 29 at 23:09
  • 2
    Another possibility is you might be walking a DFS link even when you “direct mount.” \\SERVERFILE01\shared\Sites\Blah can itself contain another DFS reparse point. smbclient happily follows the whole chain; the kernel client won’t unless the dns_resolver upcall above is working. After fixing the upcalls, try mounting the DFS namespace path (let kernel follow the referral) - bash sudo mount -t cifs //ad.company.com/Shared /mnt/l \ -o prefixpath=Sites/BLAH,domain=COMPANY,username=USERNAME,password=PASSWORD,sec=ntlmssp,vers=3.1.1,port=445 Commented Sep 29 at 23:13
  • 1
    I've tried the fixes resolver fixes but unfortunately they don't make a difference in terms of overall success. I'm gonna give you the bounty, though, because I think this is on the right track and getting me appreciably closer to success. 🙏 Commented Oct 6 at 18:34

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.