Probably not easy to solve I think.
cifs client needs to encode/decode correct bytestream / bytesequence o=
n the
wire by taking into consideration the charset used by cifs client even =
when
unicode is not negotiated.
If iocharset is specified, it should honour that mount option for non-u=
nicode
case also.
Basically, decode/encode of received/sent bytestream / bytesequence on =
the
wire should happen in both the cases - unicode and non-unicode - based =
on
iocharset if specified as a mount option or default charset when iocha=
rset
is not specified as a mount option.
With UCS-2LE encoding, we know every unicode character on the wire is t=
wo bytes
long but without unicode, we do not know how many btyes long is each ch=
aracter,
server could be using multi-byte/variable bytesize charset.
So one option would be to use another mount option codepage to specify
the charset used at the server and use the charset specified with the
codepage mount option. If server does not support unicode and codepage
option is not specified, consider utf8 as a default charset on the serv=
er.
I think Jeff Layton had proposed such ideas/solution before and probabl=
y has/ha
some related code also, not sure, will try to look for that code.
Hy,
I tried creating a new file, and as I write it correctly, it appears =
garbled
in "ls".
So, I hadn't though about this, but he files were created locally in =
a FAT32
volume.
I did some research and it appears the most probable cp is 1252 (I'm =
in
# mount -t cifs //192.168.1.253/Disk_a1 /shared/ahgora --verbose -o
user=3Duser,pass=3D"",uid=3D1000,gid=3D1000,iocharset=3Dcp1257
ip=3D192.168.1.253,unc=3D\\192.168.1.253\Disk_a1,iocharset=3Dcp1257,u=
id=3D1000,gid=3D1000,user=3Duser,pass=3D********
mount error(79): Can not access a needed shared library
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
I also tried cp860 and cp 1250, but the accented characters were kept=
as
weird symbols.
I didn't quite get how iocharset would solve this, as by you're exper=
iment,
the server seems not to support UTF.
iocharset
Charset used to convert local path names to and from Unico=
de.
Unicode is used by default for network path names if the server suppo=
rts
it. If iocharset is not specified then the nls_default spe=
cified
during the local client kernel build will be used. **If server does n=
ot
support Unicode, this parameter is unused**.
Since smbclient seems to be doing the conversion correctly, isn't it
possible to just "ask it" which conversion it is doing?
Thanks
Post by Steve FrenchTook a Samba server, and set "unicode=3Dfalse" in smb.conf
mounted to the server from cifs and verified that Unicode is not bei=
ng
Post by Steve Frenchsent
created some files locally with Spanish characters in the directory
"test" and as expected the special characters were mapped to '?' (se=
e
Post by Steve Frenchthe ls of /mnt1/test)
/home/sfrench/test/123=C3=A1a=C3=A9b=C3=ADc=C3=B3d=C3=BAe=C3=BCf=C3=B1=
g=C2=BFh=C2=A1
Post by Steve French/home/sfrench/test/=C3=A1a=C3=A9b=C3=ADc=C3=B3d=C3=BAe=C3=BCf=C3=B1g=
=C2=BFh=C2=A1
Post by Steve French123=E2=94=9C=C3=ADa=E2=94=9C=C2=AEb=E2=94=9C=C2=A1c=E2=94=9C=E2=94=82=
d=E2=94=9C=E2=95=91e=E2=94=9C=E2=95=9Df=E2=94=9C=E2=96=92g=E2=94=AC=E2=94=
=90h=E2=94=AC=C3=AD =E2=94=9C=C3=ADa=E2=94=9C=C2=AEb=E2=94=9C=C2=A1c=E2=
=94=9C=E2=94=82d=E2=94=9C=E2=95=91e=E2=94=9C=E2=95=9Df=E2=94=9C=E2=96=92=
g=E2=94=AC=E2=94=90h=E2=94=AC=C3=AD
Post by Steve French/mnt1/test/123?a?b?c?d?e?f?g?h? /mnt1/test/?a?b?c?d?e?f?g?h?
123=C3=A1a=C3=A9b=C3=ADc=C3=B3d=C3=BAe=C3=BCf=C3=B1g=C2=BFh=C2=A1 =C3=
=A1a=C3=A9b=C3=ADc=C3=B3d=C3=BAe=C3=BCf=C3=B1g=C2=BFh=C2=A1
Post by Steve Frenchunmounted and the mounted with "iocharset=3Dcp850" on the client.
Created the files over the remote mount in /mnt1/test1 and it worked
fine and the Spanish characters were visible (locally in ~/test1 tho=
se
Post by Steve Frenchsame filenames are not easily visible since the characters map
differently).
So ... it looks like if files were created on a mount with the right
code page (iocharset=3Dcp850 in my case) then you should be able to
create and read them fine remotely.
To clarify - we need to experiment with setting "unicode=3Dfalse" i=
n a
Post by Steve Frenchnormal Samba server's smb.conf and experiment with client mount
options to see if it can be reproduced
First strange thing is why isn't the server negotiating Unicode - =
that
Post by Steve Frenchis unusual these days
Negotiating unicode (UCS-2) the way like most every other server w=
ould
Post by Steve Frenchavoid this issue
Looking at the trace we are not setting the Unicode flag on SMB
FindFirst
presumably because it was not offered at SMB tree connect time. W=
e
Post by Steve Frenchalways set it in the normal case when the server supports Unicode =
(see
Post by Steve Frenchbelow)
265 if (treeCon->ses) {
266 if (treeCon->ses->capabilities & CAP_UNICODE)
267 buffer->Flags2 |=3D SMBFLG2_UNICODE;
So without Unicode we have to set the code page manually. The ser=
ver
Post by Steve Frenchis way too old (10 years?) for us to mount smb2 (which would force
unicode on the wire) or to use Unix Extensions (which probably
requires at least 3.0 Samba to be useful).
Haven't tried iocharset and codepage mount options recently
(presumably the way to experiment with this is to turn off Unicode=
in
Post by Steve FrenchSamba smb.conf via unicode=3Dfalse)
Post by adcromitusPost by stevePost by adcromitusHello again,
Sorry for the long time to reply.
I've been going around on how to do this. I set up Wireshark an=
d saw
bout
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromituswhat
I should send here.
Anyway I did a "ls" on a dir with a file named "Cole=C3=A7=C3=A3=
o", and
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromituswireshar
captured "cole \247 \243o". I send a few frames from tcpdump wh=
ere
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitusthat
happens.
How can I see if my distro defaults to UTF-8 on the client?
Linux kernel 3.2.0-4-amd64
(Debian Wheezy)
mount.cifs version: 5.5
Thanks in advance.
This seems strange because modern Linux distributions should m=
ap
Samba
one
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitusfor
local.
Does you distro not default to UTF-8 on the client?
Would be helpful to see a wire trace (ethereal or tcpdump) and=
make
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitussure the server is sending UCS-2 (Unicode) on the wire. See
https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting
com>
tory.
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitusI have a router (that I got from my ISP) which allows the
connection
of a
pen/HDD by USB. That pen is shared on the network as a Window=
s
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitusShare
folder.
In Windows 7 I can see all the files name correctly, but when=
I
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitusmount
the
mount -t cifs //<local share ip-address>/<shared-folder> --ve=
rbose
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitus-o
user=3Duser,pass=3D"",uid=3D1000,gid=3D1000
(there is no password)
All file names with special characters (like =C3=87=C3=A3=C3=B5=
=C3=A9...) have a
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitusquestion
mark
in place of the accented character and I can't open the file =
or
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitusfolder, as
any command responds the file doesn't exist. This happens in
dolphin,
thunar
and in the command line with simple commands like cat.
I tried adding the following option without success
iocharset=3Dutf-8
iocharset=3Dutf-8,codepage=3Dcp437
iocharset=3Dutf-8,codepage=3Dcp850
iocharset=3Diso8859-1
This also happens if I access the share from my android devic=
e, so
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitusI
was
convinced it was a problem related to old firmware (from the router).
However, recently I connected to the drive using smbclient an=
d the
lder
Post by Steve FrenchPost by adcromitusPost by stevePost by adcromitusat
fstab,
and so smbclient is not a good solution.
Linux kernel 3.2.0-4-amd64
(Debian Wheezy)
mount.cifs version: 5.5
(smbclient version 4.1.11-Debian)
Server=3D[Samba 2.2.12]
So. Is there something else I can try?
Thanks in advance.
Hi
avi=C3=B1=C3=B3n
bar=C3=A7a
HTH,
Steve
Hy Steve,
So I used chroot to install the cifs-utils version from Debian ne=
xt
Post by Steve FrenchPost by adcromitusrelease
(cifs-utils v.6.4), and the result was the same as with my curren=
t
Post by Steve FrenchPost by adcromitusversion.
Does the tcpdump helped in any way?
Thanks again.
Post by stevePost by adcromitus--
To unsubscribe from this list: send the line "unsubscribe
linux-cifs"
in
More majordomo info at http://vger.kernel.org/majordomo-info.=
html
Post by Steve French--
Thanks,
Steve
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs"=
in
More majordomo info at http://vger.kernel.org/majordomo-info.html