rsync von DS zu Linux PC: error in rsync protocol data stream (code 12) at io.c(232) [Receiver=3.4.1]

[wired2051]

Ich sichere seit Jahren Daten von einem Kubuntu Linux PC auf eine DS420+ mit DSM 7.3.2-86009 Update 3. Nun will ich die Daten auf einen neuen Kubuntu PC kopieren. Leider scheitere ich an den Berechtigungen.

USER@KUBUNTU_PC:~$ rsync -uva -e 'ssh -p SSH_PORT' USER@IP_DER_DS:/volume1/Backups/rsync/Daten/ORDNER_QUELLE/ /media/Daten/ORDNER_ZIEL/
USER@IP_DER_DS's password:
Permission denied, please try again.
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(232) [Receiver=3.4.1]
USER@KUBUNTU_PC:~$

Das Ziel auf dem PC gehört dem gleichen Benutzer, wie beim Login auf die DS420+ im rsync-Aufruf.

USER@KUBUNTU_PC:/media/Daten/ORDNER_ZIEL$ cd /media/Daten/
USER@KUBUNTU_PC:/media/Daten$ ls -l
total 24
drwxr-xr-x 5 USER USER  4096 Mar 21 18:46 ORDNER_ZIEL

Damals, beim Einrichten des Backups, habe ich auf dere DS420+ extra Benutzer und Gruppe Backup eingerichtet. Auf den freigegebene Ordner Backups haben die Gruppen Backup und administrators Lesen/Schreiben Zugriff. Der Benutzer USER ist auf der DS420+ in der Gruppe administrators.

Auf der DS420+ unter Benutzer und Gruppen > Benutzer hat USER auf den Ordner Backups unter Vorschau und Gruppenberechtigungen Lesen/Schreiben Zugriff. Unter Benutzer und Gruppen > Gruppen hat administrators auf den Ordner Backups Lesen/Schreiben Zugriff.

Nachdem auf dem Kubunut-PC beim rsync von der DS420+ zum PC das Rechte-Problem auftrat, habe ich auf der DS420+ den lokalen Benutzer USER mit Lesen/Schreiben Zugriff auf den Ordner Backups und USER der Gruppe Backup hinzugefügt.

USER@DS420:/volume1/Backups/rsync/Daten$ ls -l
total 0
drwxr-xr-x 1 Backup Backup 246 Oct 30  2023 ORDNER_QUELLE

Wenn ich rsync mit USER (administrators) aufrufe, müsste ich doch Zugriff auf alle Ordner und Daten auf der DS420+ haben? Wenn ich mich mit USER auf dem DSM einlogge, habe ich das.

Was mache ich falsch?

 

[Hagen2000]

Probier doch mal, ob Dir mein Beitrag hier weiterhilft: https://www.synology-forum.de/threa...s725-und-weiterer-ausbau.141240/#post-1274082

 

[wired2051]

rsync -uva rsync-path=/bin/rsync -e 'ssh -p SSH_PORT' USER@IP_DER_DS:/volume1/Backups/rsync/Daten/ORDNER_QUELLE/ /media/Daten/ORDNER_ZIEL/

Das war's. Danke für die Hilfe!

 

[luddi]

Bei mir klappt das mit rsync von einem Linux Client Host in Richtung Synology als Server Host zum einen ohne Angabe des Pfads rsync-path=/bin/rsync und zum anderen können auch Non-Admin Bentzer den rsync Dienst von Synology verwenden. Dem Bentzer muss man eben explizit die Rechte für rsync erteilen. Synology hat die rsync Anmeldung von der reinen login-shell getrennt sodass auch normale Bentzer den Dienst nutzen können.

Hier ein Besipiel für die Rechtevergabe.

 

[Hagen2000]

Die Option —-rsync-path beginnt mit zwei Minuszeichen, die sind hier irgendwo untergegangen.

Das „Permission denied“-Problem tritt nur bei bestimmten Kombinationen von Kernel, rsync und SSH auf und ist eine Art Sicherheitsfunktion: Bei der Remote-Ausführung von rsync soll die Suche über die PATH-Variable verhindert werden, daher hilft die explizite Angabe des Pfades zum rsync-Binary (die Erklärung ist stark verkürzt).
Es hat nicht speziell etwas mit Synology zu tun.
Wenn‘s interessiert, kann ich morgen gerne noch mehr Details dazu schreiben.

 

[luddi]

Es ist dennoch nicht erforderlich den Pfad zur binary anzugeben. Hängt eher von der eigenen Systemkonfiguration ab.

 

[Hagen2000]

