Posted Friday, 06-Dec-2013 by Ingo Karkat
Shortly after upgrading my secondary development workstation from Ubuntu 13.04 to the latest 13.10 release, I noticed that I couldn't mount shares served from my Windows development workstation any more. Instead, it just came back to me with:
mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs).
Other Windows systems were able to access the share, so the problem must have been with Linux or that particular system. A brief search of the web showed me how to connect in a different way, through the ftp-like smbclient tool:
Interestingly, this worked well. So, I suspected that the operating system upgrade had broken the mount.cifs command. Fortunately, I had two sets of Ubuntu VMs, one already upgraded, the other not. And indeed, the upgraded VM couldn't connect, whereas the older operating system had no problems.
Alright, so what kind of permissions problem do I have when it's not the password itself? My first attempts were various values of the security mode option, e.g. mount -o sec=ntlmv2 (assuming some default had changed), but none worked. As I was running out of ideas with the mount command, I turned to the Windows server side in desparation. In Event Viewer, under Windows Logs > Security, I found the entries for successful and unsuccessful connections (under Task Category = Logon).
The /Details\ tab offers access to the full Event entry in XML format. I grabbed the text of both, and compared them in my preferred editor, GVIM:
Suddenly, I had a hot lead: The unsuccessful connection attempt includes the machine's domain in the username (TargetUserName), and wrongly defaults to the machine's domain (TargetDomainName). Such a user doesn't exist in that wrong domain, and therefore the authentication fails!
Because of my perusal of man mount.cifs during troubleshooting, I was already aware of the domain= mount option, but I hadn't used it in my original mount command:
$ mount -t cifs -o username=host\\user ...
Instead, the domain must now be passed separately:
$ mount -t cifs -o domain=host,username=user ...
Here's both the wrong and right invocation side by side once more:
I was happy to have that resolved, so that I could continue with my work, but still, this left a bitter taste. Wasn't there a better way?
Strictly speaking, the mount.cifs tool is right: The authentication failed. The man page even explicitly mentions the deprecation under the username option:
Earlier versions of mount.cifs also allowed one to specify the username in a "user%password" or "workgroup/user" or "workgroup/user%password" to allow the password and workgroup to be specified as part of the username. Support for those alternate username formats is now deprecated and should no longer be used. Users should use the discrete "password=" and "domain=" to specify those values.
So, am I supposed to read the manual entries for all used (and defaulted) options of every command involved?! That's not practical. I think the tool could have easily detected this deprecated use. Had it offered a better error message, an hour of troubleshooting would have been prevented. (And I wouldn't have to write up this blog entry in the hope of accelerating that process for other poor souls who'll inevitably stumble on the same problem.)
mount error(13): Permission denied Use of combined "user%password" or "workgroup/user" or "workgroup/user%password" syntax for the "username=" option are deprecated now; please adapt the value. Refer to the mount.cifs(8) manual page (e.g. man mount.cifs).
I'm also worried that the smbclient command still allows the combined syntax, so there's now an inconsistency among closely related tools in the same release.
Whatever the reasons for the deprecation; this is a reminder that API changes which break backwards compatibility are a delicate area, and should best be handled with the utmost in care, precise and highly visible documentation (preferably listing the reasons for the change, too), and explicit checks and warnings for the deprecated use (at least for some considerable timespan).
Ingo Karkat, 06-Dec-2013
ingo's blog is licensed under Attribution-ShareAlike 4.0 International
