Basic Backup Basic Backup

Raychan · 02. Dez 2023

Vielen Dank erstmal für das Tool.

Gibt es eine Möglichkeit den Zielpfad als Freigegebenen Ordner auszuwählen? Ich ziehe aktuell vom alten NAS auf einen neuen NAS um und möchte eine 1zu1 kopie von den freigegebenen Ordnern machen.

Basis Backup sagt mir immer das Zielverzeichnis darf nicht leer sein.

Tommes · 02. Dez 2023

Hi

Raychan schrieb:
Gibt es eine Möglichkeit den Zielpfad als Freigegebenen Ordner auszuwählen? […] Basis Backup sagt mir immer das Zielverzeichnis darf nicht leer sein.

Hätte ich diese Möglichkeit einbauen wollen, würdest du die Fehlermeldung nicht erhalten. Es ist demnach gewollt, das diese Möglichkeit untersagt bleibt.

Tommes

treki · 02. Dez 2023

Raychan schrieb:
Vielen Dank erstmal für das Tool.

Gibt es eine Möglichkeit den Zielpfad als Freigegebenen Ordner auszuwählen? Ich ziehe aktuell vom alten NAS auf einen neuen NAS um und möchte eine 1zu1 kopie von den freigegebenen Ordnern machen.

Basis Backup sagt mir immer das Zielverzeichnis darf nicht leer sein.

Anhang anzeigen 89131

Anhang anzeigen 89130

Könntest für das mal mit meinem Script probieren.
https://www.synology-forum.de/threads/howto-backup-per-lftp-script.129178/#post-1109173

RR!! · 09. Dez 2023

Hallo, habe BasicBackup installiert. Die Verbindung zwischen einer DS1813 und einer DS1817 steht.
Allerdings wenn die rsync-Datensicherung startet, kommt es zur Fehlermeldung "ERROR: module is write only"
Was kann ich tun bzw. wo kann ich hier ansetzen?

Anbei mal ein Auszug aus dem Protokoll:

Basic Backup GUI Version: 0.8-100
Basic Backup Job Configuration : 0.8-000
Basic Backup rsync script Version: 0.8-000
DiskStation Manager Version: 7.1.1-42962 Update 6
-------------------------------------------------------------------------------------------------------------------
2023-12-09 16:26:29 - Der Datensicherungsauftrag wird gestartet...
-------------------------------------------------------------------------------------------------------------------
Die Auftragskonfiguration wird eingelesen [ SICH_01 Video-TMP.config ]
Es wird ein Pull-Backup durchgefuehrt. Verbindung wird geprueft...
Der Remote Server ist online. Versuche eine Verbindung herzustellen.
Die SSH-Verbindung zum Remote Server wurde erfolgreich hergestellt.
Der Remote Server ist einsatzbereit. Der Datensicherungsauftrag wird vorbereitet.
Das Datensicherungsziel wurde lokalisiert.
Start der rsync-Datensicherung...

-------------------------------------------------------------------------------------------------------------------
2023-12-09 16:26:30 - Schreibe rsync-Protokoll fuer den Quellordner...
➜ /volume1/2 Video/01 Video-TMP
-------------------------------------------------------------------------------------------------------------------

ERROR: module is write only
rsync error: syntax or usage error (code 1) at main.c(879) [sender=3.1.2]
[sender] _exit_cleanup(code=1, file=main.c, line=879): about to call exit(1)
[Receiver] _exit_cleanup(code=1, file=io.c, line=1812): about to call exit(1)

### Rsync meldete den Exit-Code 1: Syntax- oder Anwendungsfehler

Tommes · 10. Dez 2023

Hi!
Für den Moment bin ich überfragt, da ich diesen Fehler so auch noch nicht hatte. Vor allem die Error-Meldung modul is write only finde ich ziemlich suspekt. Ich habe zwar bereits nach möglichen Gründen gesucht, bisher aber nichts Adäquates gefunden. Sobald ich etwas herausgefunden habe, melde ich mich. Bis dahin könntest du an deinem Auftrag ein -vv anhängen, also z.B. so...

Bash:

/usr/syno/synoman/webman/3rdparty/BasicBackup/rsync.sh --job-name="SICH_01 Video-TMP" -vv &

