Static Binaries

Hallo KB19,

vielen Dank für deine Rückmeldung. Den Flag hatte ich auch schon probiert, bekomme aber leider auch damit einen Fehler.

Folgend mein Befehl:

rsync -arv --rsync-path=~/rsync.amd64 test.csv example.de:/csv-dateien/

example.de ist in meiner ssh-config Datei mit einem public key definiert, daher muss ich keinen Benutzernamen angeben. ssh example.de funktioniert z.B.

Die Antwort:

rsync: [receiver] failed to set permissions on "/csv-dateien/.test.csv.KEjpAL": No such file or directory (2)

sent 611417 bytes  received 42 bytes  1222918.00 bytes/sec
total size is 611202  speedup is 1.00
rsync error: some files could not be transferred (code 23) at /AppleInternal/Library/BuildRoots/4ff29661-3588-11ef-9513-e2437461156c/Library/Caches/com.apple.xbs/Sources/rsync/rsync/main.c(996) [sender=2.6.9]

Quote from vistree

example.de:/csv-dateien/

Damit greifst du auf das absolute Verzeichnis /csv-dateien/ zu, da fehlt noch der Pfad zu deinem Home Directory auf dem Server.

Hallo H6G,

das scheint bei mir das home-Verzeichnis zu sein. Wenn ich per SSH auf den Server gehe und dort den Pfad per pwd prüfe, dann sehe ich, dass mein home-Verzeichnis = dem Root ist.

Ich bekommen den identischen Fehler, wenn ich das Verzeichnis z.B auf ~/csv-dateien/ ändere.

Das Verzeichnis existiert. Per scp kann ich auch problemlos Dateien hochladen. Das ist halt nur sehr langsam und es findet bei Fehlern kein Abgleich statt.

um welchen server handelt es sich denn?

weil, das hört sich ja stark nach webhosting an.

die alte applemöhre könnte dann evtl. auch ein rsync-update vertragen (v2.6.9).

Es handelt sich um ein "Reseller Webhosting 8000" Paket mit Plesk. Ich selbst habe keine Möglichkeit Programme auf dem Server zu installieren und rsync ist leider nicht Teil des Setups.

Ich bin insofern ein Stück weiter, als ich rsync nun doch nutzen konnte - nur noch so, wie ich es gerne würde.

Lasse ich aus meinem Standard-Befehl die Option -a weg, dann funktioniert der Transfer:

rsync -rv --rsync-path=~/rsync.amd64 test.csv example.de:/csv-dateien/

Das Weglassen der archiv-Option ist natürlich nicht zweckmäßig. Woran liegt das, dass es mit der Option nicht geht? Was kann ich tun?

vistree Dann probiere die einzelnen Optionen doch mal der Reihe nach aus, woran es liegt:

       --archive, -a            archive mode is -rlptgoD (no -A,-X,-U,-N,-H)

Wenn ich raten müsste, liegt es an -o oder -g. An -p wird es hoffentlich nicht scheitern, außer die Rechte des übergeordneten Ordners wurden völlig falsch gesetzt.

Hallo KB19, ich habe die verschiedenen Optionen jetzt alle einzeln getestet - und leider liegt es doch an der Option -p

Lasse ich die Weg und nutze nur -rltgoD, dann funktioniert es.

Die "preserve permissions" kann ich allerdings nicht wirklich weglassen, da ich rsync vor allem nutzen möchte, um mehrere Webseiten von einem alten Server auf den neuen bei netcup zu bringen ...

Probier mal zusätzlich --inplace aus.

Falls es dann noch immer nicht klappt, logge Dich einmal über SSH auf dem Webspace ein und kopiere die Ausgabe davon ins Forum:

ls -adhils /csv-dateien

Gerne auch ohne das d dazwischen, damit man den ganzen Ordnerinhalt sieht.

Quote from vistree

und leider liegt es doch an der Option -p

… vermutlich, weil dein benutzer nicht übereinstimmt.

Olivetti: ja, die Benutzer stimmer nicht überein. Aber das sollte eigentlich nicht zu einem Problem führen. Das mache ich ja immer so - und fast nie sind der lokale Benutzer und er entfernte Benutzer identisch.

