rsync - mkstemp a échoué: Permission denied (13)
J'ai la configuration suivante périodiquement rsync fichiers à partir du serveur A vers le serveur B. le Serveur B est le démon rsync en cours d'exécution 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
De serveur Un je suis émission de la commande suivante:
rsync -adzPvO --delete --password-file=/path/to/pwd/file/pwd.dat /dir/to/be/backedup/[email protected]::BACKUP
Répertoire de SAUVEGARDE est entièrement en lecture/écriture/exécution pour tout le monde. Quand je lance la commande rsync à partir d'Un serveur, je vois:
afile.txt
989 100% 2.60kB/s 0:00:00 (xfer#78, to-check=0/79)
pour chaque et everyfile dans le répertoire que je souhaite de sauvegarde. Il échoue lorsque j'arrive à l'écriture de fichiers tmp:
rsync: mkstemp "/.afile.txt.PZQvTe" (in BACKUP) failed: Permission denied (13)
Heures de recherche sur google plus tard et je n'arrive toujours pas à résoudre ce qui semble être un très simple problème d'autorisation. Des conseils? Merci à l'avance.
Des Informations Supplémentaires
Je viens de remarquer ce qui suit se produit au début du processus:
rsync: failed to set permissions on "/." (in BACKUP): Permission denied (13)
Est-il en essayant de définir des autorisations sur "/"?
Modifier
Je suis connecté en tant qu'utilisateur someuser. Mon répertoire de destination est plein de lecture/écriture/exécution de la permission pour tout le monde, y compris son contenu. En outre, le répertoire de destination est la propriété de someuser et dans someuser du groupe.
Suivi
J'ai trouvé à l'aide de SSH permet de résoudre ce
- Est cette configuration qui avait travaillé un temps ?
- J'ai utiliser la même configuration pour TIRER via rsync, mais ce processus est un PUSH. Donc, pour répondre à votre question, je n'ai pas utilisé cette configuration dans ce genre de configuration.
- L'utilisation de SSH est une solution de contournement, pas vraiment une solution, ou la compréhension du problème d'autorisations ici. Je vais avoir un semblable problema et à l'aide de SSH n'est pas une option pour moi :/
- Erreur (13) est un dossier de problème d'autorisations. C'est bien expliqué ici superuser.com/questions/398146/...
Vous devez vous connecter pour publier un commentaire.
Assurez-vous que l'utilisateur que vous êtes rsync avais sur la machine distante a accès en écriture pour le contenu du dossier ET le dossier lui-même, comme rsync essayé de mettre à jour la date de modification sur le dossier lui-même.
Même si vous avez obtenu ce travail, j'ai récemment eu un semblable de la rencontre et de pas ou la recherche sur Google a été d'aucun secours, puisqu'ils sont tous traités de base, les problèmes d'autorisation considérant que la solution ci-dessous est un peu hors de réglage que vous n'auriez même pas pensé à vérifier dans la plupart des situations.
Une chose à vérifier avec la permission refusée que j'ai récemment trouvé d'avoir des problèmes avec rsync moi-même où les autorisations sont exactement les mêmes sur les deux serveurs, y compris le propriétaire et le groupe mais rsync transferts travaillé d'une façon sur un serveur, mais pas dans l'autre sens.
Il s'est avéré que le serveur avec les problèmes que je recevais de refus d'autorisation de avait SELinux activé qui à son tour remplace POSIX autorisations sur les fichiers/dossiers. Ainsi, même si le dossier en question aurait pu être 777 avec la racine en cours d'exécution, la commande SELinux est activé et serait à son tour remplacer ces autorisations, qui a produit une "permission denied"-erreur de rsync.
Vous pouvez exécuter la commande
getenforce
pour voir si SELinux est activé sur la machine.Dans ma situation, j'ai juste désactiver SELINUX complètement parce qu'il n'était pas nécessaire et déjà désactivé sur le serveur qui fonctionnait bien, et causé des problèmes pour être activé. Pour désactiver, ouvrez
/etc/selinux/config
et définirSELINUX=disabled
. Pour désactiver temporairement vous pouvez exécuter la commandesetenforce 0
qui donnera de SELinux dans unpermissive
de l'état, plutôt que deenforcing
état qui provoque l'impression des mises en garde au lieu de les faire respecter.Démon Rsync utilise par défaut la personne/nogroup pour tous les modules, si elle est en cours d'exécution en vertu de l'utilisateur root. Donc, vous devez définir les paramètres
uid
etgid
à l'utilisateur que vous souhaitez, ou régler à la racine de/root.failed to set times on "/." (in linuxbackup): Operation not permitted (1)
même si la distance démon était déjà en cours d'exécution en tant que root. Changeruid
etgid
àroot
dansrsyncd.conf
fixe queJ'ai rencontré le même problème et résolu par
chown
l'utilisateur du dossier de destination. L'utilisateur actuel n'a pas la permission de lire, écrire et exécuter le dossier de destination des fichiers. Essayez d'ajouter la permission parchmod a+rwx <folder/file name>
.J'ai eu un problème similaire, mais dans mon cas, c'était parce que le stockage a seulement SFTP, sans ssh ou rsync démons sur elle. Je ne pouvais rien changer, bcs ce serveur a été fourni par mon client.
rsync ne pouvait pas changer la date et l'heure du fichier, certains autres utilitaires (comme csync) m'a montré d'autres erreurs: "Impossible de créer le fichier temporaire Clock skew détecté".
Si vous avez accès au stockage-server - il suffit d'installer openssh-server ou de lancer rsync comme un démon ici.
Dans mon cas - je ne pouvais pas faire cela et la solution a été: lftp.
lftp est l'utilisation pour la synchronisation est ci-dessous:
/src/dossier est le dossier sur mon PC, /rem/dossier - est sftp://sft.domaine.tld/rem/dossier.
vous pouvez trouver mans par le lien lftp.yar.ru/lftp-man.html
Cela pourrait ne pas convenir à tout le monde car il ne permet pas de conserver le fichier d'origine autorisations, mais dans mon cas ce n'était pas important et il a résolu le problème pour moi. rsync est une option
--chmod
:Cela oblige les autorisations d'être ce que vous voulez sur tous les fichiers/répertoires. Par exemple:
serait ajouter en Lecture, Écriture et Exécution pour l'utilisateur à tous transférés répertoires.
--rsync-path=/bin/rsync
de rsync pour se débarrasser de la "permission refusée".Windows: Vérifiez les autorisations de dossiers de destination. Prendre possession si vous devez donner les droits pour le compte qui exécute le service rsync.
J'imagine une erreur courante actuellement pas mentionné ci-dessus est d'essayer d'écrire dans un espace de montage (par exemple,
/media/drivename
) lorsque la partition n'est pas montée. Qui produit cette erreur ainsi.Si c'est un disque crypté réglé sur auto, montage, mais qui ne fonctionne pas, peut être un problème de l'auto-déverrouillage de la partition chiffrée avant de tenter d'écrire à l'espace où il est censé être monté.
J'ai eu le même message d'erreur lors de la synchronisation des fichiers à l'intérieur d'un conteneur Docker et la destination était un volume monté (menu fixe pour mac), je lance
rsync
viasu-exec <user>
. J'ai été en mesure de résoudre le problème en exécutantrsync
commeroot
avec-og
drapeaux (garder le propriétaire et le groupe de fichiers de destination).Je ne sais pas encore ce qui a causé ce problème, la destination des autorisations ont été OK (j'ai exécuter
chown -R <user>
pour le dossier de destination avant dersync
), peut-être en quelque sorte lié à Docker pour Mac lente du système de fichiers.J'ai eu le même problème en cas de CentOS 7. Je suis allé à travers des articles ,des forums, mais ne pourrais pas trouver la solution.
Le problème était avec SElinux. Désactiver SElinux à la fin du serveur travaillé.
Vérifier SELinux statut à la fin du serveur (à partir d'où vous tirez des données à l'aide rysnc)
Commandes pour vérifier SELinux statut et de la désactiver
$getenforce
L'application ## cela signifie que SElinux est activé
$setenforce 0
$getenforce
Permissive
Maintenant, essayez d'exécuter la commande rsync sur le client final ,il a travaillé pour moi.
Tout le meilleur!
Faire attention sur le -e ssh et jenkins@localhost: dans l'exemple suivant:
Qui m'a aidé à
P. S. aujourd'Hui, j'ai réalisé que lorsque vous modifier (ajouter) jenkins utilisateur à un groupe, la permission de s'appliquer après esclave (agent) redémarrer. Et ma solution (-e ssh et jenkins@localhost:) doivent uniquement lorsque vous ne pouvez pas redémarrer l'agent/serveur.
exécuter dans un accès root ssh aurez à résoudre ce problème
ou
chmod 0777 /dir/to/be/backedup/
ou
chown username:user /dir/to/be/backedup/