Dateirechte | synoacltool

[DanielB]

Hallo zusammen
Ich stehe vor einem ähnlichen / gleichen Problem wie im obigen Verlauf beschrieben.
Folgender Unterschied besteht aber:
- Die Ordner erhalten die Berechtigung des übergeordneten Ordners, auch rekursiv.
- Auf Dateiebene wird die Berechtigungen neu vergeben - nicht vererbt.

Wie oben beschrieben wollte ich nun auch den Parameter--syno-acl verwenden - was übrigens dem Parameter -X entspricht.

Der Parameter --syno-acl löst folgene Meldung aus:
rsync: rsync_xal_set: set_xattr_syno_acl(""/volume1/NAS-B20 Datensicherung/_Test Script/."","user.rsync.synoacl") failed: Permission denied (13)

Der Prozess wird mit dem Admin User ausgeführt und trotzdem fehlt die notwendige Berechtigung.
Was könnte die Ursache für "Permission denied" sein?

Zudem sollten der Owner und Gruppe 1:1 übernommen werden. Auf beiden NAS sind die UID's und GID's identisch definiert.
Jedoch scheinen die Parameter -o und -g nicht zu wirken.
Was könnte hier die Lösung sein?

Für einen einen Tipp wäre ich dankbar.

Das Backup erfolgt von einer DS220+ (mit DSM 7.2) auf eine DS215j (mit DSM 7.1.1) und wird über SSH durchgeführt.
Eine Alternative (z.Bsp. Synology Drive share sync) für rsync habe ich nicht gefunden, da die gelöschten Daten in ein backup-Directory verschoben werden sollen und erst nach einer definierten Zeit endgültig gelöscht werden.

Gruss Daniel

 

[DanielB]

Der Grund für die "Permission denied" im Zusammenhang mit --syno-acl ist gefunden.
In der Systemsteuerung --> Anwendungsberechtigungen --> rsync(....) musste noch die Administratoren-Gruppe (auf dem Ziel-Server) berechtigt werden.
Der Admin-User selber konnte nicht berechtigt werden, da das "Kästchen" ausgegraut ist.

Nur leider funktioniert der Parameter --syno-acl nicht. Die Berechtigungen auf Dateiebene wird nach wie vor nicht vererbt.

 

[peterhoffmann]

Als "root" ausgeführt?

Bei mir läuft das Backupscript mit Rootrechten. Im Grunde wird da rsync u.a. mit dem Parameter --syno-acl ausgeführt.

 

[DanielB]

Danke für den Hinweis: Nein, das Script wird nicht mit Rootrecht ausgeführt.

Das Script mit Rootrechten auszuführen will/wollte ich vermeiden.
Zudem haben erste Versuche mit Rootrechten einen rsync-Code 52 zurückgeliefert, deren Ursache mir noch nicht klar ist:
rsync error: service disabled (code 52) at io.c(254) [sender=3.1.2]

Gruss Daniel

 

[luddi]

Den Befehl rsync auf dem Host als root auszuführen ist die eine Sache. Aber wie sieht es auf dem entfernten Zielserver aus?
Mit welchem User meldest du dich hierbei an?
Wenn ich das richtig gelesen habe ist es ein Admin User. Vielleicht liegt es genau daran, dass man sich auch auf dem Zielserver mit root authentifizieren muss.

Wie sieht denn dein gesamter rsync Befehl aus? Würde mich interessieren.

 

[peterhoffmann]

Nachtrag:
Die Konstellation in meinem Fall ist nicht NAS1 zu NAS2, sondern von VolumeX zu VolumeY auf dem gleichen NAS.

 

[DanielB]

@luddi

Das Script wird mit dem Admin-User ausgeführt. Ebenso erfolgt die Anmeldung via ssh auf dem Zielserver auch mit dem Admin-User.

der rsync-Befehl sieht wie folgt aus:
-e ssh -p 12345 -l admin --syno-acl -vvv --archive -h --itemize-changes --stats --delete --backup --backup-dir=./@backup/2023-12-24 /volume1/System/Script/_Test Script/ xxxxxxx.dscloud.me:/volume1/NAS-B20\ Datensicherung/_Test\ Script/

In diesem Fall werden die Daten übertragen, aber OWNER/GROUP und Permission nicht vollständig übernommen.

Anmerkung: Port und DNS sind anonymisiert.

Wenn der Script als Root läuft und die Anmeldung ebenfalls als Root erfolgt gibt es folgenden Fehler
- rsync error: service disabled (code 52) at io.c(254) [sender=3.1.2]

