it-swarm.com.de

rsync - mkstemp fehlgeschlagen: Berechtigung abgelehnt (13)

Ich habe das folgende Setup, um Dateien von Server A auf Server B regelmäßig zu rsync zu retten. Auf Server B hat der Rsync-Dämon die folgende Konfiguration:

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 A gebe ich den folgenden Befehl aus:

rsync -adzPvO --delete --password-file=/path/to/pwd/file/pwd.dat /dir/to/be/backedup/ [email protected]::BACKUP

Das BACKUP-Verzeichnis kann von allen Benutzern vollständig gelesen/geschrieben/ausgeführt werden. Wenn ich den Befehl rsync von Server A aus ausführen, sehe ich Folgendes:

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

für jede einzelne Datei in dem Verzeichnis, das ich sichern möchte. Es schlägt fehl, wenn ich tmp-Dateien schreibe:

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

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

Zusätzliche Information

Ich habe gerade bemerkt, dass zu Beginn des Prozesses Folgendes auftritt:

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

Versucht es, die Erlaubnis auf "/" zu setzen?

Bearbeiten

Ich bin als Benutzer - irgendeiner Benutzer angemeldet. Mein Zielverzeichnis verfügt über vollständige Lese-, Schreib- und Ausführungsberechtigung für alle Benutzer, einschließlich des Inhalts. Außerdem gehört das Zielverzeichnis einigen Benutzern und einer Gruppe einiger Benutzer.

Nachverfolgen

Ich habe festgestellt, dass SSH das löst

41
user320487

Stellen Sie sicher, dass der Benutzer, mit dem Sie auf dem Remote-Computer rsync arbeiten, Schreibzugriff auf den Inhalt des Ordners UND den Ordner selbst hat, da rsync versucht hat, die Änderungszeit im Ordner selbst zu aktualisieren.

13
Mauvis Ledford

Obwohl Sie diese Funktion erfolgreich abgeschlossen haben, hatte ich kürzlich eine ähnliche Begegnung, und keine Suche nach SO oder Google war hilfreich, da sie alle mit grundlegenden Berechtigungsproblemen zu tun hatten, obwohl die Lösung unten etwas Abweichendes ist, was Sie nicht tun würden Denken Sie auch in den meisten Situationen nach.

Eine Sache, die ich mit Erlaubnis bestreiten konnte, dass ich kürzlich festgestellt habe, dass ich Probleme mit rsync selbst hatte, bei denen die Berechtigungen auf beiden Servern, einschließlich Eigentümer und Gruppe, genau gleich waren. Rsync-Übertragungen funktionierten jedoch auf einem Server, nicht jedoch auf dem anderen.

Es stellte sich heraus, dass der Server Probleme hatte, von denen mir die Erlaubnis verweigert wurde, wenn SELinux aktiviert war, wodurch POSIX-Berechtigungen für Dateien/Ordner überschrieben wurden. Auch wenn der betreffende Ordner 777 mit root ausgeführt werden konnte, wurde der Befehl SELinux aktiviert und würde wiederum die Berechtigungen überschreiben, die zu einem "Berechtigung verweigert" -Fehler von rsync führten.

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

In meiner Situation habe ich SELINUX einfach komplett deaktiviert, da es auf dem Server, der einwandfrei funktionierte und nicht aktiv war, bereits deaktiviert war. Zum Deaktivieren öffnen Sie /etc/selinux/config und legen SELINUX=disabled fest. Zum vorübergehenden Deaktivieren können Sie den Befehl setenforce 0 ausführen, der SELinux in einen permissive-Status und nicht enforcing-Status versetzt, wodurch Warnungen ausgegeben werden, anstatt sie zu erzwingen.

13
Jeff Wilbert

Der Rsync-Dämon verwendet standardmäßig für alle Module nobody/nogroup, wenn er 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.

8
Marki555

Ich bin auf das gleiche Problem gestoßen und habe es durch den Benutzer des Zielordners chown gelöst. Der aktuelle Benutzer hat keine Berechtigung zum Lesen, Schreiben und Ausführen der Zielordnerdateien. Versuchen Sie, die Berechtigung durch chmod a+rwx <folder/file name> hinzuzufügen.

6
hao

Dies ist möglicherweise nicht für jeden Benutzer geeignet, da die ursprünglichen Dateiberechtigungen nicht erhalten bleiben. In meinem Fall war dies jedoch nicht wichtig, und das Problem wurde für mich gelöst. rsync hat eine Option --chmod:

--chmod Mit dieser Option wird rsync angewiesen, eine oder mehrere durch Kommas getrennte lqchmodrq-Zeichenfolgen auf die Erlaubnis der Dateien in der Übertragung anzuwenden. Das Der resultierende Wert wird so behandelt, als wären die Berechtigungen die sendende Seite für die Datei, was bedeutet, dass diese Option scheinen keine Auswirkungen auf vorhandene Dateien zu haben, wenn --perms nicht aktiviert ist.