... und schauen, was dir das Protokoll noch so auswirft. Ich teste bei mir aber auch noch ein paar Dinge durch.

Tommes

RR!! · 10. Dez 2023

Hi @Tommes, anbei mal das vv-Protokoll - wobei in meinem vorherigen Beitrag der Fehlerteil aus einem vvv-Protokoll stammte und deshalb zusätzlich diese Zeilen enthielt:
[sender] _exit_cleanup(code=1, file=main.c, line=879): about to call exit(1)
[Receiver] _exit_cleanup(code=1, file=io.c, line=1812): about to call exit(1)

Basic Backup GUI Version: 0.8-100
Basic Backup Job Configuration : 0.8-000
Basic Backup rsync script Version: 0.8-000
DiskStation Manager Version: 7.1.1-42962 Update 6
-------------------------------------------------------------------------------------------------------------------
2023-12-10 09:51:09 - Der Datensicherungsauftrag wird gestartet...
-------------------------------------------------------------------------------------------------------------------
Die Auftragskonfiguration wird eingelesen [ SICH_01 Video-TMP.config ]
Es wird ein Pull-Backup durchgefuehrt. Verbindung wird geprueft...
Der Remote Server ist online. Versuche eine Verbindung herzustellen.
Die SSH-Verbindung zum Remote Server wurde erfolgreich hergestellt.
OpenSSH_8.2p1, OpenSSL 1.1.1t 7 Feb 2023
debug2: resolve_canonicalize: hostname 192.168.178.86 is address
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug2: ssh_connect_direct
debug1: Connecting to 192.168.178.86 [192.168.178.86] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type 0
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2
debug1: match: OpenSSH_8.2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.178.86:22 as 'RR-admin'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: ciphers stoc: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: MACs ctos: hmac-sha1,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com,umac-64-etm@openssh.com,umac-64@openssh.com
debug2: MACs stoc: hmac-sha1,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com,umac-64-etm@openssh.com,umac-64@openssh.com
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:+6mqQf/tbnMfdGaCLsI2lNji0WQYBq63H2j4f8NzwDQ
debug1: Host '192.168.178.86' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /root/.ssh/id_rsa RSA SHA256:z7pVEbPvTyHSWAMnsNDLYqlYF+dBCOUMbfCpMBM1Wao explicit
debug2: pubkey_prepare: done
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:z7pVEbPvTyHSWAMnsNDLYqlYF+dBCOUMbfCpMBM1Wao explicit
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: /root/.ssh/id_rsa RSA SHA256:z7pVEbPvTyHSWAMnsNDLYqlYF+dBCOUMbfCpMBM1Wao explicit
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.178.86 ([192.168.178.86]:22).
debug2: fd 4 setting O_NONBLOCK
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /var/services/homes/RR-admin/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /var/services/homes/RR-admin/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending command: logout
debug2: channel 0: request exec confirm 1
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: read<=0 rfd 4 len 0
debug2: channel 0: read failed
debug2: channel 0: chan_shutdown_read (i0 o0 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
debug2: channel 0: rcvd ext data 48
sh: line 0: logout: not login shell: use `exit'
debug2: channel 0: written 48 to efd 6
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i3 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
Transferred: sent 3616, received 3324 bytes, in 0.0 seconds
Bytes per second: sent 73207.3, received 67295.6
debug1: Exit status 1
Der Remote Server ist einsatzbereit. Der Datensicherungsauftrag wird vorbereitet.
Das Datensicherungsziel wurde lokalisiert.
Start der rsync-Datensicherung...

-------------------------------------------------------------------------------------------------------------------
2023-12-10 09:51:11 - Schreibe rsync-Protokoll fuer den Quellordner...
➜ /volume1/2 Video/01 Video-TMP
-------------------------------------------------------------------------------------------------------------------
opening connection using: ssh -p 22 -i "~/.ssh/id_rsa" -l RR-admin 192.168.178.86 rsync --server --sender -vvlogDtpre.iLsfxC . "/volume1/2 Video/01 Video-TMP" (14 args)
receiving incremental file list
ERROR: module is write only
rsync error: syntax or usage error (code 1) at main.c(879) [sender=3.1.2]

### Rsync meldete den Exit-Code 1: Syntax- oder Anwendungsfehler
-------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------
2023-12-10 09:51:12 - WARNUNG: Der Datensicherungsauftrag SICH_01 Video-TMP wurde fehlerhaft ausgeführt oder abgebrochen.

Tommes · 10. Dez 2023

Hm... an der SSH-Verbindung kann es meiner Meinung nach nicht liegen, denn das schaut alles gut aus und Basic Backup verbindet sich auch problemlos.

Ich würde daher auf ein Berechtigungsproblem tippen, da am Ende des Protokolls u.a. das hier steht...

receiving incremental file list
ERROR: module is write only

Vielleicht hat dein Benutzer RR-admin nicht die nötigen Rechte um sich aus dem Ordner /volume1/2 Video/01 Video-TMP die nötigen Informationen zu holen, da du scheinbar nur Schreibrechte, aber keine Leserechte auf diesen Ordner hast. Klingt zwar irgendwie unlogisch, aber was besseres fällt mir grad nicht ein.

Tommes

luddi · 10. Dez 2023

@Tommes Ich habe auch selbst einmal in meiner Umgegung mit rsync herumgespielt. Meine Erkenntnis hierzu ist, dass rsync bei einem Rechteproblem dies immer zu einem Permission denied (13) fürht.
Ich habe zum Test folgende owner permissions des Zielverzeichnisses überprüft.

Code:

dr--------
d-w-------
d--x------
drw-------
dr-x------

Bei all diesen Kombinationen bekommt an den Fehler über fehlende Berechtigung.

Man muss zwingend Schreib und Ausführbare Rechte besitzen damit es klappt. Einmal selbstverständlich um Dateien zu erstellen und zum anderen um Verzeichnisse zu durchqueren. Leserechte benötigt man hierzu definitiv nicht, um Dateien zu erstellen.

Code:

d-wx------

Aber auch mir sagt der Fehler module is write only überhaupt nichts bzw. lässt mich nicht auf das vorliegende Problem schließen.

Man sieht in dem Basic Backup log nur folgende Information über die Verbindung:

Code:

opening connection using: ssh -p 22 -i "~/.ssh/id_rsa" -l RR-admin 192.168.178.86 rsync --server --sender -vvlogDtpre.iLsfxC . "/volume1/2 Video/01 Video-TMP" (14 args)

Hierzu müsste man den exakten Befehl überprüfen welches von Basic Backup ausgeführt wird, denn nach dem Fehler module is write only wird zusätzlich das ausgegeben.

Code:

rsync error: syntax or usage error (code 1) at main.c(879) [sender=3.1.2]

Könnten wir hier debuggen und den Befehl transparent machen, indem wir den kompletten rsync command im Log ausgeben?

Tommes · 10. Dez 2023

Hey @luddi danke für deine Unterstützung.

luddi schrieb:
Könnten wir hier debuggen und den Befehl transparent machen, indem wir den kompletten rsync command im Log ausgeben?

Man könnte dem Befehl zur Auftragsausführung ein -vvv anstelle eines -vv mitgeben, so wie oben vorgeschlagen. Also so…

Bash:

/usr/syno/synoman/webman/3rdparty/BasicBackup/rsync.sh --job-name="SICH_01 Video-TMP" -vvv &

Basic Backup debuggt hierbei sowohl ssh als auch rsync und legt die gesammelten Informationen im Protokoll ab.

Du kannst den Befehl auch direkt über die Konsole ausführen, evtl. spuckt dir der Debug-Modus weitere Informationen aus, die nicht ins Protokoll geschrieben werden. Müsste man mal vergleichen. Ich meine mich daran erinnern zu können, das Informationen teilweise nur auf der Konsole ausgegeben wurden, bin mir aber nicht sicher

RR!! · 10. Dez 2023

Datensicherungsprotokoll > SICH_01 Video-TMP

Basic Backup GUI Version: 0.8-100
Basic Backup Job Configuration : 0.8-000
Basic Backup rsync script Version: 0.8-000
DiskStation Manager Version: 7.1.1-42962 Update 6
-------------------------------------------------------------------------------------------------------------------
2023-12-10 15:16:24 - Der Datensicherungsauftrag wird gestartet...
-------------------------------------------------------------------------------------------------------------------
Die Auftragskonfiguration wird eingelesen [ SICH_01 Video-TMP.config ]
Es wird ein Pull-Backup durchgefuehrt. Verbindung wird geprueft...
Der Remote Server ist online. Versuche eine Verbindung herzustellen.
Die SSH-Verbindung zum Remote Server wurde erfolgreich hergestellt.
OpenSSH_8.2p1, OpenSSL 1.1.1t 7 Feb 2023
debug2: resolve_canonicalize: hostname 192.168.178.86 is address
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug2: ssh_connect_direct
debug1: Connecting to 192.168.178.86 [192.168.178.86] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type 0
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2
debug1: match: OpenSSH_8.2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.178.86:22 as 'RR-admin'
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.178.86
debug3: order_hostkeyalgs: have matching best-preference key type ecdsa-sha2-nistp256-cert-v01@openssh.com, using HostkeyAlgorithms verbatim
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: ciphers stoc: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: MACs ctos: hmac-sha1,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com,umac-64-etm@openssh.com,umac-64@openssh.com
debug2: MACs stoc: hmac-sha1,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com,umac-64-etm@openssh.com,umac-64@openssh.com
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:+6mqQf/tbnMfdGaCLsI2lNji0WQYBq63H2j4f8NzwDQ
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.178.86
debug1: Host '192.168.178.86' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /root/.ssh/id_rsa RSA SHA256:z7pVEbPvTyHSWAMnsNDLYqlYF+dBCOUMbfCpMBM1Wao explicit
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:z7pVEbPvTyHSWAMnsNDLYqlYF+dBCOUMbfCpMBM1Wao explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /root/.ssh/id_rsa RSA SHA256:z7pVEbPvTyHSWAMnsNDLYqlYF+dBCOUMbfCpMBM1Wao explicit
debug3: sign_and_send_pubkey: RSA SHA256:z7pVEbPvTyHSWAMnsNDLYqlYF+dBCOUMbfCpMBM1Wao
debug3: sign_and_send_pubkey: signing using rsa-sha2-512 SHA256:z7pVEbPvTyHSWAMnsNDLYqlYF+dBCOUMbfCpMBM1Wao
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.178.86 ([192.168.178.86]:22).
debug2: fd 4 setting O_NONBLOCK
debug2: fd 5 setting O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 4
debug1: Remote: /var/services/homes/RR-admin/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /var/services/homes/RR-admin/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x08
debug2: client_session2_setup: id 0
debug1: Sending command: logout
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: read<=0 rfd 4 len 0
debug2: channel 0: read failed
debug2: channel 0: chan_shutdown_read (i0 o0 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug3: send packet: type 96
debug2: channel 0: input drain -> closed
debug2: channel 0: rcvd ext data 48
sh: line 0: logout: not login shell: use `exit'
debug2: channel 0: written 48 to efd 6
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i3 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1)

