I need to mount a CIFS share (in the end via fstab, for now manually
from terminal) which has both a space and a german umlaut in its name. I
cannot get mount.cifs to mount it, it always complains it cannot find it. Mounting from windows or from nautilus works, however.
I managed to get around the space problem in fstab with the \040 trick,
but I cannot find a way to correctly encode the umlaut. When looking at
the output of "mount.cifs --verbose '//server/Täst Freigabe' /mnt", it
looks like it is accessing the correct share, but it does not work.
I also got a hint here
pipe the share name through iconv, but "mount.cifs $(echo //server/Täst
Freigabe | iconv -t850) /mnt" also does not work.
What can I do? Changing the share name is currently not an option, there
are just too many users with links/bookmarks to it.
Additional info as requested from Günter attached
$ sudo mount.cifs "//mail/Täst Freigabe" /mnt -o user=ah --verbose
mount.cifs kernel mount options: unc=//mail\Täst Freigabe,ver=1,user=ah,ip=172.16.9.3,pass=********
mount error(6): No such device or address
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
$ mount.cifs -V
mount.cifs version: 1.12-3.4.7
$ modinfo cifs
description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
author: Steve French <email@example.com>
vermagic: 2.6.32-25-generic SMP mod_unload modversions 586
parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 (int)
parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (int)
parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (int)
parm: cifs_max_pending:Simultaneous requests to server. Default: 50 Range: 2 to 256 (int)
$ smbclient -L //mail -U ah
Domain=[AG] OS=[Unix] Server=[Samba 3.4.8]
$ printenv | egrep "(LANG|LC)"
Created attachment 6088 [details]
Wireshark trace of unsuccessful attempt using mount.cifs
Created attachment 6089 [details]
Wireshark trace of successful attempt using windows
Created attachment 6090 [details]
Wireshark trace of successful attempt using nautilus
Forgot to mention this is on Ubuntu 10.04 LTS, with the server being Debian 5.0.
I also tried using mount.cifs from cifs-utils 4.7 built from source, but nothing obvious changed.
It looks like we're translating the a + umlaut incorrectly here. One big difference is that cifs isn't capitalizing it before sending the request but windows and nautilus do.
Does this work better if you capitalize the entire sharename first? That is, could you try mounting this instead?
No, capitalizing does not work. Wireshark dump shows the UNC path is now translated to \\MAIL\T?\344ST FREIGABE, but that still doesn't work.
when i look at my own network sniff, the tcon tree name is *correctly*
filled in here in UCS.
So the question is, why the mapping from the local character set
to ucs is not working on your side.
When no "iocharset" mount option is specified, cifs internally uses
to set the mapping.
This default kernel nls charset is set with e.g.
in the kernel build (inside .config).
The string "Täst" is coded in utf8 and ucs as:
T | ä | s | t
UTF8: 0x54 | 0xc3 0xa4 | 0x73 | 0x74 (so "ä" needs 2 bytes)
UCS: 0x54 0x00 | 0xe4 0x00 | 0x73 0x00 | 0x74 0x00 (ucs on the wire)
The interesting part in your error case is, that *both* bytes from
the UTF8 char "ä" are converted to ucs - which is just simply wrong:
T | ä | s | t
UTF8: 0x54 | 0xc3 0xa4 | 0x73 | 0x74
UCS: 0x54 0x00 | 0x1c 0x25 0xf1 0x00 | 0x73 0x00 | 0x74 0x00
So what kind of mapping is done here?
0xc3 ---> 0x1c 0x25 (This resulting unicode sequence is really strange)
0xa4 ---> 0xf1 0x00
Anyway, this doesn't look like utf8 to ucs mapping at all.
Andreas, what do you get with the following?
wc -c <enter>
Here i get:
Or this one:
echo Täst > utf8.txt
hexdump -C utf8.txt
00000000 54 c3 a4 73 74 0a |T..st.|
You can also try to force cifs to use utf8 mapping by using
the "iocharset=utf8" mount option.
Atm i've no further ideas.
Good catch on the difference in the length Gunther...
Yes, I think the problem may be some sort of character set mismatch. Could you tell me what CONFIG_NLS_DEFAULT is set to on your kernel?
.config of my current kernel build contains
One must take care that the corresponding module (or build-in) is also set:
Normally a lot of NLS modules are set active.
A nice site about "UTF-8 encoding table and Unicode characters":
Right, I assume that Gunther's default mapping is "correct". I'm more curious if there's a mismatch in Andreas' rig.
Thanks for working on this so hard. But I'll have to wait until monday to try anything out, as this is at work.
I was just thinking about this a bit more... how to get your results
on a "plain vanilla linux kernel"... like the one i also use.
I think i now know what's going on.
When i force cifs to use a different character mapping with:
mount.cifs //server/share /mnt -o user=gk,iocharset=cp437
i get the same ucs mess on the wire like you.
Brad Hards (bradh) on the samba irc channel was so kind to install
the kernel source on his kubuntu 10.04 LTS machine.
was set on his machine.
Andreas, I'm sure when you use
mount.cifs '//mail/Täst Freigabe' /mnt -o user=ah,iocharset=utf8
all will work as expected.
So, regarding cifs one could say "it's NOTABUG" ...
Cause other linux file systems also use
the side-effects of this CONFIG_NLS_DEFAULT setting should be
made available to a broader audience.
Andreas, would you please be so kind to open a bug with
It's really strange that they still use cp437 these days.
As jlayton noted on irc (regarding UTF8):
"especially given that they have libc set up for it"
Only for kernel hackers. The usage of CONFIG_NLS_DEFAULT inside
the kernel source tree:
What the *****?!? It works with iocharset=utf8, you're completely right. Well, I will certainly open that bug report with the Ubuntu kernel, but I'm somewhat disappointed now. I thought Ubuntu was one of the first distros with complete UTF-8 support, but it seems they missed something here.
Please keep this report open for a moment so I can post the link to the Ubuntu bug here for documentation.
Ok, reassigning to Kukks since he did the heavy lifting on this.
I'm going to go ahead and mark the bug as INVALID. You should still be able to reference this bug in the Ubuntu bug report. Please reopen it if we need to discuss it further.