Dadurch werden die Berechtigungen für alle Dateien/Verzeichnisse wie gewünscht. Zum Beispiel:

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

würde für alle übertragenen Verzeichnisse Lesen, Schreiben und Ausführen für den Benutzer hinzufügen.

3
Zitrax

Ich hatte ein ähnliches Problem, aber in meinem Fall lag es daran, dass der Speicher nur SFTP ohne ssh- oder rsync-Daemons enthält. Ich konnte nichts ändern, weil dieser Server von meinem Kunden bereitgestellt wurde.

rsync konnte das Datum und die Uhrzeit für die Datei nicht ändern. Andere Utilities (wie csync) zeigten mir andere Fehler: "Temporäre Datei konnte nicht erstellt werden" Clock Skew wurde erkannt ". Wenn Sie Zugriff auf den Speicherserver haben, müssen Sie nur installieren openssh-server oder starten Sie hier rsync als Daemon.

In meinem Fall konnte ich dies nicht tun, und die Lösung lautete: lftp . Die Verwendung von lftp für die Synchronisation ist unten:

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

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

sie finden mans unter dem Link lftp.yar.ru/lftp-man.html

3
bolD

Windows: Überprüfen Sie die Berechtigungen der Zielordner. Übernehmen Sie den Besitz, wenn Sie dem Konto, das den rsync-Dienst ausführt, Rechte erteilen müssen.

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

Wenn es sich um ein verschlüsseltes Laufwerk handelt, für das die automatische Bereitstellung eingestellt ist, dies jedoch nicht der Fall ist, kann die verschlüsselte Partition automatisch entsperrt werden, bevor versucht wird, in den Speicherbereich zu schreiben, in den sie gemountet werden soll.

0
Wolf

Achten Sie auf - e ssh und jenkins @ localhost: im nächsten Beispiel:

rsync -r  -e ssh --chown=jenkins:admin --exclude .git --exclude Jenkinsfile --delete ./ [email protected]:/home/admin/web/xxx/public

Das hat mir geholfen

S. Heute wurde mir klar, dass, wenn Sie den Benutzer jenkins zu einer Gruppe hinzufügen, die Berechtigung nach dem Neustart des Slaves (Agenten) gültig ist. Und meine Lösung (- e ssh und jenkins @ localhost:) brauchen Sie nur, wenn Sie Agent/Server nicht neu starten können.

0
basil

Ich hatte das gleiche Problem im Fall von CentOS 7. Ich habe viele Artikel und Foren durchgesehen, konnte aber keine Lösung finden. Das Problem war mit SElinux. Das Deaktivieren von SElinux auf dem Server hat funktioniert. Überprüfen Sie den SELinux-Status auf der Serverseite (von wo Sie Daten mit rysnc abrufen). Befehle, um den SELinux-Status zu überprüfen und zu deaktivieren

$ getenforce

Durchsetzen von ## bedeutet, dass SElinux aktiviert ist

$ setenforce 0

$ getenforce

Freizügig

Versuchen Sie nun, den Befehl rsync auf der Client-Seite auszuführen, er hat bei mir funktioniert. Alles Gute!

0
aastha

Ich habe einen Centos 7-Server mit rsyncd an Bord: /etc/rsyncd.conf

[files]
path = /files

Standardmäßig blockiert Selinux den Zugriff für den Ordner "rsyncd to/files"

# this sets needed context to my /files folder
Sudo semanage fcontext -a -t rsync_data_t '/files(/.*)?'
Sudo restorecon -Rv '/files'
# sets needed booleans
Sudo setsebool -P rsync_client 1

Das Deaktivieren von Selinux ist eine einfache, aber keine gute Lösung

0
shmakovpn

Ich hatte den gleichen Fehler beim Synchronisieren von Dateien innerhalb eines Docker-Containers und das Ziel war ein eingehängtes Volume (Docker für Mac). Ich habe rsync über su-exec <user> ausgeführt. Ich konnte es auflösen, indem ich rsync als root mit -og-Flags ausführte (Besitzer und Gruppe für Zieldateien beibehalten).

Ich bin immer noch nicht sicher, was das Problem verursacht hat, die Zielberechtigungen waren in Ordnung (ich habe chown -R <user> für Zielverzeichnis vor rsync ausgeführt), vielleicht etwas mit Docker für Mac langsames Dateisystem verbunden.

0
chingis

Überraschenderweise hat niemand den mächtigen Sudo erwähnt. Hatte das gleiche Problem und Sudo hat es behoben

0
Rimski