debug3: send packet: type 1
debug1: fd 0 clearing O_NONBLOCK
debug3: fd 1 is not O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
Transferred: sent 3616, received 3324 bytes, in 0.1 seconds
Bytes per second: sent 72298.7, received 66460.4
debug1: Exit status 1
Der Remote Server ist einsatzbereit. Der Datensicherungsauftrag wird vorbereitet.
Das Datensicherungsziel wurde lokalisiert.
Start der rsync-Datensicherung...

-------------------------------------------------------------------------------------------------------------------
2023-12-10 15:16:26 - Schreibe rsync-Protokoll fuer den Quellordner...
➜ /volume1/2 Video/01 Video-TMP
-------------------------------------------------------------------------------------------------------------------
opening connection using: ssh -p 22 -i "~/.ssh/id_rsa" -l RR-admin 192.168.178.86 rsync --server --sender -vvvlogDtpre.iLsfxC . "/volume1/2 Video/01 Video-TMP" (14 args)
receiving incremental file list
[sender] add_rule(-s @eaDir/***)
[sender] add_rule(-s @Logfiles/***)
[sender] add_rule(-s #recycle/***)
[sender] add_rule(-s #snapshot/***)
[sender] add_rule(-s .DS_Store/***)
server_sender starting pid=8195
ERROR: module is write only
rsync error: syntax or usage error (code 1) at main.c(879) [sender=3.1.2]
[sender] _exit_cleanup(code=1, file=main.c, line=879): about to call exit(1)
[Receiver] _exit_cleanup(code=1, file=io.c, line=1812): about to call exit(1)

### Rsync meldete den Exit-Code 1: Syntax- oder Anwendungsfehler
-------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------
2023-12-10 15:16:27 - WARNUNG: Der Datensicherungsauftrag SICH_01 Video-TMP wurde fehlerhaft ausgeführt oder abgebrochen.

RR!! · 10. Dez 2023

root@RR-DS1813:~# /usr/syno/synoman/webman/3rdparty/BasicBackup/rsync.sh --job-n ame="SICH_01 Video-TMP" -vvv &
[1] 17912
root@RR-DS1813:~# Basic Backup GUI Version: 0.8-100
Basic Backup Job Configuration : 0.8-000
Basic Backup rsync script Version: 0.8-000
DiskStation Manager Version: 7.1.1-42962 Update 6
-------------------------------------------------------------------------------- -----------------------------------
2023-12-10 15:24:08 - Der Datensicherungsauftrag wird gestartet...
-------------------------------------------------------------------------------- -----------------------------------
Die Auftragskonfiguration wird eingelesen [ SICH_01 Video-TMP.config ]
Es wird ein Pull-Backup durchgefuehrt. Verbindung wird geprueft...
Der Remote Server ist online. Versuche eine Verbindung herzustellen.
Die SSH-Verbindung zum Remote Server wurde erfolgreich hergestellt.
OpenSSH_8.2p1, OpenSSL 1.1.1t 7 Feb 2023
debug2: resolve_canonicalize: hostname 192.168.178.86 is address
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug2: ssh_connect_direct
debug1: Connecting to 192.168.178.86 [192.168.178.86] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type 0
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2
debug1: match: OpenSSH_8.2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.178.86:22 as 'RR-admin'
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.178.86
debug3: order_hostkeyalgs: have matching best-preference key type ecdsa-sha2-nis tp256-cert-v01@openssh.com, using HostkeyAlgorithms verbatim
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2 -nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sh a256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman- group14-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2 -nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa -sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25 519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01 @openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp38 4,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25 519@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256 -ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256 -ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-25 6-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-6 4@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-25 6-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-6 4@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,diffie-he llman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16 -sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh -sha2-nistp521
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp2 56,ssh-ed25519
debug2: ciphers ctos: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,ae s256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: ciphers stoc: aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,ae s256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: MACs ctos: hmac-sha1,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-2 56-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@open ssh.com,umac-128@openssh.com,umac-64-etm@openssh.com,umac-64@openssh.com
debug2: MACs stoc: hmac-sha1,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-2 56-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@open ssh.com,umac-128@openssh.com,umac-64-etm@openssh.com,umac-64@openssh.com
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit > compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit > compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:+6mqQf/tbnMfdGaCLsI2lNji0WQY Bq63H2j4f8NzwDQ
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.178.86
debug1: Host '192.168.178.86' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /root/.ssh/id_rsa RSA SHA256:z7pVEbPvTyHSWAMnsNDLYqlYF +dBCOUMbfCpMBM1Wao explicit
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh. com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nis tp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:z7pVEbPvTyHSWAMnsNDLYq lYF+dBCOUMbfCpMBM1Wao explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /root/.ssh/id_rsa RSA SHA256:z7pVEbPvTyHSWAMnsNDLYql YF+dBCOUMbfCpMBM1Wao explicit
debug3: sign_and_send_pubkey: RSA SHA256:z7pVEbPvTyHSWAMnsNDLYqlYF+dBCOUMbfCpMBM 1Wao
debug3: sign_and_send_pubkey: signing using rsa-sha2-512 SHA256:z7pVEbPvTyHSWAMn sNDLYqlYF+dBCOUMbfCpMBM1Wao
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.178.86 ([192.168.178.86]:22).
debug2: fd 5 setting O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 4
debug1: Remote: /var/services/homes/RR-admin/.ssh/authorized_keys:1: key options : agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /var/services/homes/RR-admin/.ssh/authorized_keys:1: key options : agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x08
debug2: client_session2_setup: id 0
debug1: Sending command: logout
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd ext data 48
sh: line 0: logout: not login shell: use `exit'
debug2: channel 0: written 48 to efd 6
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: chan_shutdown_read (i0 o0 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> closed
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i3 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1)

debug3: send packet: type 1
debug3: fd 1 is not O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
Transferred: sent 3596, received 3360 bytes, in 0.1 seconds
Bytes per second: sent 70628.8, received 65993.5
debug1: Exit status 1
Der Remote Server ist einsatzbereit. Der Datensicherungsauftrag wird vorbereitet .
Das Datensicherungsziel wurde lokalisiert.
Start der rsync-Datensicherung...

-------------------------------------------------------------------------------- -----------------------------------
2023-12-10 15:24:10 - Schreibe rsync-Protokoll fuer den Quellordner...
➜ /volume1/2 Video/01 Video-TMP
-------------------------------------------------------------------------------- -----------------------------------
opening connection using: ssh -p 22 -i "~/.ssh/id_rsa" -l RR-admin 192.168.178.8 6 rsync --server --sender -vvvlogDtpre.iLsfxC . "/volume1/2 Video/01 Video-TMP" (14 args)
receiving incremental file list
[sender] add_rule(-s @eaDir/***)
[sender] add_rule(-s @Logfiles/***)
[sender] add_rule(-s #recycle/***)
[sender] add_rule(-s #snapshot/***)
[sender] add_rule(-s .DS_Store/***)
server_sender starting pid=9842
ERROR: module is write only
rsync error: syntax or usage error (code 1) at main.c(879) [sender=3.1.2]
[sender] _exit_cleanup(code=1, file=main.c, line=879): about to call exit(1)
[Receiver] _exit_cleanup(code=1, file=io.c, line=1812): about to call exit(1)

### Rsync meldete den Exit-Code 1: Syntax- oder Anwendungsfehler
-------------------------------------------------------------------------------- -----------------------------------
-------------------------------------------------------------------------------- -----------------------------------
2023-12-10 15:24:11 - WARNUNG: Der Datensicherungsauftrag SICH_01 Video-TMP wurd e fehlerhaft ausgeführt oder abgebrochen.
root@RR-DS1813:~#

luddi · 10. Dez 2023

Tommes schrieb:
Basic Backup debuggt hierbei sowohl ssh als auch rsync und legt die gesammelten Informationen im Protokoll ab.

Das ist mir bewusst. Wie man auch im Log von @RR!! sehen kann. Allerdings ist das nicht aufschlussreich für meine vorherige Frage.

Denn hier heißt es nichts anderes als vorher schon zu sehen war, nämlich Rsync meldete den Exit-Code 1: Syntax- oder Anwendungsfehler.

Code:

Start der rsync-Datensicherung...

-------------------------------------------------------------------------------- -----------------------------------
2023-12-10 15:24:10 - Schreibe rsync-Protokoll fuer den Quellordner...
➜ /volume1/2 Video/01 Video-TMP
-------------------------------------------------------------------------------- -----------------------------------
opening connection using: ssh -p 22 -i "~/.ssh/id_rsa" -l RR-admin 192.168.178.8 6 rsync --server --sender -vvvlogDtpre.iLsfxC . "/volume1/2 Video/01 Video-TMP" (14 args)
receiving incremental file list
[sender] add_rule(-s @eaDir/***)
[sender] add_rule(-s @Logfiles/***)
[sender] add_rule(-s #recycle/***)
[sender] add_rule(-s #snapshot/***)
[sender] add_rule(-s .DS_Store/***)
server_sender starting pid=9842
ERROR: module is write only
rsync error: syntax or usage error (code 1) at main.c(879) [sender=3.1.2]
[sender] _exit_cleanup(code=1, file=main.c, line=879): about to call exit(1)
[Receiver] _exit_cleanup(code=1, file=io.c, line=1812): about to call exit(1)

### Rsync meldete den Exit-Code 1: Syntax- oder Anwendungsfehler
-------------------------------------------------------------------------------- -----------------------------------

Im Log findet man nur den Hinweis opening connection using: ssh .......
@Tommes Mich hätte im Log eher der gesamte rsync Befehl interessiert welcher abgesetzt wird, um diesen einmal näher unter die Lupe zu nehmen. Und genau das wollte ich wissen, ob man diesen Befehl auch im Log mit ausgeben kann. Sonst können wir nur orakeln weshalb es hier schiefgeht.

luddi · 10. Dez 2023

Ein kleines Update zu meinen Versuchen.

Ich habe nun auch auf dem Zielserver beim Verzeichnisnamen ein Leerzeichen eingebaut. Das Zielverzeichnis heißt nun /luddi 01

Kommen wir zu den unterschiedlichen Szenarien beim rsync Befehl und geben das Verzeichnis auf verschiedene weise an (am Ende der jeweils ersten Zeile):

-> /luddi\ 01

Code:

rsync -ah -vvv --stats --partial --progress -e "ssh -p 22 -i ~/.ssh/luddi_at_raspi_id_rsa" /temp/dummy_folder/dummyfile_1G luddi@raspi.local:/luddi\ 01
opening connection using: ssh -p 22 -i "~/.ssh/luddi_at_raspi_id_rsa" -l luddi raspi.local rsync --server -vvvlogDtpre.iLsfxCIvu --stats --partial . "/luddi\ 01"  (15 args)
sending incremental file list
...

-> /"luddi 01"

Code:

rsync -ah -vvv --stats --partial --progress -e "ssh -p 22 -i ~/.ssh/luddi_at_raspi_id_rsa" /temp/dummy_folder/dummyfile_1G luddi@raspi.local:/"luddi 01"
opening connection using: ssh -p 22 -i "~/.ssh/luddi_at_raspi_id_rsa" -l luddi raspi.local rsync --server -vvvlogDtpre.iLsfxCIvu --stats --partial . "/luddi\ 01"  (15 args)
sending incremental file list
...

-> /luddi 01

Code:

rsync -ah -vvv --stats --partial --progress -e "ssh -p 22 -i ~/.ssh/luddi_at_raspi_id_rsa" /temp/dummy_folder/dummyfile_1G luddi@raspi.local:/luddi 01
Unexpected remote arg: luddi@raspi.local:/luddi
rsync error: syntax or usage error (code 1) at main.c(1512) [sender=3.2.7]
[sender] _exit_cleanup(code=1, file=main.c, line=1512): about to call exit(1)

Bei Punkt No. 3 scheitert der Befehl mit exakt der gleichen Meldung nämlich rsync error: syntax or usage error (code 1).

@Tommes Meine Vermutung ist, dass irgendetwas mit den Leerzeichen nicht stimmt und somit evtl. die Parameter nicht in korrekter Weise an den rsync Befehl übergeben werden.

Was man noch sehen kann, ist folgendes unter der Liste der Argumente:
Unter Punkt No. 1 und 2 wird in beiden Fällen das Leerzeichen entsprechend escaped mit einem Backslash und den zusätzlichen Double Qoutes
"/luddi\ 01".

Bei dem Beispiel von @RR!! ist der String zwar in Double Quotes, aber der escaping Character für das Leerzeichen fehlt
"/volume1/2 Video/01 Video-TMP".

@RR!! Könntest du den Versuch evtl. mit Verzeichnissen am Ziel durchführen, bei denen keine Leerzeichen im Namen vorkommen, um meine Theorie zu bestätigen?

Tommes · 10. Dez 2023

luddi schrieb:
Mich hätte im Log eher der gesamte rsync Befehl interessiert welcher abgesetzt wird, um diesen einmal näher unter die Lupe zu nehmen. Und genau das wollte ich wissen, ob man diesen Befehl auch im Log mit ausgeben kann.

Sag das doch gleich

Ich hab grad keinen Rechner zur Hand, deshalb verweise ich für den Moment auf einen Codeabschnitt in meinem GitHub Repo. Ab Zeile 588 findest du die passenden rsync Aufrufe für ein lokales, pull- oder push Backup. Bei letzteren beiden steht am Ende der Zeile ein…

> >(tee -a "${script_log}") 2>&1

… jedoch wird dadurch wohl nur der ssh Teil ins Protokoll geschrieben, also das hier opening connection using: ssh ....... Vielleicht kannst du dir das so umbauen, das auch der rsync Teil ausgegeben wird.

Tommes · 10. Dez 2023

@luddi
Eigentlich sollte es keine Probleme mit Leerzeichen geben, auch wenn ich das sicherlich nicht hundertprozentig ausschließen kann. Das richtige escapen oder eben nicht escapen von Leerzeichen hat mir schon oft schlaflose Nächte bereitet.

luddi · 10. Dez 2023

@Tommes Genau das hatte ich doch hier im Beitrag erwähnt, was ich möchte. Vielleicht liegt schon wieder eines unserer Verständnisprobleme vor.

luddi schrieb:
Könnten wir hier debuggen und den Befehl transparent machen, indem wir den kompletten rsync command im Log ausgeben?

Ja genau, ich kenne die Stelle im File "rsync.sh" aus deinem Repo.
Interessant wäre hiervon nur die Ausgabe von "${source}" und "${target}" im Log. Damit könnten wir schon sehen wie es an rsync übergeben wird.

luddi · 10. Dez 2023

Tommes schrieb:
Das richtige escapen oder eben nicht escapen von Leerzeichen hat mir schon oft schlaflose Nächte bereitet.

Ja das Problem kenne ich selbst zu gut. Genau aus diesem Grund liegt meine Vermutung wohl nahe, dass es etwas hiermit zu hat.

Warten wir mal auf die Antwort von @RR!! ob es klappt, wenn Verzeichnisse ohne Leerzeichen verwendet werden.
In diesem Fall müssten wir tatsächlich einmal debuggen wie die Strings an den rsync Befehl übergeben werden.

Tommes · 10. Dez 2023

Theoretisch kannst du das ja einfach in einer weiteren Zeile einfügen. Zum Beispiel so…

echo "${source}" | tee -a "${script_log}"
echo "${target}" | tee -a "${script_log}"

… damit sollten die Werte für source und target im Protokoll erscheinen.

luddi schrieb:
Vielleicht liegt schon wieder eines unserer Verständnisprobleme vor.

Ich glaub, das liegt eher an mir. Manchmal bin ich nicht konzentriert genug oder nicht richtig bei der Sache und dann passieren mir solche Dinge. Ich sollte mir vielleicht etwas mehr Zeit nehmen und die Texte mehrfach lesen, bevor ich mich dazu äußer. Ich werd halt alt…

luddi · 10. Dez 2023

@Tommes Ich denke hier in der Zeile 636 ist der Fehler.

Code:

# If the connectiontype is sshpush
        if [[ "${connectiontype}" == "sshpush" ]]; then

            # Escape white spaces with backslash
            target=$(echo ${target} | sed -e 's/ /\ /g')

            # Local to Remote: rsync [option]... [source]... [USER@]HOST:DEST
            rsync \
            ${var[syncopt]} \
            ${dryrun} \
            ${verbose} \
            --stats \
            --delete \
            ${backup} \
            ${excluded} \
            ${perms} \
            -e "ssh -p ${var[sshport]} -i ~/.ssh/${var[privatekey]}" "${source}" ${var[sshuser]}@${var[sshpush]}:"'${target}'" > >(tee -a "${script_log}") 2>&1
            rsync_exit_code=${?}
        fi

Nur in diesem Fall von connection type sshpush von Local to Remote verwendest du das hier: "'${target}'" geschmückt mit single qoutes. Bei allen anderen Fällen wird "${target}" verwendet. Wenn single qoutes mit angegeben werden, so wird der String 1:1 übergeben und somit wird rsync die Leerzeichen nicht escapen.

Oder das es sich bei @RR!! um ein pull backup laut Protokoll handelt könnte es auch sein dass man in Zeile 616 auch die zusätzlichen single qoutes benötigt "'${target}'".

Ich weiß jetzt zwar nicht was in welchem Fall richtig ist, aber beide Fälle werden nicht konsequent gleich behandelt im Script.

Tommes · 10. Dez 2023

Hm… warum habe ich das dann aber nur für push und nur für target escaped und mit Single Quotes versehen, nicht aber für sources sowie bei local und bei pull? Das ist doch bescheuert? Ahhhhh…

Basic Backup Basic Backup

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Datensicherungsprotokoll > SICH_01 Video-TMP​

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Kaffeautomat

Datensicherungsprotokoll > SICH_01 Video-TMP