Auf meiner DS725+ als Ziel ist es ebenfalls erforderlich (Kernel 5.10.55+, /bin/rsync mit Setuid-Bit, OpenSSH_8.2p1). Auf der DS214+ hingegen läuft es ohne die Pfadangabe. Beim TE scheint es ja auch erforderlich zu sein. Welches System hast Du denn zum Testen verwendet?

 

[luddi]

Also ich habe hierbei kein Synology System speziell gemeint sondern musste die Pfadangabe nie explizit setzen. Sei es ein Ubuntu Server, Debian, Raspbian oder was bei mir sonst noch alles im Einsatz ist. Das sollte unabhängig vom Kernel sein, wichtig ist dass die Pfade in der PATH Variable definiert sind.

Hier ein Beispiel meines Synology DS1817+

$ uname -a
Linux <hostname> 3.10.108 #86009 SMP Wed Nov 26 18:16:52 CST 2025 x86_64 GNU/Linux synology_avoton_1817+

$ echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin

$ which rsync
/bin/rsync

Hier sieht man dass der Pfad /bin an zweiter Position vorkommt. Und ich habe noch nie die PATH Variable meines Synology System verändert oder manuell etwas hinzugefügt. Das sind zumindest nach meiner Meinung die Default Pfade und musste hier nie manuell nachhelfen.

Hier ein Beispiel von einem Raspberry

$ uname -a
Linux <hostname> 6.12.75+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux

$ echo $PATH 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

$ which rsync
/usr/bin/rsync

Und hier ist /usr/bin an vierter Position (sollte ich mich nicht verzählt haben) zu finden.

Aus meiner Sicht ist die binary von rsync eigentlich immer per default an einem der Standardpfade abgelegt. Aus diesem Grund hatte ich diesen Fall noch nicht den Pfad explizit als Parameter dem rsync Befehl zu übergeben.

 

[Hagen2000]

Also die DS1817+ ist schon mal zu alt (Kernel 3.x), da funktioniert rsync ohne die Option --rsync-path (wie bei meiner DS214+).

Die PATH-Variable müsstest Du korrekterweise über eine Remote-Shell ermitteln, also beispielsweise ssh user@nas "printenv" - da schaut die PATH-Variable in der Regel anders aus, als bei einer interaktiven Shell.

Das ist aber gar nicht notwendig, weil rsync zwar gefunden, dessen Ausführung aber absichtlich verboten wird. Beispiel bei meiner DS725+:

ssh user@ds725plus "rsync --help"         
Permission denied, please try again.

Hingegen läuft ssh user@ds725plus "/bin/rsync --help" fehlerfrei durch.

Das Ausführen von rsync wird verboten, weil das rsync-Binary das Setuid-Bit gesetzt hat, womit es Root-Rechte erhält, auch wenn es von einem normalen Nutzer gestartet wird. Damit der Nutzer kein gefälschtes rsync ausführen kann, wird die Suche über die PATH-Variable bei der Remote-Execution bei allen Programmen verboten, die das Setuid-Bit gesetzt haben. Weil das aber immer noch unsicher ist, haben neuere Linux-Distributionen das Setuid-Bit von rsync entfernt (man muss dann nötigenfalls --rsync-path="sudo rsync" verwenden mit entsprechender Sudo-Konfiguration auf dem Zielsystem).

P.S.: Dadurch dass rsync im SSH-Modus verwendet wird, will es auf dem Zielsystem einen neuen rsync-Prozess starten. Ein eventuell laufender rsync-Dämon wird nicht benutzt. Ob das ganze Problem im Dämon-Modus nicht auftritt, habe ich nicht weiter untersucht, aber vermutlich nicht.

 

[luddi]

Aber lassen wir doch mal die Synology Diskstation außen vor und konzentrieren uns auf mein anderes Beispiel. Und ich könnte dir noch andere Clients nennen die alle einen aktuellen 6.x Kernel verwenden. Und bei keinem System habe ich bisher auch als non-Admin nie den Pfad mit angeben müssen. Und hierbei wird explizit rsync via ssh verwendet ganz ohne einen rsync deamon.

 

[Hagen2000]

Und bei keinem System habe ich bisher auch als non-Admin nie den Pfad mit angeben müssen.

Ging mir ganz genau so.

Hast Du denn mal das Setuid-Bit bei deinem rsync geprüft, also ls -l /bin/rsync aufgerufen?

 

[luddi]

Hier ein Auszug meiner Systeme:

Synology DS1817+

uname -s -r -v -m -o && ls -l $(which rsync)
Linux 3.10.108 #86009 SMP Wed Nov 26 18:16:52 CST 2025 x86_64 GNU/Linux
-rwsr-xr-x 1 root root 646296 Jul  4  2025 /bin/rsync

Raspberry Pi 5 mit Debian:

