Je reçois une erreur déroutante de rsync et les premières choses que je trouve dans les recherches Web (ainsi que tous les chmod'ing habituels) ne le résolvent pas:
rsync: failed to set times on "/foo/bar": Operation not permitted (1)
rsync error: some files could not be transferred (code 23)
at /SourceCache/rsync/rsync-35.2/rsync/main.c(992) [sender=2.6.9]
Cela semble fonctionner malgré cette erreur, mais ce serait bien de s'en débarrasser.
rsync
file-transfer
dreeves
la source
la source
Réponses:
Si
/foo/barest sur NFS (ou éventuellement sur un système de fichiers FUSE), cela peut être le problème.Dans tous les cas, l'ajout de
-O/--omit-dir-timesà votre ligne de commande lui évitera d'essayer de définir des heures de modification sur les répertoires.la source
-On'aide pas, évidemment. Cela ne se produisait pas lorsque ma partition de sauvegarde était ext3 au lieu de ext4.--no-tpour supprimer l'option implicite.Le problème est probablement dû au fait que / foo / bar n'appartient pas au processus d'écriture sur un système distant Darwin (OS X). Une solution au problème consiste à définir un propriétaire adéquat sur le site distant.
Étant donné que cette réponse a été votée et qu'elle a donc été, espérons-le, utile à quelqu'un, je la prolonge pour la rendre plus claire.
La raison pour laquelle cela se produit est que rsync essaie probablement de définir une heure de modification arbitraire (mtime) lors de la copie de fichiers.
Pour ce faire, la
utime()fonction système de Darwin nécessite que l'uid effectif du processus d'écriture soit le même que l'uid du fichier ou celui du super utilisateur, voir la page opengroup utime . Consultez cette discussion sur la liste de diffusion rsync comme référence.la source
/remote/path/to/foo/barsur le serveur distant avec cette commande:rsync -avzP --exclude '.DS_Store' /local/path/to/foo/bar/ [email protected]:/remote/path/to/foo/baret j'ai eu les mêmes messages d'erreur que ceux qui ont disparu lorsque j'ai crééuser1le propriétaire de/remoe/path/to/foo/barcomme ceci:$ chown -R user1 /remote/path/to/foo/barComme @ racl101 a commenté une réponse, ce problème peut être lié au propriétaire du dossier . La commande rsync doit être effectuée par le même utilisateur que celui du propriétaire du dossier. Si ce n'est pas la même chose, vous pouvez le changer.
la source
Le problème dans mon cas était que le "point de montage du récepteur" était mal monté. C'était en mode lecture seule (pour une raison extrange). Il semblait que rsync copiait les fichiers, mais ce n'était pas le cas. J'ai vérifié mon fichier fstab et changé les options de montage par défaut, remonter le système de fichiers et exécuter à nouveau rsync. Tout va bien alors.
la source
J'ai eu le même problème. Pour moi, la solution est de supprimer le fichier distant et de laisser
rsynccréer à nouveau.la source
J'ai vu ce problème lorsque j'écris sur un système de fichiers qui ne gère pas (correctement) les temps - je pense que les partages SMB ou FAT ou quelque chose comme ça.
Quel est votre système de fichiers cible?
la source
sudo port install rsync) et elle cassera moins. Pour le vérifierrsync --version:: rsync version 3.0.5 protocole version 30 ... append, ACL, xattrs, iconv, symtimes, file-flags ... (ACL et xattrs sont les plus importants)Il se peut que vous n'ayez pas de privilèges sur certains fichiers. À partir d'un compte administrateur, essayez "sudo rsync -av" Sinon, activez le compte root et connectez-vous en tant que root. Cela devrait vous permettre de durcir complètement votre système et de forcer brutalement votre rsync! ;-) Je ne suis pas sûr que les attributs --extended mentionnés ci-dessus vous aideront, mais je l'ai ajouté aussi, juste pour faire bonne mesure.
la source
Cela m'est arrivé sur une partition de type
xfs (rw,relatime,seclabel,attr2,inode64,noquota), où les répertoires appartenaient à un autre utilisateur dans un groupe dont nous étions tous les deux membres. L'appartenance au groupe était déjà établie avant la connexion et l'ensemble de la structure du répertoire était accessible en écriture au groupe. J'avais exécuté manuellementsudo chown -R otheruser.group directoryetsudo chmod -R g+rw directorypour confirmer cela.Je n'ai toujours aucune idée de la raison pour laquelle cela n'a pas fonctionné à l'origine, mais je me suis approprié le
sudo chown -R myuser.group directoryproblème. Peut-être lié à SELinux?la source
utime()fonctionner. Vous pouvez également exécuter en tant que root et le faire. Mais si l'UID du fichier est différent, ils ne vous permettent pas de changer l'heure en autre chose que "maintenant".utime().Cette erreur peut également apparaître si vous exécutez le processus rsync pour les fichiers qui n'ont pas été récemment modifiés dans la source ou la destination ... car il ne peut pas définir l'heure des fichiers récemment modifiés.
la source