Offen ist noch der Versuch mit:
rsync-path='sudo admin'

 

[luddi]

Okay ich denke ich habe verstanden woran das Problem liegt.

rsync error: service disabled (code 52) at io.c(254) [sender=3.1.2]

Der Fehler "service disabled" macht hier auch Sinn, wenn man versucht, als root auf dem Zielserver mittels User/Passwort zu authentifizieren.
DSM erlaubt dies nämlich nicht.
Was mich dennoch wundert, wie führst du die Anmeldung für den Admin per Script aus? Wo wird das Passwort übergeben? Das geht aus dem Befehl nicht hervor.

Aber zurück zum eigentlichen Problem bzw. Lösungsvorschlag.
Um eine erfolgreiche Anmeldung mittels root am Zielserver auszuführen, schlage ich vor, dass man ein RSA Schlüsselpaar erstellt und sich mittels diesem anmeldet. Damit klappt auch die Authentifizierung direkt mit dem User root. Und wenn das ganze Script basiert laufen soll dann empfehle ich ein RSA Schlüssel ohne Passwort.

Hier mal ein Beispiel wie der rsync Aufruf mittels RSA Key aussehen würde.

rsync -<OPTIONS> -e "ssh -p <PORT> -i <PATH_TO_RSA_PRIVATE_KEY>" <SOURCE> root@<REMOTE_HOST>:<TARGET>

Wie man ein RSA Schlüsselpaar erzeugt und wie man den Public Key auf dem entfernten Server ablegt (installiert) werde ich hier nicht im Detail erläutern, dazu gibt es bereits genügend Anleitungen. Falls Fragen aufkommen stehen wir dennoch gern zur Unterstützung bereit.

 

[Tommes]

Hi!

In diesem Fall werden die Daten übertragen, aber OWNER/GROUP und Permission nicht vollständig übernommen.

Eigentlich sollten die Gruppenrechte (Option -g) ins Ziel übertragen werden, die Besitzrechte (Option -o) werden nur mit root-Rechten im Ziel abgelegt. Ich verwende bei Zugriffsproblemen bei einem Push-Backup hier im Zweifel die Option --chmod=ugo=rwX, auch wenn das am Ende alles über den Haufen wirft.

rsync -<OPTIONS> -e "ssh -p <PORT> -i <PATH_TO_RSA_PRIVATE_KEY>" <SOURCE> root@<REMOTE_HOST>:<TARGET>

Weißt ja… bei einem Push oder Pull Backup auf bzw. von einem Remote Server, rsync immer schön die Option -s mitgeben, damit auch Leer- und Sonderzeichen in Ordner und Dateinamen übertragen werden.

Um eine erfolgreiche Anmeldung mittels root am Zielserver auszuführen, schlage ich vor, dass man ein RSA Schlüsselpaar erstellt und sich mittels diesem anmeldet

Meines Wissens funktioniert das in Verbindung mit einer Remote DiskStation nicht auf Anhieb, da Synology die ssh Aufschaltung als root in diesem Fall unterbindet. Man müsste auf der Remote DiskStation noch ein paar Modifikationen durchführen, damit das möglich ist. Was genau das war, kann ich grad nicht beantworten. Würde aber auch davon abraten, dies zu tun.

Tommes

 

[DanielB]

@luddi
Danke für die Info.
Für die Anmeldung wird kein Password verwendet. Die Anmeldung erfolgt mit den ssh "Schlüsselpaaren", ohne Password erstellt.
Durch die Angabe des Benutzers -l Admin, wird im entsprechenden home Verzeichnis auf dem Source-NAS der Schlüssel gesucht.

Die ssh Verbindung von NAS1 zu NAS2 kann erfolgreich mit dem "User" root durchgeführt werden. Nur in Verbindung mit rsync funktioniert es beim root nicht.

Ich werde nun aber noch einen Versuch machen, indem ich den Schlüssel direkt via dem Parameter -i mitgebe.

@Tommes
Das der Owner nur mit Root-Rechten im Ziel abgelegt wird, habe ich so klar formuliert noch nicht gefunden. Aber jetzt weiss ich wenigstens, warum die Owner nicht übernommen werden. Vielen Dank.

Die ssh-Anmeldung als root konnte ich ohne Modifikation auf der Remote DiskStation einrichten. Es war nur ein bisschen kniffelig, die Schlüssel in autorized-keys zu übertragen.

Gruss Daniel

 

[luddi]

