Hallo
ich habe die Aufgabe per Linux-Server auch ein Backup eines Windows NT-Servers durchzuführen. Nichts leichter als das dachte ich und habe die Windows-Freigabe einfach mit
mount -t smbfs -o username=xxx,password=xxx //nt-server/d$ /mnt
auf dem Linux eingeklingt und dieses Verzeichnis mit tar aufs Band geschrieben. Da in der Fa. auch japanische Kollegen arbeiten gibt es hier ein Problem. Diese legen Verzeichnisse und Dateien mit japanischen Zeichen an (läßt sich nicht vermeiden, leider). Bei diesen bringt tar eine Fehlermeldung, dass er Datei ???? nicht öffnen kann (Da stehen wirklich die Fragezeichen, ebenso wenn man sich Diese mit ls anschaut).
Ich habe versucht durch laden der NLS-Kernelmodule für japanischen Zeichensätze, das Problem zu lösen. Hat aber nicht geholfen.
Jemannd eine Idee, wie man diese Dateien sichern kann?
Grüße aus Kamenz
On Thu, Oct 17, 2002 at 08:47:54AM +0200, Bernd Ledig wrote:
Hallo
Hi Bernd,
ich habe die Aufgabe per Linux-Server auch ein Backup eines Windows NT-Servers durchzuführen. Nichts leichter als das dachte ich und habe die Windows-Freigabe einfach mit
mount -t smbfs -o username=xxx,password=xxx //nt-server/d$ /mnt
auf dem Linux eingeklingt und dieses Verzeichnis mit tar aufs Band geschrieben. Da in der Fa. auch japanische Kollegen arbeiten gibt es hier ein Problem. Diese legen Verzeichnisse und Dateien mit japanischen Zeichen an (läßt sich nicht vermeiden, leider).
Ich kenne mich zwar weder mit Samba, Backup noch Japanisch aus, aber ich würde mal drauf tippen, das die verwendete Sambaversion noch kein utf8 beherrscht und deswegen den Dateinamen nicht versteht.
Ciao, Tobias
On Thu, 17 Oct 2002 09:52:27 +0200, Tobias Koenig wrote:
On Thu, Oct 17, 2002 at 08:47:54AM +0200, Bernd Ledig wrote:
Ich kenne mich zwar weder mit Samba, Backup noch Japanisch aus, aber ich würde mal drauf tippen, das die verwendete Sambaversion noch kein utf8 beherrscht und deswegen den Dateinamen nicht versteht.
Ich sehe an der Stelle gar kein samba.
Reinhard
am 17.10.2002, um 10:20:44 +0200 mailte Reinhard Foerster folgendes:
On Thu, 17 Oct 2002 09:52:27 +0200, Tobias Koenig wrote:
On Thu, Oct 17, 2002 at 08:47:54AM +0200, Bernd Ledig wrote:
Ich kenne mich zwar weder mit Samba, Backup noch Japanisch aus, aber ich würde mal drauf tippen, das die verwendete Sambaversion noch kein utf8 beherrscht und deswegen den Dateinamen nicht versteht.
Ich sehe an der Stelle gar kein samba.
Dann schau noch mal genau. Die Leute speichern von ihren Wixdos-Kisten ins Dateisystem von Linux.
Heiko sagte mir mal was von einem Script, was er da hat, welches rekursiv kaputte Dateinamen reparieren kann. Vielleicht kann er es ja mal posten, hätte auch Interesse daran.
Andreas
On Thu, 17 Oct 2002 11:16:32 +0200, Andreas Kretschmer wrote:
Ich sehe an der Stelle gar kein samba.
Dann schau noch mal genau. Die Leute speichern von ihren Wixdos-Kisten ins Dateisystem von Linux.
Na dann bin ich blind. Sie machen
mount -t smbfs -o username=xxx,password=xxx //nt-server/d$ /mnt
Die mounten also ein vom Windowsrechner freigegebenes Laufwerk unter Linux und speichern es auf der Linuxkiste mit tar. Da ist nur Windows und smbfs aus dem Linuxkernel im Spiel. Wo soll da samba im Spiel sein.
*grübelnd*, Reinhard
Tobias Koenig schrieb:
On Thu, Oct 17, 2002 at 08:47:54AM +0200, Bernd Ledig wrote:
ich habe die Aufgabe per Linux-Server auch ein Backup eines Windows NT-Servers durchzuführen. Nichts leichter als das dachte ich und habe die Windows-Freigabe einfach mit
mount -t smbfs -o username=xxx,password=xxx //nt-server/d$ /mnt
auf dem Linux eingeklingt und dieses Verzeichnis mit tar aufs Band geschrieben. Da in der Fa. auch japanische Kollegen arbeiten gibt es hier ein Problem. Diese legen Verzeichnisse und Dateien mit japanischen Zeichen an (läßt sich nicht vermeiden, leider).
Ich kenne mich zwar weder mit Samba, Backup noch Japanisch aus, aber ich würde mal drauf tippen, das die verwendete Sambaversion noch kein utf8 beherrscht und deswegen den Dateinamen nicht versteht.
Im Einsatz ist Debian-Linux Woody, also relativ aktuell. Ab welcher Version kann denn Samba UTF8? Hatte Wintdows NT schon UTF8 ?
Grüße aus Kamenz
On Thu, 17 Oct 2002, Bernd Ledig wrote:
Hallo
ich habe die Aufgabe per Linux-Server auch ein Backup eines Windows NT-Servers durchzuführen. Nichts leichter als das dachte ich und habe die Windows-Freigabe einfach mit
mount -t smbfs -o username=xxx,password=xxx //nt-server/d$ /mnt
probiers mal mit UTF-8: mount -t smbfs -o utf8,username=xxx,password=yyy //server/d$ /mnt
oder wars utf-8? Weiß nicht, hab hier keine mount-Manpage zur Hand, da stehts mit drin.
On Thu, 17 Oct 2002 08:47:54 +0200, Bernd Ledig wrote:
Bei diesen bringt tar eine Fehlermeldung, dass er Datei ???? nicht öffnen kann (Da stehen wirklich die Fragezeichen, ebenso wenn man sich Diese mit ls anschaut).
Wie sieht das bei "ls -b" aus?
Letzlich musst du nicht die Zeichen auf dem Linuxrechner darstellen sondern nur ins Archiv bringen und wieder richtig herstellen. Dazu ist IMO keinerlei Arbeit hinsichtlich UTF-? nötig.
Probiere mal was in Richtung find /mountpunkt -print0 | tar c --null -T - -f archive
Reinhard
Reinhard Foerster schrieb:
Wie sieht das bei "ls -b" aus?
ls -lb ergibt: total 16 drwxr-xr-x 1 root root 4096 Oct 19 2000 1????????Mechatro drwxr-xr-x 1 root root 4096 Apr 29 14:36 ???? drwxr-xr-x 1 root root 4096 Oct 16 13:49 TDDK drwxr-xr-x 1 root root 4096 Apr 29 14:50 TDDK???(CD)
also keine Änderung. Ich habe inzwischen auch probiert beim mounten Zeichensatz utf8 anzugeben:
mount -t smbfs -o iocharset=utf8,username=......
Hat aber nicht geholfen.
Letzlich musst du nicht die Zeichen auf dem Linuxrechner darstellen sondern nur ins Archiv bringen und wieder richtig herstellen. Dazu ist IMO keinerlei Arbeit hinsichtlich UTF-? nötig.
Probiere mal was in Richtung find /mountpunkt -print0 | tar c --null -T - -f archive
liefert: tar: ./TDDK/02?5\3726\3727?TDDK??????.xls: Read error at byte 0, reading 8192 bytes: No such file or directory tar: ./TDDK/02?5\3726\3727?TDDK??????.xls: Read error at byte 0, reading 4096 bytes: No such file or directory tar: ./TDDK/02?5\3726\3727?TDDK??????.xls: Read error at byte 0, reading 2048 bytes: No such file or directory tar: Error exit delayed from previous errors
Grüße
Am Donnerstag, dem 17. Oktober 2002 um 12:39:36, schrieb Bernd Ledig:
tar: ./TDDK/02?5\3726\3727?TDDK??????.xls: Read error at byte 0, reading 8192 bytes: No such file or directory
Lass mal ein fsck über die Partition laufen und teile uns deine Beobachtung mit. Ich habe eine dunkle Vermutung...
Torsten
Am Donnerstag, dem 17. Oktober 2002 um 12:39:36, schrieb Bernd Ledig:
tar: ./TDDK/02?5\3726\3727?TDDK??????.xls: Read error at byte 0, reading 8192 bytes: No such file or directory
Ignoriere meine andere Mail und versuche mal mittels smbclient diese Datei zu kopieren bzw. die Tar-Datei mit smbtar zu erstellen.
Torsten
Torsten Werner schrieb:
Am Donnerstag, dem 17. Oktober 2002 um 12:39:36, schrieb Bernd Ledig:
tar: ./TDDK/02?5\3726\3727?TDDK??????.xls: Read error at byte 0, reading 8192 bytes: No such file or directory
Ignoriere meine andere Mail und versuche mal mittels smbclient diese Datei zu kopieren bzw. die Tar-Datei mit smbtar zu erstellen.
Und hier das Ergebnis:
backupsrv:/tmp# smbclient //nt-server/f$ -U backup added interface ip=172.20.47.250 bcast=172.20.47.255 nmask=255.255.255.0 Got a positive name query response from 172.20.47.2 ( 172.20.47.2 ) Domain=[TDDK.DE] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0] smb: > cd User smb: \User> cd Hagio smb: \User\Hagio> mget *.xls Get file 7S_CY.xls? y NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \User\Hagio\7S_CY.xls
smb: \User\Hagio> tar c /tmp/t.tar . directory \User\Hagio\Hagio\ NT_STATUS_OBJECT_NAME_NOT_FOUND listing \User\Hagio\Hagio* tar: dumped 1 files and directories Total bytes written: 0
Im syslog tauchen Meldungen wie folgt auf: Oct 17 15:11:45 backupsrv kernel: smb_open: Hagio/??????.xls open failed, result=-2 Oct 17 15:11:45 backupsrv kernel: smb_open: Hagio/??????.xls open failed, result=-2 Oct 17 15:11:45 backupsrv kernel: smb_readpage_sync: Hagio/??????.xls open failed, error=-2
Als scheint das Problem beim smbfs-Packet zu liegen. Aber wie lösen?
Grüße aus Kamenz
Am Donnerstag, dem 17. Oktober 2002 um 13:35:55, schrieb Bernd Ledig:
NT_STATUS_OBJECT_NAME_NOT_FOUND opening remote file \User\Hagio\7S_CY.xls
Ich vermute, dass aufgrund des japanischen Multibyte-Zeichensatzes unerlaubte Zeichen im Pfadnamen vorkommen, die auf einem japanischen Windows korrekt dekodiert werden. Einen guten Tipp kann ich dir nicht geben, außer dein Glück auf einer japanischen Mailingliste zu probieren (auf englisch natürlich).
Torsten
Am Donnerstag, dem 17. Oktober 2002 um 13:35:55, schrieb Bernd Ledig:
Als scheint das Problem beim smbfs-Packet zu liegen. Aber wie lösen?
Ähm, hast du in smb.conf(5) den Abschnitt zu 'client code page' gelesen und im Kernel CONFIG_NLS_CODEPAGE_932 und CONFIG_NLS_UTF8 aktiviert?
Torsten
Torsten Werner schrieb:
Am Donnerstag, dem 17. Oktober 2002 um 13:35:55, schrieb Bernd Ledig:
Als scheint das Problem beim smbfs-Packet zu liegen. Aber wie lösen?
Ähm, hast du in smb.conf(5) den Abschnitt zu 'client code page' gelesen und im Kernel CONFIG_NLS_CODEPAGE_932 und CONFIG_NLS_UTF8 aktiviert?
Die Kernel-Module für diese Codepages sind geladen. Unklar ist mir der Einfluß der smb.conf auf smbmount. Auf dem Backup-Server läuft ja selber kein Samba.
Am Donnerstag, dem 17. Oktober 2002 um 15:27:28, schrieb Bernd Ledig:
Die Kernel-Module für diese Codepages sind geladen.
Du musst beim mounten natürlich noch die Option codepage=932 oder so setzen.
Unklar ist mir der Einfluß der smb.conf auf smbmount.
Keinen, es hat aber Einfluss auf smbclient.
Torsten
On Thu, 17 Oct 2002 08:47:54 +0200, Bernd Ledig wrote:
ich habe die Aufgabe per Linux-Server auch ein Backup eines Windows NT-Servers durchzuführen.
...
Da in der Fa. auch japanische Kollegen arbeiten gibt es hier ein Problem.
Hast du es nun hinbekommen? Die Lösung würde mich interessieren.
Reinhard
Reinhard Foerster schrieb:
On Thu, 17 Oct 2002 08:47:54 +0200, Bernd Ledig wrote:
ich habe die Aufgabe per Linux-Server auch ein Backup eines Windows NT-Servers durchzuführen.
...
Da in der Fa. auch japanische Kollegen arbeiten gibt es hier ein Problem.
Hast du es nun hinbekommen? Die Lösung würde mich interessieren.
Nein, bis jetzt noch nicht. Ich habe noch als Lösungsmöglichkeit rsync ausprobiert. Auf der NT-Kiste das rsync installiert und von dort aus versucht die Dateien auf die Linux-Kiste zu übertragen. Es trat da selbe Problem auf, das rsync die japanischen Dateien nicht öffnen konnte. In diesem Zusammenhang ist mit aufgefallen, das noch nicht einmal die Microsoft eigenen Kommandozeilen-Tools damit umgehen können. Auch ein einfaches copy *.* nul schlägt bei diesen Dateien fehl, so dass ich annehmen muss, dass schon die NT-Kiste nicht richtig konfiguriert ist oder NT das eben nicht vernüftig handeln kann (Erstaunlicher Weise kann der Dateiexplorer diese Dateien kopieren, er zeigt sie mit senkrechten Strichen an). Da in ca. 14 Tagen ein IT-Fachmann aus Japan vorbeikommt, werde ich diesen mal löchern.
Grüße aus Kamenz
On Mon, 21 Oct 2002, Bernd Ledig wrote:
Reinhard Foerster schrieb:
On Thu, 17 Oct 2002 08:47:54 +0200, Bernd Ledig wrote:
Da in der Fa. auch japanische Kollegen arbeiten gibt es hier ein Problem.
Hast du es nun hinbekommen? Die Lösung würde mich interessieren.
Nein, bis jetzt noch nicht.
[gelöscht]
nicht öffnen konnte. In diesem Zusammenhang ist mit aufgefallen, das noch nicht einmal die Microsoft eigenen Kommandozeilen-Tools damit umgehen können. Auch ein einfaches copy *.* nul schlägt bei diesen Dateien fehl, so dass ich annehmen muss, dass schon die NT-Kiste nicht richtig konfiguriert ist oder NT das eben nicht vernüftig handeln kann (Erstaunlicher Weise kann der Dateiexplorer diese Dateien kopieren, er zeigt sie mit senkrechten Strichen an).
Da geht es Dir ja schon ganz gut. Bei mir wollte Win98 nicht mal im Explorer ein paar Dateien mit russischen Namen kopieren. Soviel zu Unicode-Unterstützung in Win.
Da in ca. 14 Tagen ein IT-Fachmann aus Japan vorbeikommt, werde ich diesen mal löchern.
Das einfachste wäre wohl: Wie kriegt man NT und Samba dazu Dateien im Unicode (UTF-8/UCS2) auszutauschen?
Tobias
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Bernd Ledig -
Reinhard Foerster -
Tobias Koenig -
Tobias Schlemmer -
Torsten Werner