Bug 8746 - can't mount cifs share with password containing extended characters
Summary: can't mount cifs share with password containing extended characters
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: user space tools (show other bugs)
Version: 2.6
Hardware: x64 Linux
: P5 normal
Target Milestone: ---
Assignee: Jeff Layton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-07 09:40 UTC by Thanos
Modified: 2012-05-22 10:28 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thanos 2012-02-07 09:40:33 UTC
Hello,

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:
Domain WORKGROUP
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:
username=test
password=üöäWSX3edc
domain=WORKGROUP

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?

Best regards
Comment 1 Jeff Layton 2012-04-06 11:50:44 UTC
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.
Comment 2 Thanos 2012-05-22 09:33:46 UTC
(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.

Hi Jeff,

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!

Best regards
Comment 3 Jeff Layton 2012-05-22 10:28:21 UTC
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.