Ich glaube, ich muss wohl meinen Lösungsvorschlag revidieren. Es sieht wohl tatsächlich so aus als würde rsync für root nicht funktionieren. Ich war der Meinung, dass dies bei einer älteren DSM Version noch möglich war. Aber auch ich bekomme es gerade nicht hin mittels root via rsync eine Datei zu übertragen.

Bei mir kommt allerdings dieser Fehler:

rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(231) [sender=3.2.7]

 

[Tommes]

Das der Owner nur mit Root-Rechten im Ziel abgelegt wird, habe ich so klar formuliert noch nicht gefunden.

Auszug aus der rsync man page ...

-o, --owner
This option causes rsync to set the owner of the destination file to be the same as the source file, but only if the receiving rsync is being run as the super-user (see also the --super and --fake-super options). Without this option, the owner of new and/or transferred files are set to the invoking user on the receiving side.

Die ssh-Anmeldung als root konnte ich ohne Modifikation auf der Remote DiskStation einrichten.

Wir reden jetzt davon, das man sich in Verbindung mit einer Passwortlosen Public-Key Authentifizierung direkt per SSH auf der Remote-DiskStation als root anmelden kann. Was aber nicht funktioniert, ist der Verbindungsaufbau als root über rsync bzw. -e "ssh ...." Dafür müssen glaube ich Änderungen in der sshd_config vorgenommen werden... ich meine irgendwas mit PermitRootLogin yes .. oder so.

Tommes

 

[luddi]

@DanielB In diesem Beitrag Rsync als root per ssh auf Synology: wrong password (code 44) hatten wir schon einmal über das Thema diskutiert. Jedoch habe ich bisher auch nichts weiter unternommen, um herauszufinden, wie man rsync via root auführen kann.

 

[Tommes]

Laut dem Beitrag #26 in dem von dir verlinkten Thread wird wohl die Lösung beschrieben. Die größte Gefahr sehe ich jedoch darin, den Benutzer admin im DSM zu aktivieren. Das würde ich nur in Verbindung mit einem wirklich starken Passwort tun und auch nur dann, wenn meine DiskStation nicht vom Internet aus erreichbar ist. Aber das muss ja jeder selbst entscheiden.

Auch bin ich mir nicht sicher, ob Änderungen in der sshd_config ein DSM Update überleben.

 

[DanielB]

Liebe Forennutzer
Ich danke Euch allen für die Vorschläge und Unterstützung.

Wie in einem früheren Task angesprochen habe ich nun auch noch den Versuch mit rsync-path='sudo xxxxx' durchgeführt - gemäss Anleitung eines Forenbeitrags. Natürlich mit vorheriger Anpassung der Datei sudoers.
Aber diese Variante hat zu folgendem Fehler geführt:
[sender] _exit_cleanup(code=43, file=io.c, line=254): entered
rsync error: service disabled (code 52) at io.c(254) [sender=3.1.2]
[sender] _exit_cleanup(code=43, file=io.c, line=254): about to call exit(52)

Der SSH-Verbindungsaufbau scheint mit mit root über rsync bzw. -e "ssh ...." zu funktionieren, aber schlussendlich gibt es die gleiche Fehlermeldung wie oben beschrieben.
ssh-Log: debug1: Authentication succeeded (publickey).


Vom Synology Support selber wurde mir die "Synchronisation freigegebener Ordner" empfohlen. Ich habe das durchgespielt und die Rechte wurden 1:1 inkl. Owner/Gruppen übernommen. Leider ist nicht erkennbar wie Synology dies macht.
Zudem deckt dies nicht meine Anforderung ab.


Ich werde nun eine andere Lösung suchen.

 

[DanielB]

In der Synology Dokumentation habe ich noch folgenden Hinweis gefunden. Gemäss diesem Hinweis können Owner und Gruppe mit Administratorenrechte übernommen werden, aber im Daemon-Modus.

https://kb.synology.com/de-de/DSM/help/DSM/AdminCenter/file_rsync?version=7

Anmerkung:​

• Um den rsync-Dienst zu nutzen, müssen DSM-Benutzer die verschlüsselte Übertragung verwenden. Rsync-Konten können nur unverschlüsselte Übertragung verwenden.
• Um eine rsync-Sicherung von Synology NAS oder anderen Client-Geräten vorzunehmen und dabei die Informationen des Besitzers und der Gruppe der Quelldaten beizubehalten, müssen Sie im Daemon-Modus Folgendes tun:
  • Fügen Sie die rsync-Konten zur Gruppe administrators hinzu.
  • Sichern Sie Daten im freigegebenen Ordner NetBackup.