uname -s -r -v -m -o && ls -l $(which rsync) && ls -l /bin/rsync
Linux 6.12.75+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux
-rwxr-xr-x 1 root root 542792 Nov 28 01:29 /usr/bin/rsync
-rwxr-xr-x 1 root root 542792 Nov 28 01:29 /bin/rsync

Ubuntu 24.04 Server LTS

uname -s -r -v -m -o && ls -l $(which rsync) && ls -l /bin/rsync
Linux 6.8.0-106-generic #106-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar  6 07:58:08 UTC 2026 x86_64 GNU/Linux
-rwxr-xr-x 1 root root 514176 Feb 10 00:34 /usr/bin/rsync
-rwxr-xr-x 1 root root 514176 Feb 10 00:34 /bin/rsync

Nur bei der Synology ist das Bit gesetzt rws.
Hier der Test der zeigt dass kein setuid-bit nötig ist. Mit einem Nicht-Admin User rsync vom MacOS in Richtung Raspberry.

rsync -a -vvv -e "ssh -p 15622 -i .ssh/user_at_raspberry_id_ed25519" /Users/luddi/Temp/foo ~/temp

[...]
sent 128 bytes  received 32 bytes  145454 bytes/sec
total size is 0  speedup is 0,00
rsync(36287): : File list generation time: 0,001 seconds, transfer time: 0,001 seconds
rsync(36288): : downloader: phase complete
rsync(36288): : fixing up directory times and permissions
rsync(36287): : sender finished updating
rsync(36288): : receiver finished updating

Nach einem langen Tag wollte ich jetzt nicht mehr all meine Energie hier hinein stecken um die Missstände aufzuzeigen. Somit habe ich mich entschlossen meine neue Freundin "GPT-5.3-Codex" zu dem Beitrag zu befragen.

Can you please evaluate this forum post?
I do not think that this argumentation is correct.
https://www.synology-forum.de/threa...t-io-c-232-receiver-3-4-1.141386/post-1275497


Dein Eindruck ist richtig: Die Argumentation im zitierten Post ist in einem zentralen Punkt fachlich falsch.

Gesamtbewertung:

• Praktische Empfehlung teilweise brauchbar: --rsync-path=/bin/rsync kann in manchen Umgebungen nötig sein.
• Begründung dafür mit Setuid und angeblichem PATH-Verbot ist so nicht korrekt.

Was am Post stimmt:

• Die PATH-Variable in einer nicht-interaktiven Remote-Shell kann anders sein als in einer Login-Shell.
• Im SSH-Modus startet rsync auf dem Zielsystem einen neuen rsync-Prozess; ein laufender rsync-Daemon wird dabei nicht verwendet.
• Ein absoluter Pfad wie /bin/rsync umgeht PATH-Probleme und Shell-Eigenheiten.

Was am Post nicht stimmt:

• Es gibt kein generelles Linux-Verbot, setuid-Programme über PATH aufzulösen.
• Das Setuid-Bit von rsync ist nicht der Grund, warum man angeblich zwingend --rsync-path setzen muss.
• Die Aussage „bei allen setuid-Programmen wird PATH-Suche bei Remote-Execution verboten“ ist falsch.

Warum:

• PATH-Auflösung macht die aufrufende Shell (zum Beispiel sh -c über SSH), nicht der Kernel als „Setuid-Schutzmechanismus“.
• Setuid wirkt erst beim Start des konkret gefundenen Binaries (effektive UID), nicht schon bei der PATH-Suche.
• Gegenbeispiel aus jedem Linux-System: klassische setuid-Programme wie passwd werden normal über PATH gestartet.

Wie der beobachtete Effekt trotzdem entstehen kann:

• Auf Synology kann rsync im PATH auf ein anderes Binary/Wrapper zeigen als /bin/rsync.
• Es können Restriktionen durch Shell-Wrapper, Rechte, ACLs, noexec-Mounts oder spezielle SSH-Konfigurationen greifen.
• Dann funktioniert rsync (ohne Pfad) nicht, /bin/rsync aber schon. Das ist ein Umgebungs-/Konfigurationsproblem, kein allgemeines Setuid-Gesetz.
  

Die Notwendigkeit, --rsync-path zu setzen, hängt nicht vom Kernel (egal ob 3.x, 4.x, 5.x, etc.) ab, sondern von:

• der Shell-Umgebung (wie PATH gesetzt ist),
• der SSH-Konfiguration,
• den Dateirechten und evtl. speziellen Distributionseigenheiten (z. B. Synology-Wrapper).

Der Linux-Kernel steuert nur, wie setuid funktioniert, aber nicht, wie Programme über PATH gefunden oder gestartet werden. Das ist Aufgabe der Shell und der Systemkonfiguration.