Hallo Samba Experten, mein Problem entstand nach der Umstellung eines Systems von Samba 2.X auf Samba 3.X. Die vorher ordentlich angezeigten Umlaute werden nun nicht mehr richtig dargestellt. Dadurch ist auch das Wechseln in Verzeichnisse mit Umlauten im Namen über SMB nicht mehr möglich. Meine smb.conf enthält allerdings schon die folgenden drei Zeilen. unix charset = ISO-8859-15 display charset = ISO-8859-15 dos charset = 850 Es ist möglich neue Dateien mit Umlauten im Namen zu erstellen. Probleme bereiten nur die bereits vorhandenen Dateien. Neu erstellte Dateien verwenden also ein anderes Charset als das zuletzt verwendete. In der Samba 2.x config war kein Charset explizit eingetragen. Auf einem Vergleichssystem liefert mir testparm folgende Info zu den verwendeten Codepages. client code page = 850 code page directory = /etc/samba/codepages character set = die Umgebungsvariablen LOCALE sind überall nicht gesetzt. Auf dem Problemsystem sind denke ich ausserdem nicht genügen Codepages installiert. #ls -l /usr/lib/samba/charset/ total 24 drwxr-xr-x 2 root root 4096 May 25 11:35 ./ drwxr-xr-x 8 root root 4096 May 25 11:34 ../ -rwxr-xr-x 1 root root 4920 Apr 19 15:09 CP437.so* -rwxr-xr-x 1 root root 4780 Apr 19 15:09 CP850.so* Beispiel für einen bestehenden defekt angezeigten Dateinamen: ls -b W* W\224rterb\201cher ö ist also \224 und ü ist \201 nun stellt sich mir die Frage wie finde ich dazu die passende Codepage. Greetings Daniel -- Das Leben ist ein Spiel: Unwirklich, unrealistisch. Nur dass man es nicht mehr neu starten kann. Kein loeschen, kein restart, nur -=GAME OVER=-
Hallo Daniel, hallo Leute, Am Mittwoch, 25. Mai 2005 21:27 schrieb Daniel Lord:
mein Problem entstand nach der Umstellung eines Systems von Samba 2.X auf Samba 3.X. Die vorher ordentlich angezeigten Umlaute werden nun nicht mehr richtig dargestellt. Dadurch ist auch das Wechseln in Verzeichnisse mit Umlauten im Namen über SMB nicht mehr möglich.
Dein Problem setzt sich übrigens auch in Deinen Mails fort - diese enthalten diverse falsche Headerzeilen: | Content-Type: text/plain; | charset=iso-8859-1 Stimmt nicht, Deine Mail ist utf-8-codiert. | X-Message-Flag: You are using an insecure mail client which can be | used to spread viruses Stimmt auch nicht. *SCNR*
Meine smb.conf enthält allerdings schon die folgenden drei Zeilen. unix charset = ISO-8859-15
Mach da mal utf-8 draus. Irgendwie habe ich das Gefühl, dass das eher passen könnte ;-)
display charset = ISO-8859-15
Da auch utf-8.
dos charset = 850
Keine Ahnung, ob das passt - lass es aber erstmal.
Es ist möglich neue Dateien mit Umlauten im Namen zu erstellen. Probleme bereiten nur die bereits vorhandenen Dateien. Neu erstellte Dateien verwenden also ein anderes Charset als das zuletzt verwendete.
Das spricht eindeutig für ein anders eingestelltes charset. BTW: Wenn Du den Zeichensatz nicht umstellen willst, wäre die Verwendung von convmv eine gute Idee ;-)
In der Samba 2.x config war kein Charset explizit eingetragen.
... und somit galt vermutlich implizit der systemweite Zeichensatz.
die Umgebungsvariablen LOCALE sind überall nicht gesetzt.
Was spuckt der Befehl locale aus? utf-8?
Beispiel für einen bestehenden defekt angezeigten Dateinamen: ls -b W* W\224rterb\201cher
Der ist definitiv nicht uft-8-codiert. Guck ggf. mal die iso-8859-* manpages durch, ob Du das passende Charset zu diesen Zeichencodes findest.
ö ist also \224 und ü ist \201 [...]
... und zusammen mit einer kaputten Mailcodierung gibt es einen nicht sehr schmackhaften Zeichensalat. Gruß Christian Boltz -- Tja, und so hab ich wohl die beiden wichtigsten Dinge gelernt, die man IMO ueber Linux lernen kann: Wie man Doku findet, liest, verarbeitet und versteht :) Und Geduld (v.a. mit sich selbst) bzw. Durchhaltevermoegen.. [David Haller in suse-linux über seine ersten Erfahrungen mit Linux]
Hi, On Wed, 25 May 2005, Christian Boltz wrote:
Hallo Daniel, hallo Leute,
Am Mittwoch, 25. Mai 2005 21:27 schrieb Daniel Lord:
mein Problem entstand nach der Umstellung eines Systems von Samba 2.X auf Samba 3.X. Die vorher ordentlich angezeigten Umlaute werden nun nicht mehr richtig dargestellt. Dadurch ist auch das Wechseln in Verzeichnisse mit Umlauten im Namen über SMB nicht mehr möglich.
Dein Problem setzt sich übrigens auch in Deinen Mails fort - diese enthalten diverse falsche Headerzeilen:
ja, das habe ich leider auch gerade gemerk. Wobei dieses Problem unabhaengig vom Samba Server ist, da es sich um einen anderen Rechner mit anderer Distribution handelt. Wird aber auch noch gefixed.
| Content-Type: text/plain; | charset=iso-8859-1
Stimmt nicht, Deine Mail ist utf-8-codiert.
...bin noch am Schalter suchen um das ab/umzustellen.
Meine smb.conf enthält allerdings schon die folgenden drei Zeilen. unix charset = ISO-8859-15
Mach da mal utf-8 draus. Irgendwie habe ich das Gefühl, dass das eher passen könnte ;-)
display charset = ISO-8859-15
Da auch utf-8.
utf-16 ist auf dem System default. utf-8 ist aber leider nicht richtig, da ein ae oe ue dabei 2Bytes beanspruchen. In den ganzen Dateinamen kommt aber nur 1Byte vor.
Es ist möglich neue Dateien mit Umlauten im Namen zu erstellen. Probleme bereiten nur die bereits vorhandenen Dateien. Neu erstellte Dateien verwenden also ein anderes Charset als das zuletzt verwendete.
Das spricht eindeutig für ein anders eingestelltes charset. BTW: Wenn Du den Zeichensatz nicht umstellen willst, wäre die Verwendung von convmv eine gute Idee ;-)
das geht aber nur, wenn ich weiss mit welchem Zeichensatz die alten Dateinamen codiert wurden.
In der Samba 2.x config war kein Charset explizit eingetragen.
... und somit galt vermutlich implizit der systemweite Zeichensatz.
der auf POSIX stand
die Umgebungsvariablen LOCALE sind überall nicht gesetzt.
Was spuckt der Befehl locale aus? utf-8?
POSIX fuer alles LC_ALL ist leer
Beispiel für einen bestehenden defekt angezeigten Dateinamen: ls -b W* W\224rterb\201cher
Der ist definitiv nicht uft-8-codiert. Guck ggf. mal die iso-8859-* manpages durch, ob Du das passende Charset zu diesen Zeichencodes findest.
ö ist also \224 und ü ist \201 [...]
... und zusammen mit einer kaputten Mailcodierung gibt es einen nicht sehr schmackhaften Zeichensalat.
Wie gesagt, die Mailcodierung ist mir gerade eben nach einem Update meiner Desktopbox zerbroeselt und das hat nichts mit dem Serverproblem zu tun. Greetings Daniel -- Das Leben ist ein Scheiß-Adventure, aber coole Grafik.
Hallo, On Wed, 25 May 2005, Christian Boltz wrote:
Am Mittwoch, 25. Mai 2005 21:27 schrieb Daniel Lord:
Beispiel für einen bestehenden defekt angezeigten Dateinamen: ls -b W* W\224rterb\201cher
Der ist definitiv nicht uft-8-codiert. Guck ggf. mal die iso-8859-* manpages durch, ob Du das passende Charset zu diesen Zeichencodes findest.
Negativ. Es gibt weder bei den iso-8859-* zeichensätzen, noch bei den cp* Zeichensätzen passende Definitionen. Da läuft wohl etwas ziemlich schief. Das Problem hoffe ich jetzt erst mal durch ein Downgrade auf 2.X gelöst zu haben. Morgen weiß ich mehr. Mein mutt müßte auch wieder repariert sein. Einen schönen Feiertag (sofern man im "richtigen" Bundesland wohnt). Greetings Daniel -- If you think technology can solve your problems you don't understand technology and you don't understand your problems. (Marcus Ranum)
Hallo Daniel,
On Wed, 25 May 2005 21:27:23 +0200
Daniel Lord
mein Problem entstand nach der Umstellung eines Systems von Samba 2.X auf Samba 3.X. Die vorher ordentlich angezeigten Umlaute werden nun nicht mehr richtig dargestellt.
Samba 3 benutzt explizit einen bestimmten Zeichensatz (UTF-8?). Ich denke man muss die alten Dateinamen konvertieren. Siehe hierzu: http://us2.sambaInternational Language Support.org/samba/docs/man/Samba- Guide/upgrades.html#id2580690 Punkt: International Language Support und http://us2.samba.org/samba/docs/man/Samba-HOWTO-Collection/unicode.html#id26... Viele Grüße Ralf
Hallo Ralf, On Thu, 26 May 2005, Ralf Schuchardt wrote:
Ich denke man muss die alten Dateinamen konvertieren.
convmv ist mir schon bekannt. Auch wenn ich vermeiden wollte es zu benutzen. Inzwischen will ich es nutzen habe nun aber das Problem, dass die Sonderzeichen auf dem System in keiner mir bekannten Codepage zu finden sind, und ich daher auch keine "von X -> nach UTF-8" Kodierung machen kann. So wie ich das sehe wird es darauf hinauslaufen, dass ich mir ein eigenes Script schreiben muß, das mir die entsprechenden Zeichen nach einer eigenen Tabelle richtig ersetzt. Es sei denn jemand hat noch eine geniale Idee oder kennt das charset, in dem die Zeichen wie folgt gemapped sind. char octal hex ü 201 93 ä 204 96 ö 224 A8 Greetings Daniel -- One wordly wisdom: "Most people use doors, not windows."
participants (3)
-
Christian Boltz
-
Daniel Lord
-
Ralf Schuchardt