7
RSync kann Berechtiungen nicht übermitteln
Guten Tag
Ich versuche von einem Netgear NAS auf ein anderes, meine Backups zu kopieren. Dies hat bis jetzt eigentlich auch immmer super funktioniert und ich glaube ab dem letzten Firmware Update funktioniert es nicht mehr richtig. Ich habe natürlich auch schon im Netgear Forum nachgefragt, doch leider konnte mir dort niemand weiterhelfen.
FSTAB Eintrag sieht so aus:
//192.168.x.x/backup /mnt/pdzhnas2_backup cifs username=xxx,password=xxx 0 0
Mein RSync Befehl ist folgendermassen:
rsync -az $SOURCE --bwlimit=$C_SPEEDLIMIT_KB --partial --delete --stats $TARGET >> $C_LOGFILE
Fehlermeldung:
rsync: chown "/mnt/pdzhnas2_backup/Test/." failed: Permission denied (13)
rsync: chgrp "/mnt/pdzhnas2_backup/Test/cool.txt" failed: Permission denied (13)
Quelle und Ziel NAS sind folgender Typ:
ReadyNAS 2100
RAIDiator-x86 4.2.22
Nun das kopieren funktioniert einwandfrei, nur leider kann es die Rechte (Permissions) nicht mehr übermitteln. Woran könnte das Problem liegen?
Vielen Dank
Ich versuche von einem Netgear NAS auf ein anderes, meine Backups zu kopieren. Dies hat bis jetzt eigentlich auch immmer super funktioniert und ich glaube ab dem letzten Firmware Update funktioniert es nicht mehr richtig. Ich habe natürlich auch schon im Netgear Forum nachgefragt, doch leider konnte mir dort niemand weiterhelfen.
FSTAB Eintrag sieht so aus:
//192.168.x.x/backup /mnt/pdzhnas2_backup cifs username=xxx,password=xxx 0 0
Mein RSync Befehl ist folgendermassen:
rsync -az $SOURCE --bwlimit=$C_SPEEDLIMIT_KB --partial --delete --stats $TARGET >> $C_LOGFILE
Fehlermeldung:
rsync: chown "/mnt/pdzhnas2_backup/Test/." failed: Permission denied (13)
rsync: chgrp "/mnt/pdzhnas2_backup/Test/cool.txt" failed: Permission denied (13)
Quelle und Ziel NAS sind folgender Typ:
ReadyNAS 2100
RAIDiator-x86 4.2.22
Nun das kopieren funktioniert einwandfrei, nur leider kann es die Rechte (Permissions) nicht mehr übermitteln. Woran könnte das Problem liegen?
Vielen Dank
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 201384
Url: https://administrator.de/contentid/201384
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
ich vermute dass auf deinen Ziel ein Dateisystem ist, welches keine Berechtigungen speichern kann.
Zum Beispiel FAT32.
Gruß Alex
ich vermute dass auf deinen Ziel ein Dateisystem ist, welches keine Berechtigungen speichern kann.
Zum Beispiel FAT32.
Gruß Alex
Moin,
ich würde einen Bug in Raidiator vermuten.
Meine Konfig:
ReadyNAS3100, Raidiator 4.2.22 (als Sicherungsziel)
Ubuntu 12.04LTS als Rsync-Server / Sicherungsquelle
Ich konfiguriere beide Seiten (zu Testzwecken erst mal ohne SSL), der Verbindungstest auf Seiten der ReadyNAS funktioniert einwandfrei. Starte ich den Backupjob auf der ReadyNAS, werden stundenlang die Verzeichnisse ermittelt und es passiert nichts mehr. Gegenprobe mit einem Win7 Pro-Rechner und der Rsync-Implementation DeltaCopy als Rsync-Server: Läuft, zumindest während meiner (wenn auch recht kurzen) Testphase. Die Fehlermeldungen in den Logs deuten auf ein Rechteproblem hin, ohne dass ich das jetzt eingrenzen könnte. In den nächsten Tag teste ich noch mal mit einem QNAP-NAS als Rsync-Server.
Meine Suche nach Hilfe im Netgear-Forum war ebenfalls erfolglos. Bei Netgear habe ich einen Call eröffnet, der lediglich folgende Antwort ergeben hat: Linux ist als Rsync-Server "nicht supportet". Aha, dann vielen Dank....
In zwei Ubuntu-Foren konnte ich ebenfalls nichts in Erfahrung bringen.
@facebraker: FAT32 auf der ReadyNAS?!? Wohl kaum.
ich würde einen Bug in Raidiator vermuten.
Meine Konfig:
ReadyNAS3100, Raidiator 4.2.22 (als Sicherungsziel)
Ubuntu 12.04LTS als Rsync-Server / Sicherungsquelle
Ich konfiguriere beide Seiten (zu Testzwecken erst mal ohne SSL), der Verbindungstest auf Seiten der ReadyNAS funktioniert einwandfrei. Starte ich den Backupjob auf der ReadyNAS, werden stundenlang die Verzeichnisse ermittelt und es passiert nichts mehr. Gegenprobe mit einem Win7 Pro-Rechner und der Rsync-Implementation DeltaCopy als Rsync-Server: Läuft, zumindest während meiner (wenn auch recht kurzen) Testphase. Die Fehlermeldungen in den Logs deuten auf ein Rechteproblem hin, ohne dass ich das jetzt eingrenzen könnte. In den nächsten Tag teste ich noch mal mit einem QNAP-NAS als Rsync-Server.
Meine Suche nach Hilfe im Netgear-Forum war ebenfalls erfolglos. Bei Netgear habe ich einen Call eröffnet, der lediglich folgende Antwort ergeben hat: Linux ist als Rsync-Server "nicht supportet". Aha, dann vielen Dank....
In zwei Ubuntu-Foren konnte ich ebenfalls nichts in Erfahrung bringen.
@facebraker: FAT32 auf der ReadyNAS?!? Wohl kaum.
Hallo zusammen,
Ein anderer möglicher Fehler ist, dass der kopierende Benutzer die Berechtigungen von einem Benutzer mit höherer Berechtigung setzen will, das geht grundsätzlich nicht. Auf Deutsch: ein normaler Benutzer kann keine Dateien dem Benutzer root zuweisen.
Kann es sein, dass durch das Firmware-Update die Benutzer-IDs verändert worden sind?
Markus
Fehlermeldung:
rsync: chown "/mnt/pdzhnas2_backup/Test/." failed: Permission denied (13)
rsync: chgrp "/mnt/pdzhnas2_backup/Test/cool.txt" failed: Permission denied (13)
das kann darauf hindeuten, dass der "kopierende" Benutzer auf der Quelle auf dem Zielrechner (NAS) nicht vorhanden ist (vergleiche nicht den Benutzernamen sondern die Benutzer-ID).rsync: chown "/mnt/pdzhnas2_backup/Test/." failed: Permission denied (13)
rsync: chgrp "/mnt/pdzhnas2_backup/Test/cool.txt" failed: Permission denied (13)
Ein anderer möglicher Fehler ist, dass der kopierende Benutzer die Berechtigungen von einem Benutzer mit höherer Berechtigung setzen will, das geht grundsätzlich nicht. Auf Deutsch: ein normaler Benutzer kann keine Dateien dem Benutzer root zuweisen.
Kann es sein, dass durch das Firmware-Update die Benutzer-IDs verändert worden sind?
Markus
Hallo
Also bei der Firmware 4.2.19 hat es bei mir noch einwandfrei funktioniert. Laut den changelogs von der Firmware, sollte sich dort nichts geändert haben. Wahrscheinlich haben sie dennoch irgendwo etwas geändert.
@facebraker
Es ist NTFS.
@Coreknabe
Linux ist als Rsync-Server nicht supportet??? Ist ja wohl ein Witz oder?
@64748
Möglich ist alles. Wie kann ich denn die Benutzer-ID kontrollieren?
Folgenden Test habe ich einmal gemacht:
NAS1 LOKAL: chown veeam test.txt [ok]
NAS2 LOKAL: chown veeam test.txt [ok]
NAS1 --> Mount NAS2: chown veeam test.txt [permission denied]
Komisch... weil der User veeam gibts eigentlich sowohl auf dem Lokalen als auf remote NAS und sollte alle Berechtigungen haben.
Nun habe ich einmal versucht auf einem NAS via Windows NTFS Permissions zu setzten. Und es ist tatsächlich so, dass ich keine Domain-Users hinzufügen kann. Hmm bin mir jetzt nicht mehr hundert prozentig sicher, aber ich glaube früher hat das funktionert.
Gruss
Also bei der Firmware 4.2.19 hat es bei mir noch einwandfrei funktioniert. Laut den changelogs von der Firmware, sollte sich dort nichts geändert haben. Wahrscheinlich haben sie dennoch irgendwo etwas geändert.
@facebraker
Es ist NTFS.
@Coreknabe
Linux ist als Rsync-Server nicht supportet??? Ist ja wohl ein Witz oder?
@64748
Möglich ist alles. Wie kann ich denn die Benutzer-ID kontrollieren?
Folgenden Test habe ich einmal gemacht:
NAS1 LOKAL: chown veeam test.txt [ok]
NAS2 LOKAL: chown veeam test.txt [ok]
NAS1 --> Mount NAS2: chown veeam test.txt [permission denied]
Komisch... weil der User veeam gibts eigentlich sowohl auf dem Lokalen als auf remote NAS und sollte alle Berechtigungen haben.
Nun habe ich einmal versucht auf einem NAS via Windows NTFS Permissions zu setzten. Und es ist tatsächlich so, dass ich keine Domain-Users hinzufügen kann. Hmm bin mir jetzt nicht mehr hundert prozentig sicher, aber ich glaube früher hat das funktionert.
Gruss
Also auf einem Unixsystem kann man die Benutzer-ID (uid) in der Datei /etc/passwd nachsehen.
Ändern derselben geht mit dem usermod Befehl mit der Option -u oder --uid. Allerdings weiß ich nicht, ob man das so auf den NAS-Systemen machen kann.
Du kannst (falls kein Linux oder Unix vorhanden) die Manpage zum Befehl usermod auch mit Google finden, einfach "man usermod" bei Google eingeben.
So wie Du es beschreibst, also wann genau der Berechtigungsfehler auftritt, gehe ich davon aus, dass es etwas in dieser Richtung ist.
Eine andere Sache ist, Du könntest versuchen herauszufinden, ob rsync mit irgendwelchen default-Optionen aufgerufen wird, von denen Du nix weißt. Darin unterscheiden sich die Tools in den verschiedenen Linux-Distributionen gerne schonmal. Ich würde empfehlen, auch die Manpage von rsync zu konsultieren.
Markus
Ändern derselben geht mit dem usermod Befehl mit der Option -u oder --uid. Allerdings weiß ich nicht, ob man das so auf den NAS-Systemen machen kann.
Du kannst (falls kein Linux oder Unix vorhanden) die Manpage zum Befehl usermod auch mit Google finden, einfach "man usermod" bei Google eingeben.
So wie Du es beschreibst, also wann genau der Berechtigungsfehler auftritt, gehe ich davon aus, dass es etwas in dieser Richtung ist.
Eine andere Sache ist, Du könntest versuchen herauszufinden, ob rsync mit irgendwelchen default-Optionen aufgerufen wird, von denen Du nix weißt. Darin unterscheiden sich die Tools in den verschiedenen Linux-Distributionen gerne schonmal. Ich würde empfehlen, auch die Manpage von rsync zu konsultieren.
Markus
Hallo
@Markus
Danke für den Tipp. Ich bin nicht so der Linuxguru. Also ich habe es nun geschafft auch dem remote user die selbe uid zu vergeben. Leider funktioniert auch dies nicht, wenn ich mit chown versuche die Berechtigung auf ein Remote File zu setzen. Da brauche ich wohl auch gar nicht mehr weiter mit rsync zu suchen. Ich habe eher zuerst gedacht, dass der Fehler schon beim mounten passiert.
#/etc/fstab
//192.168.x.x/backup /mnt/pdzhnas2_backup cifs username=xxx,password=xxx 0 0
Danke schon einmal
Gruss
@Markus
Danke für den Tipp. Ich bin nicht so der Linuxguru. Also ich habe es nun geschafft auch dem remote user die selbe uid zu vergeben. Leider funktioniert auch dies nicht, wenn ich mit chown versuche die Berechtigung auf ein Remote File zu setzen. Da brauche ich wohl auch gar nicht mehr weiter mit rsync zu suchen. Ich habe eher zuerst gedacht, dass der Fehler schon beim mounten passiert.
#/etc/fstab
//192.168.x.x/backup /mnt/pdzhnas2_backup cifs username=xxx,password=xxx 0 0
Danke schon einmal
Gruss
naja, jetzt wo Du darauf hinweist fällt mir das auf
#/etc/fstab
192.168.x.x:backup /mnt/pdzhnas2_backup cifs username=xxx,password=xxx 0 0
So würde man das auf einem Linuxrechner in /etc/fstab eintragen (so ist es hier)
Allerdings: wenn rsync grundsätzlich geht, dann ist der Mountpoint richtig angelegt, vielleicht suchst Du mal in der manpage für den mount-Befehl bzw für fstab danach, wie man Benutzername und Passwort korrekt übergibt.....
Markus
Edit: ich merke gerade, dass ich keine Ahnung hab. Also die Übergabe von username und password wird so gemacht (wie bei Dir) bei einer Sambafreigabe, dann ist die Syntax //server/pfad richtig. Ich benutze aber nur NFS und hab mit Samba zu wenig Erfahrung. Das was ich oben geschrieben habe, also server:/pfad bezieht sich auf NFS.
So würde man das auf einem Linuxrechner in /etc/fstab eintragen (so ist es hier)
Allerdings: wenn rsync grundsätzlich geht, dann ist der Mountpoint richtig angelegt, vielleicht suchst Du mal in der manpage für den mount-Befehl bzw für fstab danach, wie man Benutzername und Passwort korrekt übergibt.....
Markus
Edit: ich merke gerade, dass ich keine Ahnung hab. Also die Übergabe von username und password wird so gemacht (wie bei Dir) bei einer Sambafreigabe, dann ist die Syntax //server/pfad richtig. Ich benutze aber nur NFS und hab mit Samba zu wenig Erfahrung. Das was ich oben geschrieben habe, also server:/pfad bezieht sich auf NFS.