KB19: der Ordner ist noch leer, da ja der Sync nicht klappt. Ich habe immer versucht, eine einzelne Datei hochzuladen.

bash-5.0$ ls -adhils ./csv-dateien

303694136 4.0K drwxrwxrwx 2 example.de psacln 4.0K Nov 7 19:25 ./csv-dateien

bash-5.0$ ls -ahils ./csv-dateien

total 8.0K

303694136 4.0K drwxrwxrwx 2 example.de psacln 4.0K Nov 7 19:25 .

303694122 4.0K drwx--x--- 19 example.de psaserv 4.0K Nov 7 17:28 ..

example.de ist der SSH user, welchen ich in Plesk für die Domain hinterlegt habe.

Die Option --inplace hat den Fehler leider nicht verändert.

Unter Umständen ist das noch relevant? Ich kann als SSH-Zugriffs-Typ nur "/bin/bash (chrooted)" auswählen.

Quote from vistree

example.de ist der SSH user

ich meinte schon den rsync/ssh-user (-> example.de), der mit den eigentumsrechten der ziel-überordner übereinstimmen muss.

ich würde ebenfalls mein lokales rsync updaten. AFAIR gab's mit macos früher öfter probleme mit rsyncs <v3 versus >=v3.

Nur um das auszuschließen, wäre ein Test mit einem Linux System (z.B. in einer VM) als sendende Seite vielleicht sinnvoll. Dann weiß man wenigstens, ob man den Fehler client- oder serverseitig suchen soll.

Hallo zusammen,

vielen Dank für euer Feedback! Ich habe jetzt sowohl meine lokale rsync-Version auf dem Mac aktualisiert als auch einen Test von einem Debian Server (rsync version 3.1.3 protocol version 31) vorgenommen.

Sobald ich -a oder -p mit in rsync einbaue, kommt auch dort der o.g. Fehler.

Es liegt also definitiv am Server oder an der static binary.

Habt ihr noch eine Idee?

Ich mache das rsync nur mit -r und schiebe anschließend noch ein chmod hinterher, um die Gruppen-/Otherrechte zu setzen.

Ich würde ausgehend vom Vorschlag von KB19 einmal langsam Option für Option durchgehen (und -a "nachbilden"), um den Fehler einzugrenzen, wobei -o, -g, -p abwechselnd zum Schluss ausgetestet werden, bevor man sie kombiniert und -D mbMn explizit wegfallen sollte (Grundsatz: "Nur das verwenden, was auch funktionieren kann/soll").

Obwohl ich selbst rsync seit >20 Jahren regelmäßig verwende, kann ich mir die Bedeutung vieler Optionen immer noch nicht merken, also hier die in Beispielen dieses Diskussionsfadens vorgenannten Optionen von vistree gruppiert als Referenz:

 --archive, -a            archive mode is -rlptgoD (no -A,-X,-U,-N,-H)
   --recursive, -r        recurse into directories
   --links, -l            copy symlinks as symlinks
   --perms, -p            preserve permissions
   --times, -t            preserve modification times
   --group, -g            preserve group
   --owner, -o            preserve owner (super-user only)
   -D                     same as --devices --specials

 --dirs, -d               transfer directories without recursing
 --human-readable, -h     output numbers in a human-readable format
 --itemize-changes, -i    output a change-summary for all updates
 --secluded-args, -s      sends all filenames and most options to the remote rsync via the protocol

Wenn der Eigentümer mit dem SSH-Benutzer übereinstimmt, gibt es keinen Grund für -o; wenn man das Oberverzeichnis explizit mit "chmod [u+s,]g+s" modifizieren kann und die Benutzergruppe ansonsten einheitlich ist, gibt es auch keinen Grund für -g (und noch einen Grund weniger für -o).

Gegebenenfalls könnte man im Nachgang einen Moderator bitten, diese (Teil-)Diskussion vom Diskussionsfaden "Static Binaries" abzuspalten, da es bestimmt nicht an den bereitgestellten Binärprogrammen liegt (sondern an der Kombination der Quell- und Zielumgebungskonfiguration).

