Erreur rsync: échec de la définition des heures sur «/ foo / bar»: opération non autorisée

202

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
source

non, juste un répertoire normal pour autant que je sache.

— dreeves

Je viens de rencontrer un problème similaire, même si mon code d'erreur était 22: rsync: n'a pas réussi à définir les heures sur ... Argument non valide (22). Après quelques vérifications, il s'avère que mes fichiers étaient datés de la dernière modification en 1956! Solution: touchez tous les fichiers, problème résolu. :) "trouver. -print0 | xargs -0 touch"

— KIAaze

Je trouve que si vous avez également configuré un travail cron vers la même destination, cette erreur apparaîtra. Changer l'heure du travail cron (crontab) aidera à le contourner. Dans mon cas, je n'obtiens cette erreur que si je fais un rysnc manuel si j'ai également configuré un travail cron.

— NelsonGon

296

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.

— Jon Bright
source

8

Le plus drôle, c'est que je synchronise ext3 avec ext3, les deux systèmes d'exploitation sont Linux. Je n'ai jamais eu à utiliser ce commutateur auparavant. -O a fait l'affaire, mais j'aurais aimé ne pas avoir à l'utiliser.

— d -_- b

3

Merci! Il s'avère que certains hôtes VPS (par exemple xlshosting.nl) l'utilisent en interne, ce qui peut poser des problèmes avec rsync.

— Frederik

2

J'ai le même problème de synchronisation de Linux ext4 vers Linux ext4: un "impossible de définir des heures: opération non autorisée" pour les liens symboliques , pas les répertoires. -On'aide pas, évidemment. Cela ne se produisait pas lorsque ma partition de sauvegarde était ext3 au lieu de ext4.

— Marius Gedminas

10

J'utilisais rsync -avc, et l'ajout de -O n'aidait pas. J'ai alors lu que -a était l'équivalent de -rlptgoD qui inclut -t qui, je suppose, remplace -O. Donc, pour moi, le correctif était d'utiliser -rlpgoDvc

— dlink

3

@dlink, vous pouvez ajouter --no-tpour supprimer l'option implicite.

— Noam Nelke

87

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.

— Anddam
source

10

Idem sous Linux (Debian Squeeze dans mon cas) ... Si je ne suis pas le propriétaire du répertoire cible, rsync donne le message d'erreur "Fail to set times". (Avoir une autorisation d'écriture sur le répertoire ne suffit pas.)

— ddekany

1

Je suis piégé dans le même problème. Jusqu'à monter NTFS avec uid = user.

— gavenkoa

3

Cette erreur a disparu pour moi lorsque j'ai changé le propriétaire du répertoire que j'essayais d'affecter (sur le serveur distant) à l'aide de la commande rsync au même utilisateur que celui qui essayait de se connecter via rsync sur mon script Bash local. En d'autres termes: j'essayais d'écrire /remote/path/to/foo/barsur le serveur distant avec cette commande: rsync -avzP --exclude '.DS_Store' /local/path/to/foo/bar/ user1@1.2.3.4:/remote/path/to/foo/bar et 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/bar

— racl101

2

Si vous partagez vos fichiers avec d'autres utilisateurs dans un groupe, par exemple vous utilisez le sticky bit, changer de propriétaire n'est pas vraiment la solution. Nous n'utilisons pas -t et ajoutons -O pour éviter cet avertissement.

— R. van Twisk le

1

Pouvez-vous développer la réponse pour préciser si un utilisateur fait partie d'un groupe qui possède le fichier / répertoire si cela devrait OU ne devrait pas fonctionner?

— Elijah Lynn

5

Comme @ 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.

chown -R userCorrect /remote/path/to/foo/bar

— Lud Akell
source

3

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.

— ripah
source

2

J'ai eu le même problème. Pour moi, la solution est de supprimer le fichier distant et de laisser rsynccréer à nouveau.

— shintaroïde
source

0

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?

— David Wolever
source

Je suis sur un mac, rsynchronisé sous Linux (une machine slicehost).

— dreeves

Ah, étrange ... Puisque vous utilisez rsync sur le mac, cependant, je dois vous avertir: il ne préserve pas correctement tous les attributs de fichier OS X, donc de mauvaises choses peuvent arriver. Voir, par exemple: blog.plasticsfuture.org/2006/04/23/mac-backup-software-harmful

— David Wolever

Vous pouvez cependant utiliser la version la plus récente de MacPorts ( sudo port install rsync) et elle cassera moins. Pour le vérifier rsync --version:: rsync version 3.0.5 protocole version 30 ... append, ACL, xattrs, iconv, symtimes, file-flags ... (ACL et xattrs sont les plus importants)

— David Wolever

1

rsync sur Macintosh définit en effet tous les attributs de fichier et le fait depuis un certain temps, veuillez noter que l'URL référençant «de mauvaises choses pourrait arriver» est datée de 2006!

— tgunr le

2

Les réponses ne devraient vraiment pas inclure de questions. Ce serait plus approprié comme commentaire.

— Brian

0

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.

— capitaine
source

0

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é manuellement sudo chown -R otheruser.group directoryet sudo 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?

— Sam Brightman
source

La page de manuel indique l'UID de l'application. doit correspondre à l'UID du fichier pour 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".

— Alexis Wilke le

Pouvez-vous créer un lien vers une telle page de manuel? Aucune de mes paroles utime().

— Sam Brightman le

1

linux.die.net/man/2/utime Le paragraphe pertinent: "La modification des horodatages est autorisée lorsque: soit le processus a les privilèges appropriés, soit l'ID utilisateur effectif est égal à l'ID utilisateur du fichier, soit les heures sont NULL et le processus a autorisation d'écriture pour le fichier. "

— Alexis Wilke le

0

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.

— Gurdeep Singh
source