rsync - Echec de mkstemp: autorisation refusée (13)
J'ai la configuration suivante pour gérer périodiquement les fichiers rsync du serveur A au serveur B. Le démon rsync est exécuté sur le serveur B avec la configuration suivante:
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
Depuis le serveur A, j'émets la commande suivante:
rsync -adzPvO --delete --password-file=/path/to/pwd/file/pwd.dat /dir/to/be/backedup/ [email protected]::BACKUP
Le répertoire BACKUP est entièrement lu/écrit/exécuté à tout le monde. Lorsque j'exécute la commande rsync à partir du serveur A, je vois:
afile.txt
989 100% 2.60kB/s 0:00:00 (xfer#78, to-check=0/79)
pour chaque fichier du répertoire que je souhaite sauvegarder. Cela échoue lorsque j'écris des fichiers tmp:
rsync: mkstemp "/.afile.txt.PZQvTe" (in BACKUP) failed: Permission denied (13)
Des heures à googler plus tard et je ne peux toujours pas résoudre ce qui semble être un problème de permission très simple. Conseil? Merci d'avance.
Information additionnelle
Je viens de remarquer que ce qui suit se produit au début du processus:
rsync: failed to set permissions on "/." (in BACKUP): Permission denied (13)
Est-ce qu'il essaie de définir l'autorisation sur "/"?
Modifier
Je suis connecté en tant qu'utilisateur - someuser. Mon répertoire de destination dispose des autorisations complètes en lecture/écriture/exécution pour tout le monde, y compris son contenu. De plus, le répertoire de destination appartient à someuser et à son groupe.
Suivre
J'ai trouvé l'utilisation de SSH qui résout ce problème
Assurez-vous que l'utilisateur sur lequel vous êtes synchronisé sur la machine distante dispose d'un accès en écriture au contenu du dossier ET au dossier lui-même, car rsync a tenté de mettre à jour l'heure de modification du dossier lui-même.
Bien que cela fonctionne, j'ai récemment eu une rencontre similaire et aucune SO ou recherche dans Google n'a été d'aucune aide, car elles traitaient toutes de problèmes de base en matière d'autorisation, la solution ci-dessous étant un peu décalée. pense même à vérifier dans la plupart des situations.
Une chose à vérifier avec autorisation a été refusée. J'ai récemment rencontré des problèmes avec rsync où les autorisations étaient exactement les mêmes sur les deux serveurs, y compris le propriétaire et le groupe, mais les transferts rsync fonctionnaient d'une manière sur un serveur mais pas dans l'autre.
Il s'est avéré que le serveur posait des problèmes pour lesquels l'autorisation m'était refusée si SELinux était activé, ce qui annulait les autorisations POSIX sur les fichiers/dossiers. Ainsi, même si le dossier en question aurait pu être 777 avec root en cours d'exécution, la commande SELinux était activée et écraserait à son tour les autorisations générant une erreur "autorisation refusée" de la part de rsync.
Vous pouvez exécuter la commande getenforce pour voir si SELinux est activé sur la machine.
Dans ma situation, j'ai fini par désactiver SELINUX complètement, car il n'était pas nécessaire et était déjà désactivé sur le serveur qui fonctionnait bien et qui causait des problèmes d'activation. Pour désactiver, ouvrez /etc/selinux/config et définissez SELINUX=disabled. Pour désactiver temporairement, vous pouvez exécuter la commande setenforce 0 qui définira SELinux dans un état permissive plutôt que dans un état enforcing qui le fera imprimer des avertissements au lieu de les forcer.
Le démon Rsync utilise par défaut nobody/nogroup pour tous les modules s’il est exécuté sous l’utilisateur root. Vous devez donc soit définir les paramètres uid et gid pour l'utilisateur souhaité, soit les définir sur root/root.
J'ai rencontré le même problème et l'ai résolu par chown l'utilisateur du dossier de destination. L'utilisateur actuel n'a pas l'autorisation de lire, écrire et exécuter les fichiers du dossier de destination. Essayez d'ajouter l'autorisation par chmod a+rwx <folder/file name>.
Cela pourrait ne pas convenir à tout le monde car cela ne préservait pas les autorisations de fichiers d'origine, mais dans mon cas, ce n'était pas important et cela a résolu le problème pour moi. rsync a une option --chmod:
--chmod Cette option indique à rsync d'appliquer une ou plusieurs chaînes lqchmodrq séparées par des virgules à l'autorisation des fichiers du transfert. Le la valeur résultante est traitée comme si c’était les autorisations que le côté envoi fourni pour le fichier, ce qui signifie que cette option peut semble ne pas avoir d'effet sur les fichiers existants si --perms n'est pas activé.
Cela force les autorisations à être ce que vous voulez sur tous les fichiers/répertoires. Par exemple:
rsync -av --chmod=Du+rwx SRC DST
ajouterait Lecture, Écriture et Exécution pour l’utilisateur à tous les répertoires transférés.
J'avais un problème similaire, mais dans mon cas, c'était parce que le stockage ne contient que SFTP, sans démons ssh ou rsync. Je ne pouvais rien changer, ce serveur a été fourni par mon client.
rsync n'a pas pu changer la date et l'heure du fichier, d'autres utilitaires (comme csync) m'ont signalé d'autres erreurs: "Impossible de créer le fichier temporaire Clock skew detecté" openssh-server ou lancez rsync en tant que démon ici.
Dans mon cas - je ne pouvais pas faire cela et la solution était: lftp . L’utilisation de lftp pour la synchronisation est la suivante:
lftp -c "open -u login,password sftp://sft.domain.tld/; mirror -c --verbose=9 -e -R -L /srs/folder /rem/folder"
/ src/folder - est le dossier sur mon PC,/rem/folder - est sftp: //sft.domain.tld/rem/folder.
vous pouvez trouver mans par le lien lftp.yar.ru/lftp-man.html
Windows: Vérifiez les autorisations des dossiers de destination. Devenez propriétaire si vous devez donner des droits au compte qui exécute le service rsync.
J'imagine qu'une erreur commune non mentionnée ci-dessus tente d'écrire dans un espace de montage (par exemple, /media/drivename) lorsque la partition n'est pas montée. Cela produira également cette erreur.
Si le lecteur crypté est configuré pour le montage automatique mais ne le fait pas, le problème peut être de déverrouiller automatiquement la partition cryptée avant de tenter d'écrire dans l'espace où elle est censée être montée.
J'ai eu la même erreur lors de la synchronisation de fichiers à l'intérieur d'un conteneur Docker et la destination était un volume monté (Docker pour mac), j'ai lancé rsync via su-exec <user>. J'ai pu résoudre le problème en exécutant rsync sous la forme root avec les indicateurs -og (conservez le propriétaire et le groupe pour les fichiers de destination).
Je ne suis toujours pas sûr de la cause de ce problème, les autorisations de destination étaient correctes (j'exécute chown -R <user> pour le répertoire de destination avant rsync), peut-être en quelque sorte lié au système de fichiers lent Docker for Mac.