rsync ermöglicht die einfache Synchronisation von Dateien zwischen zwei Computern.
Der Übertrag funktioniert zuverlässig jedoch gibt es zwischen Mac OS X und Linux ein Problem mit den Umlauten, das zum Fehler code 23 führen kann.
Möchte man von einem Apple PC mit Mac OS X und rsync Dateien auf einen Linux-Server oder auch die andere Richtung übertragen, wird wahrscheinlich irgendwann der folgende Fehler auftauchen:
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1350) [sender=3.2.3]
Die Ursache ist zu einer sehr hohen Wahrscheinlichkeit auf Umlaute in Ordner- / Datei-Namen zurückzuführen.
Die beiden Betriebssysteme Mac OS und die Linux-Distribution haben bei der Kodierung ein Problem, dass rsync nicht so lösen kann.
Die mögliche Ursache von Code 23
Ist in einem Dateinamen ein Umlaut (z.B. Ä, Ö, Ü, ä, ö, ü, ß) enthalten, dann
- löscht rsync die Datei im Ziellaufwerk
- kopiert die Datei von der Quelle auf das Ziellaufwerk
Es ist dabei unerheblich, ob die Datei geändert wurde oder nicht. rsync durchläuft ganz stupide die beiden Schritte immer und immer wieder.
Bei sehr vielen Dateien kann das sehr nervig und auch langwierig sein.
Das rsync-Verhalten kann man in einem solchen Fall sehr gut mit den beiden Optionen verfolgen.
rsync -P --delete --stats ...
Eine wWeitere Ursache kann z.B. ein fehlerhafter rsync-Befehl sein. Aber bei der Verwendung von Umlauten ist der Fehler mit hoher Wahrscheinlichkeit irgendwelchen Umlauten geschuldet.
Gib mir gerne einen Kaffee ☕ aus!
Wenn dir meine Beiträge gefallen und geholfen haben, dann kannst du mir gerne einen Kaffee ☕ ausgeben.
bc1qfuz93hw2fhdvfuxf6mlxlk8zdadvnktppkzqzj
Die Lösung
Das Problem lässt sich eigentlich sehr einfach umgehen. Es ist die Option --iconv
dem rsync-Befehl hinzuzufügen.
Abhängig von der Richtung der Dateiübertragung lautet die Option dann
von Linux zu MAC
--iconv=UTF8-MAC,UTF8
von Mac zu Linux
--iconv=UTF8,UTF8-MAC
Hierzu ein Beispiel für rsync von Mac zu Linux:
rsync -avhbP --iconv=UTF8,UTF8-MAC --stats --delete --log-file=${LOGFILE} --backup-dir=${BACKUPDIRECTORY} ${SOURCE1} ${TARGET1}
Richtige rsync-Version installiert?
Die Lösung mit --iconv
funktioniert erst ab rsync Version 3.
Apple liefert sein Betriebssystem aber aktuell noch mit der rsync-Version 2.x.x aus, das --iconv
nicht kennt. Es wird dann ein Fehler ausgegeben.
Abfrage der installierten rsync-Version
rsync --version
Glücklicherweise lässt sich rsync mit Hilfe von Homebrew in der aktuellsten Version installieren.
brew search rsync
brew install rsync
Nach der Installation ist der Mac neu zu starten. Die neueste Version ist dann verfügbar und kann verwendet werden.
Hallo!
Ich verwende rsync um auf meinem Synology NAS zu sichern. Auf dem NAS (DSM6.2, rsync 3.0.9) läuft der rsync daemon so das ich als Zieladresse username@192.168.178.23::home/… angeben kann.
Auf dem Mac ist rsync 3.2.4. Der 1.Lauf mit Datei/Ordernnamen mit Umlaut scheint zu funktionieren:
> rsync -va –delete –iconv=UTF8,UTF8-MAC test/ helge@192.168.178.23::home/test/
keine Fehlermeldung), aber auf dem NAS sind die Dateien mit Umlauten nicht lesbar obwohl angekommen:
ls -la test
-rw-r–r– 1 helge users 23960 Apr 24 15:02 datei1.txt
-rw-r–r– 1 helge users 23960 Apr 24 15:02 datei1 UmlautA?.txt
-rw-r–r– 1 helge users 23960 Apr 24 15:02 datei1 UmlautO?.txt
Könnte das an Besonderheiten der Synology liegen?
Danke, Helge
Hallo Helge,
was passiert, wenn du das Laufwerk deiner Synology als Netzwerklaufwerk bei deinem Mac einbindest und rsync „lokal“ läuft?
Hast du dann das gleiche Problem?
Grüße
Stefan
Hätte gleich deinen 2.Blogeintrag lesen sollen wo du genau das beschreibst 😉
Ja, gemounted als SMB share scheint rsync Dateien und Folder mit Umlauten korrekt zu kopieren. Das Problem ist dann wohl der rsync daemon auf der Synology der vielleicht eine Option wie -iconv nicht interpretiert?
Hallo Helge,
freut mich, dass es jetzt funktioniert ??