The Samba-Bugzilla – Bug 8746
can't mount cifs share with password containing extended characters
Last modified: 2012-05-22 10:28:21 UTC
I want to mount a CIFS share as a specific user but the user’s password contains extended characters (e.g. üöä).
The command I issue is:
mount -t cifs \\\\XXXX.XXX.XXX.XXX\\test\\ /mnt/tmp --verbose -o credentials=/root/credentials
And the output I get is:
mount.cifs kernel mount options: unc=// XXXX.XXX.XXX.XXX \test,user=test,domain=WORKGROUP,ver=1,credentials=/root/credentials,ip=10.80.239.216,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)”
The credentials file is:
The machine I’ve tested it is dom0 in XenServer, CIFS version 1.14-3.5.4-0.83.el5_7.2. I’ve also tried it at a 10.10 Ubuntu with CIFS version 1.12-3.4.7 and I get the same problem.
I’ve verified that I can connect to the test share using Windows 7, GNOME Nautilus, and smbclient.
Escaping the extended characters by prefixing them with ‘\’ doesn’t work, neither by enclosing the password in “...”.
Is this a CIFS error or is it mount’s fault?
What kernel are you using here?
mount.cifs simply treats the password field as an opaque string and doesn't try to interpret it.
As a first step, I'd verify whether mount.cifs is sending the password to the
kernel correctly. Do something like this:
# strace -f -s 256 -e mount mount -t cifs //XXX.XXX.XXX.XXX/test ...
and then find the mount syscall and ensure that the password in it is being
passed in correctly.
(In reply to comment #1)
> What kernel are you using here?
> mount.cifs simply treats the password field as an opaque string and doesn't try
> to interpret it.
> As a first step, I'd verify whether mount.cifs is sending the password to the
> kernel correctly. Do something like this:
> # strace -f -s 256 -e mount mount -t cifs //XXX.XXX.XXX.XXX/test ...
> and then find the mount syscall and ensure that the password in it is being
> passed in correctly.
I'm using 2.6.32-39-generic (Ubuntu 10.04 LTS). I've tried that on Debian Wheezy (kernel 2.6.32-39-generic) and it works, so I suppose it got fixed in some release.
Is this a kernel or a cifs issue? My goal is to make it work on dom0 of XenServer (a patched 2.6.32 kernel).
Do you happen to know in which version this got fixed? I could as well release a patch that back-ports this fix!
Probably a kernel issue. The mount helper is pretty "dumb" and pretty much treats the password as a blob of data, but it might be easier to try the latest version of mount.cifs on your Xen kernel and see if it helps.
Shirish did a fairly major overhaul to the auth crypto code a year or so ago, so that might be where it got fixed. Tracking down what really fixed it for you might mean running a bisect however.
I'll go ahead and close this as FIXED.