(EDIT: Andererseits ist man derzeit auf diese Binärprogramme angewiesen, um diese Aktion überhaupt durchführen zu können, also macht die Verschiebung vielleicht noch keinen Sinn.)

Hallo m_ueberall,

Danke für dein ausführliches Feedback. Ich hatte die Optionen bereits einzeln ausgetestet und festgestellt, dass es definitiv an der Option "-p" liegt. Also, dem Seiten der korrekten Ordner-/Datei-Berechtigungen.

Der SSH-User example.de ist anders als mein lokaler Benutzer (kai). Auch die Gruppen lauten anders.

Auf dem Server kann ich mich aber als example.de per SSH anmelden und habe dort auch alle Rechte, um z.B. neue Dateien/Ordner nazulegen und dort per chmod die Datei/Ordner-Rechte anzupassen.

So gehört der Zielordner /csv-dateien auch diesem Benutzer:

drwxrwxrwx 2 example.de psacln 4.0K Nov 8 08:46 csv-dateien

und ich kann nach dem SSH Login dort nach belieben Unterordner und Dateien anlegen, verschieben und löschen.

Wenn ich dich richtig verstanden habe, dann soll ich als SSH-Benutzer auf dem Server mal folgendes ausführen:

chmod u+s csv-dateien/
chmod g+s csv-dateien/

Das funktioniert und es kommen keine Fehler.

Ich kann danach aber immer noch nicht mit der Option -p den rsync ausführen.

Quote from vistree

Ich kann danach aber immer noch nicht mit der Option -p den rsync ausführen.

Dann würde ich zu Testzwecken einmal neben der Option -p auch die Option --chmod=Da+rx,a-w,Fa+r,a-w anfügen (hiermit werden die Zugriffsrechte aller übertragenen Verzeichnisse/Dateien einheitlich übersteuert), um zu sehen, ob es ein generelles Problem mit der Ausführung von chmod auf der Zielseite gibt.

• Wenn das nicht gehen sollte, kann es an rsync liegen. Gegentest in diesem Fall: Via Shell-Zugriff auf der Zielseite manuell Testdateien/-verzeichnisse via mkdir/touch anlegen und via chmod mit entsprechenden Zugriffsrechten versehen – funktioniert das auch nicht, ist etwas grundsätzlich im Argen.
• Wenn das funktioniert, kann es an den Zugriffsrechten auf der Quellseite liegen (auch wenn es seltsam klingt; je nach Dateisystem können Dateien/Verzeichnisse explizit oder implizit erweiterte Zugriffsrechte besitzen, welche aber standardmäßig via rsync nicht übertragen werden sollen (geschieht dies doch, wäre dies das Seltsame)). Gegentest in diesem Fall: Auf der Quellseite mittels mkdir/touch die vorgenannten Schritte ausführen, und die resultierenden Rechte der Dateien/Verzeichnisse sicherheitshalber mit stat, lsattr o. ä. (je nach verwendeter Quellumgebung) explizit überprüfen – wenn diese plausibel aussehen, via rsync eine Übertragung anstoßen. Funktioniert das, liegt es an den Zugriffsrechten der Originaldateien auf der Quellseite.

m_ueberall:

ich habe das direkt mal probiert. Allerdings habe ich mit -a UND --no-perms gearbeitet, um zu sehen, ob der chmod geht:

rsync -arv --no-perms --chmod=Da+rx,a-w,Fa+r,a-w --rsync-path=/rsync.amd64 ./neue-texte.csv example.de:/csv-dateien/

Das funktioniert ohne Fehler und ich sehe auf dem Zielsystem:

-rw-------  1 example.de psacln   17M Dec  6  2021 neue-texte.csv

Korrekt, "--no-perms" sollte das "-p in -a" übersteuern (und ist tatsächlich das, was ich für den --chmod-Test gemeint hatte).

Aber: Ich verstehe nicht, warum es keine Fehler gibt, wenn die Attribute nicht wie gewünscht (a+r,a-w) gesetzt sind? Geht das manuell mittels ssh ... und cd /csv-dateien; touch "neue-texte2.csv"; chmod a+r,a-w "neue-texte2.csv"?

EDIT: Siehe diesen späteren Post, welcher die Unterschiede erklärt.