Backup über rsync - Connection refused
![](https://seccdn.libravatar.org/avatar/c5aa5183587a9cea3296622345dd170c.jpg?s=120&d=mm&r=g)
Moin, ich versuche gerade ein Backup von meinem TW einzurichten. Der Backup-Server ist ein Pi, der via rsync auf Tumbleweed zugreifen soll. Auf TW läuft der rsyncd Service und es existiert eine rsyncd.conf Auf diese Art und Weise fahre ich schon seit Jahren Backups für verschiedene Linux Rechner. Der Zugriff auf TW wird allerdings verweigert. Der Eintrag in rsyncd.conf sieht so aus: 1 use chroot = false 2 #hosts allow = vanya.fritz.box 3 hosts allow = 192.168.178.10 4 5 transfer logging = true 6 log file = /var/log/rsyncd.log 7 log format = %h %o %f %l %b 8 9 10 [etc] 11 path=/etc 12 read only=yes 13 list=no 14 uid=nobody 15 gid=nogroup 16 17 [home] 18 path=/home/joachim 19 read only=yes 20 list=no 21 uid=nobody 192.168.178.10 ist der Pi mit dem Namen vanya und die 15 ist TW mit dem Namen Theophila. rsync: [Receiver] failed to connect to theophila (2003:d9:d71a:6f00:67c:16ff:fe47:c6e3): Connection refused (111) rsync: [Receiver] failed to connect to theophila (2003:d9:d71a:6f00:9243:92fe:502f:15ee): Connection refused (111) rsync: [Receiver] failed to connect to theophila (192.168.178.15): Connection refused (111) sshd läuft auf TW. Ich seh' grad nicht, wo das Problem liegt. Wenn mich jemand vom Schlauch schubsten könnte ... Joachim
![](https://seccdn.libravatar.org/avatar/d8f80cfe82b1e886c689256ed208caed.jpg?s=120&d=mm&r=g)
rsync Prozess läuft und ist lokal & remote z.B. per Telnet erreichbar? Von meinem iPad gesendet
Am 30.06.2024 um 12:42 schrieb Joachim Hussong
: Moin,
ich versuche gerade ein Backup von meinem TW einzurichten. Der Backup-Server ist ein Pi, der via rsync auf Tumbleweed zugreifen soll. Auf TW läuft der rsyncd Service und es existiert eine rsyncd.conf
Auf diese Art und Weise fahre ich schon seit Jahren Backups für verschiedene Linux Rechner.
Der Zugriff auf TW wird allerdings verweigert.
Der Eintrag in rsyncd.conf sieht so aus:
1 use chroot = false
2 #hosts allow = vanya.fritz.box
3 hosts allow = 192.168.178.10
4
5 transfer logging = true
6 log file = /var/log/rsyncd.log
7 log format = %h %o %f %l %b
8
9
10 [etc]
11 path=/etc
12 read only=yes
13 list=no
14 uid=nobody
15 gid=nogroup
16
17 [home]
18 path=/home/joachim
19 read only=yes
20 list=no
21 uid=nobody
192.168.178.10 ist der Pi mit dem Namen vanya und die 15 ist TW mit dem Namen Theophila.
rsync: [Receiver] failed to connect to theophila (2003:d9:d71a:6f00:67c:16ff:fe47:c6e3): Connection refused (111) rsync: [Receiver] failed to connect to theophila (2003:d9:d71a:6f00:9243:92fe:502f:15ee): Connection refused (111) rsync: [Receiver] failed to connect to theophila (192.168.178.15): Connection refused (111)
sshd läuft auf TW.
Ich seh' grad nicht, wo das Problem liegt.
Wenn mich jemand vom Schlauch schubsten könnte ...
Joachim
![](https://seccdn.libravatar.org/avatar/c5aa5183587a9cea3296622345dd170c.jpg?s=120&d=mm&r=g)
Am 30.06.24 um 13:14 schrieb Ralf Prengel:
rsync Prozess läuft und ist lokal & remote z.B. per Telnet erreichbar? Von meinem iPad gesendet
Ich bin jetzt doch verwirrt. Der rsync Daemon auf TW lief gar nicht. Die Meldung war, dass /etc/rsyncd.conf nicht gefunden wurde. Die Situation ist jetzt folgende: liegt rsyncd.conf in /etc/rsync/, dann wird der Zugriff verweigert. Klar, es gibt keine erlaubten Hosts, rsyncd.conf wird nicht gefunden liegt rsyncd.conf in /etc, dann erhalte ich folgende Meldungen @ERROR: Unknown module 'etc' .. @ERROR: Unknown module 'home' Was'n das jetzt? Die Module sind doch in rsyncd.conf angegeben.
![](https://seccdn.libravatar.org/avatar/4c7c9c9e5756ed4c38882b8f2ef8b88a.jpg?s=120&d=mm&r=g)
Am 30.06.24 um 13:43 schrieb Joachim Hussong:
Am 30.06.24 um 13:14 schrieb Ralf Prengel:
rsync Prozess läuft und ist lokal & remote z.B. per Telnet erreichbar? Von meinem iPad gesendet
Ich bin jetzt doch verwirrt.
Der rsync Daemon auf TW lief gar nicht. Die Meldung war, dass /etc/rsyncd.conf nicht gefunden wurde.
Die Situation ist jetzt folgende:
liegt rsyncd.conf in /etc/rsync/, dann wird der Zugriff verweigert. Klar, es gibt keine erlaubten Hosts, rsyncd.conf wird nicht gefunden
liegt rsyncd.conf in /etc, dann erhalte ich folgende Meldungen
@ERROR: Unknown module 'etc' .. @ERROR: Unknown module 'home'
Was'n das jetzt? Die Module sind doch in rsyncd.conf angegeben.
Kann ich so nciht reproduzieren. Wenn ich Deine rsyncd.conf aus dem ersten Post nach /etc packe startet der rsyncd ganz normal und verhält sich wie erwartet. Du wirst irgendwas subtil falsch machen. Unabhhängig davon würde mich anschließen und ebenfalls in 2024 keine IP basierte Auth. mehr machen. Auch nicht im Heimnetz. Viele Güße Ulf
![](https://seccdn.libravatar.org/avatar/c5aa5183587a9cea3296622345dd170c.jpg?s=120&d=mm&r=g)
Am 30.06.24 um 19:30 schrieb Ulf Volmer:
Kann ich so nciht reproduzieren. Wenn ich Deine rsyncd.conf aus dem ersten Post nach /etc packe startet der rsyncd ganz normal und verhält sich wie erwartet.
Du wirst irgendwas subtil falsch machen.
genau das ist die Frage. Was mache ich falsch? Dass es verschiedene Möglichkeiten gibt, ein Backup zu realisieren, dass man keys statt Passwörtern verwenden kann, und dass es bessere Möglichkeiten gibt als IPs, ist mir alles bewusst. Bisher habe ich es so wie beschrieben gelöst und es hat seinen Zweck erfüllt. Allerdings waren das alles Distributionen die auf Debian basieren (Raspian et al, Ubuntu). Jetzt wollte ich das so auch mit Tumbleweed machen und ich erhalte den Fehler. Ich sehe im Moment nicht, was die Ursache sein könnte. Die Backup Scripte sind alle gleich aufgebaut und rsyncd läuft. Was braucht es mehr?
![](https://seccdn.libravatar.org/avatar/9ccb24a0b345131ffb0e737bad7168d6.jpg?s=120&d=mm&r=g)
Am 01.07.24 um 08:54 schrieb Joachim Hussong:
... Bisher habe ich es so wie beschrieben gelöst und es hat seinen Zweck erfüllt. Allerdings waren das alles Distributionen die auf Debian basieren (Raspian et al, Ubuntu). Jetzt wollte ich das so auch mit Tumbleweed machen und ich erhalte den Fehler.
Ich sehe im Moment nicht, was die Ursache sein könnte.
Die Backup Scripte sind alle gleich aufgebaut und rsyncd läuft. Was braucht es mehr?
Hast du schon probiert, den Debug Level höher zu setzen. rsnapshot hat dazu selber ein paar Optionen, und sicherlich kann man das doch bei sshd und rsyncd auch noch mal extra machen. Eventuell kennt ja die tumbleweed-Version von rsnapshot ausgerechnet den Crypto-Algorithmus oder Schlüsseltyp nicht mehr, den dein rsnapshot sonst klaglos benutzt? -- Viele Grüße Michael
![](https://seccdn.libravatar.org/avatar/9ccb24a0b345131ffb0e737bad7168d6.jpg?s=120&d=mm&r=g)
Hat sich erledigt,wie ich weiter unten eben gesehen habe, war der Fehler ein anderer. -- Viele Grüße Michael
![](https://seccdn.libravatar.org/avatar/65f6637f0abadc8a2f09ebecb9ec8ffc.jpg?s=120&d=mm&r=g)
Am 30.06.2024 um 12:42 schrieb Joachim Hussong:
Moin,
ich versuche gerade ein Backup von meinem TW einzurichten. Der Backup-Server ist ein Pi, der via rsync auf Tumbleweed zugreifen soll. Auf TW läuft der rsyncd Service und es existiert eine rsyncd.conf
Auf diese Art und Weise fahre ich schon seit Jahren Backups für verschiedene Linux Rechner.
Der Zugriff auf TW wird allerdings verweigert.
Der Eintrag in rsyncd.conf sieht so aus:
1 use chroot = false
2 #hosts allow = vanya.fritz.box
3 hosts allow = 192.168.178.10
4
5 transfer logging = true
6 log file = /var/log/rsyncd.log
7 log format = %h %o %f %l %b
8
9
10 [etc]
11 path=/etc
12 read only=yes
13 list=no
14 uid=nobody
15 gid=nogroup
16
17 [home]
18 path=/home/joachim
19 read only=yes
20 list=no
21 uid=nobody
192.168.178.10 ist der Pi mit dem Namen vanya und die 15 ist TW mit dem Namen Theophila.
rsync: [Receiver] failed to connect to theophila (2003:d9:d71a:6f00:67c:16ff:fe47:c6e3): Connection refused (111) rsync: [Receiver] failed to connect to theophila (2003:d9:d71a:6f00:9243:92fe:502f:15ee): Connection refused (111) rsync: [Receiver] failed to connect to theophila (192.168.178.15): Connection refused (111)
sshd läuft auf TW.
Ich seh' grad nicht, wo das Problem liegt.
Wenn mich jemand vom Schlauch schubsten könnte ...
Joachim
Ich verwende rsync seit Ewigkeiten aber auf die Idee ein rsyncd.conf anzulegen bin ich noch nie gekommen. Wozu soll das gut sein?!?!? Und wenn ich da lese User nobody Group nogroup da stellen sich bei mir die Fußnägel auf beim Zugriff auf ein Homeverzeichnis Manfred
![](https://seccdn.libravatar.org/avatar/c5aa5183587a9cea3296622345dd170c.jpg?s=120&d=mm&r=g)
Am 30.06.24 um 18:02 schrieb Manfred Kreisl:
Ich verwende rsync seit Ewigkeiten aber auf die Idee ein rsyncd.conf anzulegen bin ich noch nie gekommen. Wozu soll das gut sein?!?!?
Ich habe einen Backup Server, der ist unabhängig von anderen Rechnern im Netz. Das Backup ist so eingerichtet, dass der Backup-Server die Daten zieht und nicht der Client drückt. Damit läuft für das gesamte Backup ein einziger Cron-Job auf dem Server, der je nach Tag, Woche, Monat diverse Laufwerke der anderen (u.a. ein NAS, läuft 24/7) sichert. Und da bietet sich rsyncd, also rsync --daemon an.
Und wenn ich da lese User nobody Group nogroup da stellen sich bei mir die Fußnägel auf beim Zugriff auf ein Homeverzeichnis
Das Ganze läuft rein im privaten Bereich. Ziel ist es, nicht ein System vollständig zurückspielen zu können, sondern nur die Einstellungen (/etc, und das nur als Nachschlagemöglichkeit) und Daten (NAS). Alles andere würde eh frisch aufgezogen werden. Und die Rechte sind in diesem Zusammenhang eher zweitrangig, Hauptsache die Daten sind noch da wenn mal was schiefgehen sollte. Das alles läuft bisher problemlos.
![](https://seccdn.libravatar.org/avatar/65f6637f0abadc8a2f09ebecb9ec8ffc.jpg?s=120&d=mm&r=g)
Am 30.06.2024 um 18:17 schrieb Joachim Hussong:
Am 30.06.24 um 18:02 schrieb Manfred Kreisl:
Ich verwende rsync seit Ewigkeiten aber auf die Idee ein rsyncd.conf anzulegen bin ich noch nie gekommen. Wozu soll das gut sein?!?!?
Ich habe einen Backup Server, der ist unabhängig von anderen Rechnern im Netz. Das Backup ist so eingerichtet, dass der Backup-Server die Daten zieht und nicht der Client drückt.
Damit läuft für das gesamte Backup ein einziger Cron-Job auf dem Server, der je nach Tag, Woche, Monat diverse Laufwerke der anderen (u.a. ein NAS, läuft 24/7) sichert. Und da bietet sich rsyncd, also rsync --daemon an.
Und wenn ich da lese User nobody Group nogroup da stellen sich bei mir die Fußnägel auf beim Zugriff auf ein Homeverzeichnis
Das Ganze läuft rein im privaten Bereich. Ziel ist es, nicht ein System vollständig zurückspielen zu können, sondern nur die Einstellungen (/etc, und das nur als Nachschlagemöglichkeit) und Daten (NAS). Alles andere würde eh frisch aufgezogen werden. Und die Rechte sind in diesem Zusammenhang eher zweitrangig, Hauptsache die Daten sind noch da wenn mal was schiefgehen sollte. Das alles läuft bisher problemlos.
Soso, wozu dann dein ursprünglicher Post?
Ich mach ähnliches, wie gesagt seit Jahrzehnten, seit geraumer Zeit sichere ich damit sogar 3 Mietserver. Und ich kann mich nur wiederholen, eine conf hab ich noch nie gebraucht und der rsync Daemon wird auch automatisch gestartet auf dem Client. Daher meine Verwirrung und die Frage. Manfred
![](https://seccdn.libravatar.org/avatar/c5aa5183587a9cea3296622345dd170c.jpg?s=120&d=mm&r=g)
Am 30.06.24 um 18:48 schrieb Manfred Kreisl:
Ich mach ähnliches, wie gesagt seit Jahrzehnten, seit geraumer Zeit sichere ich damit sogar 3 Mietserver. Und ich kann mich nur wiederholen, eine conf hab ich noch nie gebraucht und der rsync Daemon wird auch automatisch gestartet auf dem Client. Daher meine Verwirrung und die Frage.
Der rsync Dämon wurde bei mir erstmal nicht automatisch gestartet. Ich musste den Dienst erst aktivieren (systemctl enable ..., ... start). Und wie funktioniert rsync ohne rsyncd.conf auf dem Client? Machst du das über eine Remote Shell? Dann musst du aber aktiv ein Passwort angeben. Da mein Backup nachts läuft, wird das schwierig. Es soll ja vollständig automatisiert ablaufen.
![](https://seccdn.libravatar.org/avatar/65f6637f0abadc8a2f09ebecb9ec8ffc.jpg?s=120&d=mm&r=g)
Am 30.06.2024 um 19:02 schrieb Joachim Hussong:
Am 30.06.24 um 18:48 schrieb Manfred Kreisl:
Ich mach ähnliches, wie gesagt seit Jahrzehnten, seit geraumer Zeit sichere ich damit sogar 3 Mietserver. Und ich kann mich nur wiederholen, eine conf hab ich noch nie gebraucht und der rsync Daemon wird auch automatisch gestartet auf dem Client. Daher meine Verwirrung und die Frage.
Der rsync Dämon wurde bei mir erstmal nicht automatisch gestartet. Ich musste den Dienst erst aktivieren (systemctl enable ..., ... start).
Und wie funktioniert rsync ohne rsyncd.conf auf dem Client? Machst du das über eine Remote Shell? Dann musst du aber aktiv ein Passwort angeben. Da mein Backup nachts läuft, wird das schwierig. Es soll ja vollständig automatisiert ablaufen.
Für sowas gibt's ssh Keys ohne Passphrase Manfred
![](https://seccdn.libravatar.org/avatar/d8f80cfe82b1e886c689256ed208caed.jpg?s=120&d=mm&r=g)
Am 30.06.2024 um 19:02 schrieb Joachim Hussong
:
Am 30.06.24 um 18:48 schrieb Manfred Kreisl:
Ich mach ähnliches, wie gesagt seit Jahrzehnten, seit geraumer Zeit sichere ich damit sogar 3 Mietserver. Und ich kann mich nur wiederholen, eine conf hab ich noch nie gebraucht und der rsync Daemon wird auch automatisch gestartet auf dem Client. Daher meine Verwirrung und die Frage.
Der rsync Dämon wurde bei mir erstmal nicht automatisch gestartet. Ich musste den Dienst erst aktivieren (systemctl enable ..., ... start).
Und wie funktioniert rsync ohne rsyncd.conf auf dem Client? Machst du das über eine Remote Shell? Dann musst du aber aktiv ein Passwort angeben. Da mein Backup nachts läuft, wird das schwierig. Es soll ja vollständig automatisiert ablaufen.
ggf. ist auch rsnapshot eine Variante für dich. Wenn es darum geht z.B. /etc zu versionieren gibt es auch andere Wege. Ich selber habe eine synology mit active Backup laufen. Damit ist mein Thema Backups familienweit zentral gelöst. Gruß
![](https://seccdn.libravatar.org/avatar/32435562214f08d51d4aff895e189843.jpg?s=120&d=mm&r=g)
Bei mir läuft jeden Abend und jeden Morgen ein bash Script. Das holt per rsync einige Dateien von meinem Server bei Hetzner. ssh natürlich mit key. Funktioniert mit einem systemd timer ohne Probleme. Stephan Am Sonntag, 30. Juni 2024, 12:42:41 CEST schrieb Joachim Hussong:
Moin,
ich versuche gerade ein Backup von meinem TW einzurichten. Der Backup-Server ist ein Pi, der via rsync auf Tumbleweed zugreifen soll. Auf TW läuft der rsyncd Service und es existiert eine rsyncd.conf
Auf diese Art und Weise fahre ich schon seit Jahren Backups für verschiedene Linux Rechner.
Der Zugriff auf TW wird allerdings verweigert.
Der Eintrag in rsyncd.conf sieht so aus:
1 use chroot = false
2 #hosts allow = vanya.fritz.box
3 hosts allow = 192.168.178.10
4
5 transfer logging = true
6 log file = /var/log/rsyncd.log
7 log format = %h %o %f %l %b
8
9
10 [etc]
11 path=/etc
12 read only=yes
13 list=no
14 uid=nobody
15 gid=nogroup
16
17 [home]
18 path=/home/joachim
19 read only=yes
20 list=no
21 uid=nobody
192.168.178.10 ist der Pi mit dem Namen vanya und die 15 ist TW mit dem Namen Theophila.
rsync: [Receiver] failed to connect to theophila (2003:d9:d71a:6f00:67c:16ff:fe47:c6e3): Connection refused (111) rsync: [Receiver] failed to connect to theophila (2003:d9:d71a:6f00:9243:92fe:502f:15ee): Connection refused (111) rsync: [Receiver] failed to connect to theophila (192.168.178.15): Connection refused (111)
sshd läuft auf TW.
Ich seh' grad nicht, wo das Problem liegt.
Wenn mich jemand vom Schlauch schubsten könnte ...
Joachim
![](https://seccdn.libravatar.org/avatar/e7a9b2ea215e3f819535da752474d27d.jpg?s=120&d=mm&r=g)
Am 30.06.24 um 12:42 schrieb Joachim Hussong:
Moin,
ich versuche gerade ein Backup von meinem TW einzurichten. Der Backup-Server ist ein Pi, der via rsync auf Tumbleweed zugreifen soll. Auf TW läuft der rsyncd Service und es existiert eine rsyncd.conf
[...]
192.168.178.10 ist der Pi mit dem Namen vanya und die 15 ist TW mit dem Namen Theophila.
rsync: [Receiver] failed to connect to theophila (2003:d9:d71a:6f00:67c:16ff:fe47:c6e3): Connection refused (111) rsync: [Receiver] failed to connect to theophila (2003:d9:d71a:6f00:9243:92fe:502f:15ee): Connection refused (111) rsync: [Receiver] failed to connect to theophila (192.168.178.15): Connection refused (111)
IPv4/IPv6 Problem? -- ae | Andreas Ernst | IT Spektrum Postfach 5, 65612 Beselich Schupbacher Str. 32, 65614 Beselich, Germany Tel: +49-6484-91002 Fax: +49-6484-91003 ae@ae-online.de | www.ae-online.de www.tachyon-online.de
![](https://seccdn.libravatar.org/avatar/c5aa5183587a9cea3296622345dd170c.jpg?s=120&d=mm&r=g)
Am 01.07.24 um 09:02 schrieb Andreas Ernst:
IPv4/IPv6 Problem?
Yepp, das war's. Ursprünglich hatte ich den Servernamen in der conf Datei drinne. Die Ip habe ich erst versucht, als es damit nicht ging. Damit sieht es eher so aus, als ob ich ein Problem mit der Namensauflösung habe, oder warum hat es mit dem Namen nicht geklappt?
![](https://seccdn.libravatar.org/avatar/c5aa5183587a9cea3296622345dd170c.jpg?s=120&d=mm&r=g)
Zusammenfassung: für die Ipv6 des Backupservers wird keine Namensauflösung gefunden und es wird auch nur über IPv6 versucht, den Client anzusprechen. Die Rechte des home-Verzeichnisses mussten noch angepasst werden. Diese waren 0700. Damit erhielt ich ein Permission Denied. Habe es auf 0755 geändert und jetzt läuft das Backup wie es soll. Danke für's helfen Joachim
participants (7)
-
Andreas Ernst
-
Joachim Hussong
-
Manfred Kreisl
-
Michael Behrens
-
Ralf Prengel
-
Stephan Hemeier
-
Ulf Volmer