rsync - mkstemp fehlgeschlagen: Zugriff verweigert (13)

Question

Ich habe folgendes Setup regelmäßig rsync Dateien vom Server A auf Server B. Server B hat den rsync-Daemon mit der folgenden Konfiguration ausgeführt wird:

read only = false 
use chroot = false 
max connections = 4 
syslog facility = local5 
log file = /var/adm/rsyncd.log 
munge symlinks = false 
secrets file = /etc/rsyncd.secrets 
numeric ids = false 
transfer logging = true 
log format = %h %o %f %l %b 


[BACKUP] 
     path = /path/to/archive 
     auth users = someuser 

Von Server AI gibt den folgenden Befehl aus:

rsync -adzPvO --delete --password-file=/path/to/pwd/file/pwd.dat /dir/to/be/backedup/ someuser@192.168.100.100::BACKUP 

BACKUP-Verzeichnis ist vollständig lesen/schreiben/ausführen für alle. Als ich den rsync Befehl von Server A ausführen, sehe ich:

afile.txt 
     989 100% 2.60kB/s 0:00:00 (xfer#78, to-check=0/79) 

für jeden und everyfile im Verzeichnis I sichern möchte. Es schlägt fehl, wenn ich tmp-Dateien zu schreiben bekommen:

rsync: mkstemp "/.afile.txt.PZQvTe" (in BACKUP) failed: Permission denied (13) 

Stunden googeln später, und ich kann immer noch nicht lösen, was ein sehr einfaches Berechtigungsproblem zu sein scheint. Rat? Danke im Voraus.

Weitere Informationen

Ich habe gerade bemerkt, die am Anfang des Prozesses folgenden Ereignisse eintritt:

rsync: failed to set permissions on "/." (in BACKUP): Permission denied (13) 

Ist es auf „/“, um die Erlaubnis versuchen?

bearbeiten

Ich bin als Benutzer angemeldet - einbenutzer. Mein Zielverzeichnis hat volle Lese-/Schreib-/Ausführungsrechte für alle Benutzer, einschließlich des Inhalts. Darüber hinaus gehört das Zielverzeichnis einigen Benutzern und in der Gruppe eines Benutzers.

Follow-up

ich gefunden habe, mit SSH löst diese

Answer 1

Vergewissern Sie sich der Benutzer, den Sie auf dem entfernten Rechner rsync'd in sind hat Zugriff auf den Inhalt des Ordners schreiben und die Ordner selbst, als rsync versuchte, die Änderungszeit für den Ordner selbst zu aktualisieren.

Answer 2

Obwohl Sie das funktionierte, hatte ich vor kurzem eine ähnliche Begegnung und keine SO oder Google-Suche war von irgendwelcher Hilfe, da sie alle mit grundlegenden Erlaubnisproblemen behandelten, wo die Lösung unten eine Einstellung ist, die Sie nicht würden Denken Sie sogar daran, in den meisten Situationen nachzusehen.

Eine Sache zu prüfen mit Erlaubnis verweigert, dass ich vor kurzem Probleme mit rsync selbst gefunden, wo Berechtigungen waren genau die gleichen auf beiden Servern einschließlich des Eigentümers und der Gruppe, aber Rsync-Übertragungen funktioniert auf einem Server, aber nicht umgekehrt.

Es stellte sich heraus, dass der Server mit Problemen, bei denen ich die Berechtigung verweigert bekam, SELinux aktiviert hatte, was wiederum die POSIX-Berechtigungen für Dateien/Ordner außer Kraft setzt. Obwohl der fragliche Ordner 777 mit laufendem Root hätte sein können, wurde der Befehl SELinux aktiviert und würde diese Berechtigungen überschreiben, die einen "permission denied" -Fehler von rsync erzeugten.

Sie können den Befehl getenforce ausführen, um zu sehen, ob SELinux auf dem Computer aktiviert ist.

In meiner Situation beendete ich gerade SELINUX vollständig deaktivieren, weil es nicht benötigt wurde und bereits auf dem Server deaktiviert, die gut funktionierte und nur Probleme verursacht wurde aktiviert. Zum Deaktivieren öffnen Sie /etc/selinux/config und setzen Sie SELINUX=disabled. Zur vorübergehenden Deaktivierung können Sie den Befehl setenforce 0 ausführen, der SELinux in einen Zustand permissive anstatt enforcing versetzt, wodurch Warnungen ausgegeben werden, anstatt zu erzwingen.

Answer 3

Rsync-Daemon verwendet standardmäßig nobody/nogroup für alle Module, wenn es unter root-Benutzer ausgeführt wird. Sie müssen also entweder die Parameter uid und gid für den gewünschten Benutzer definieren oder sie auf root/root setzen.

Answer 4

Ich hatte ein ähnliches Problem, aber in meinem Fall war es, weil Speicher nur SFTP hat, ohne ssh oder rsync Daemons darauf. Ich konnte nichts ändern, bcs dieser Server wurde von meinem Kunden zur Verfügung gestellt.

rsync konnte das Datum und die Uhrzeit für die Datei nicht ändern, einige andere utilites (wie csync) zeigten mir andere Fehler: "Es konnte keine temporäre Datei erstellt werden Clock skew detected". Wenn Sie Zugriff auf den Storage-Server haben, installieren Sie einfach openssh-server oder starten Sie rsync als Daemon hier.

In meinem Fall - ich konnte dies nicht tun und die Lösung war: lftp. lftp die Nutzung für syncronization unten:

lftp -c "open -u login,password sftp://sft.domain.tld/; mirror -c --verbose=9 -e -R -L /srs/folder /rem/folder" 

/src/Ordner - ist der Ordner auf meinem PC,/rem/Ordner - ist SFTP: //sft.domain.tld/rem/folder.

Sie mans durch den Link lftp.yar.ru/lftp-man.html

Answer 5

Lauf in Root-Zugriff ssh finden

oder chmod 0777 /dir/to/be/backedup/

oder chown username:user /dir/to/be/backedup/ dieses Problem

Answer 6

chould lösen

Windows: Überprüfen Sie die Berechtigungen der Zielordner. Übernehmen Sie das Eigentumsrecht, wenn Sie dem Konto, auf dem der rsync-Dienst ausgeführt wird, Rechte gewähren müssen.

Answer 7

Das mag nicht jedem passen, da es nicht die ursprünglichen Dateiberechtigungen behält, aber in meinem Fall war es nicht wichtig und löste das Problem für mich. rsync hat eine Option --chmod:

--chmod Diese Option rsync sagt einem oder mehr durch Kommata getrennte lqchmodrq Strings an die Genehmigung der Dateien bei der Übertragung anzuwenden. Der sich ergebende Wert wird so behandelt, als wären es die Berechtigungen, die die sendende Seite für die Datei lieferte, was bedeutet, dass diese Option scheinbar keine Auswirkungen auf vorhandene Dateien hat, wenn --perms nicht aktiviert ist.

Dadurch werden die Berechtigungen für alle Dateien/Verzeichnisse so festgelegt, wie Sie möchten. Zum Beispiel:

rsync -av --chmod=Du+rwx SRC DST 

würde Lesen, Schreiben und Ausführen für den Benutzer zu allen übertragenen Verzeichnissen hinzufügen.

Answer 8

Ich stelle mir vor, ein allgemeiner Fehler, der derzeit nicht oben erwähnt wird, versucht, in einen Einbauraum zu schreiben (z. B. /media/drivename), wenn die Partition nicht bereitgestellt ist. Das wird auch diesen Fehler erzeugen.

Wenn es sich bei einem verschlüsselten Laufwerk um automatisches Mounten handelt, aber nicht, dann kann es ein Problem sein, die verschlüsselte Partition automatisch zu entsperren, bevor Sie versuchen, in den Bereich zu schreiben, in dem es eingehängt werden soll.

Answer 9

Ich hatte den gleichen Fehler beim Synchronisieren von Dateien in einem Docker-Container und das Ziel war ein eingehängtes Volume (Docker für Mac), ich rsync über su-exec <user> ausführen. Ich konnte es lösen, indem ich rsync als root mit -og Flags (Besitzer und Gruppe für Zieldateien beibehalten) ausführen.

Ich bin immer noch nicht sicher, was dieses Problem verursacht, die Zielberechtigungen waren in Ordnung (ich chown -R <user> für Zielverzeichnis vor rsync), vielleicht irgendwie verwandt mit Docker für Mac langsamen Dateisystem.

Answer 10

Ich stoße dieses Problem auch, und löse es durch "chown" den Benutzer des Ziel Floders. Ich denke, es ist ok für chmod a + rwx.