Error de rsync: error al establecer tiempos en “/ foo / bar”: operación no permitida


194

Recibo un error confuso de rsync y las cosas iniciales que encuentro de las búsquedas web (así como todos los cambios habituales) no lo resuelven:

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]

Parece estar funcionando a pesar de ese error, pero sería bueno deshacerse de eso.


no, solo un directorio normal por lo que puedo decir.
Dreeves

Acabo de encontrar un problema similar, aunque mi código de error fue 22: rsync: no se pudo establecer la hora en ... Argumento no válido (22). ¡Después de algunas comprobaciones resulta que mis archivos estaban fechados como modificados por última vez en 1956! Solución: toque todos los archivos, problema resuelto. :) "find. -print0 | xargs -0 touch"
KIAaze

Me parece que si también ha configurado un trabajo cron en el mismo destino, este error aparecerá. Cambiar la hora del trabajo cron (crontab) ayudará a solucionarlo. En mi caso, solo recibo este error si hago una sincronización manual si también configuré un trabajo cron.
NelsonGon

Respuestas:


286

Si /foo/barestá en NFS (o posiblemente en algún sistema de archivos FUSE), ese podría ser el problema.

De cualquier manera, agregar -O/ --omit-dir-timesa su línea de comando evitará que intente establecer tiempos de modificación en los directorios.


8
Lo curioso es que estoy sincronizando ext3 a ext3, ambos sistemas operativos son linux. Nunca he tenido que usar este interruptor antes. -O hice el truco, pero desearía no tener que usarlo.
d -_- b

3
¡Gracias! Resulta que algunos hosts VPS (por ejemplo, xlshosting.nl) lo usan internamente, lo que puede generar problemas con rsync.
Frederik

2
Tengo el mismo problema al sincronizar Linux ext4 con Linux ext4: un "no se pueden establecer tiempos: operación no permitida" para enlaces simbólicos , no directorios. -Ono ayuda, obviamente. Esto no solía ocurrir cuando mi partición de respaldo era ext3 en lugar de ext4.
Marius Gedminas

10
Estaba usando rsync -avc, y agregar -O no estaba ayudando. Luego leí que -a era el equivalente a -rlptgoD que incluye -t, que supongo que está anulando -O. Entonces, para mí, la solución fue usar -rlpgoDvc
dlink

3
@dlink que puede agregar --no-tpara eliminar la opción implícita.
Noam Nelke

86

El problema probablemente se deba a que / foo / bar no es propiedad del proceso de escritura en un sistema remoto darwin (OS X). Una solución al problema es establecer un propietario adecuado en el sitio remoto.

Como esta respuesta ha sido votada y, por lo tanto, ha sido útil para alguien, la extiendo para que quede más clara.

La razón por la que esto sucede es que rsync probablemente está tratando de establecer un tiempo de modificación arbitrario (mtime) al copiar archivos.

Para hacer esto, la utime()función del sistema de Darwin requiere que el uid efectivo del proceso de escritura sea el mismo que el uid del archivo o el del superusuario, consulte la página de opengroup utime . Verifique esta discusión en la lista de correo rsync como referencia.


10
Lo mismo en Linux (Debian Squeeze en mi caso) ... Si no soy el propietario del directorio de destino, rsync muestra el mensaje de error "error al establecer tiempos". (Tener permiso de escritura en el directorio no es suficiente.)
ddekany

1
Atrapado en el mismo problema. Hasta montar NTFS con uid = user.
gavenkoa

3
Este error desapareció cuando cambié el propietario del directorio que estaba tratando de afectar (en el servidor remoto) usando el comando rsync para el mismo usuario que el que intentaba iniciar sesión a través de rsync en mi script Bash local. En otras palabras: estaba tratando de escribir /remote/path/to/foo/baren el servidor remoto con este comando: rsync -avzP --exclude '.DS_Store' /local/path/to/foo/bar/ user1@1.2.3.4:/remote/path/to/foo/bar recibí los mismos mensajes de error que desaparecieron cuando hice user1al propietario de /remoe/path/to/foo/baresta manera:$ chown -R user1 /remote/path/to/foo/bar
racl101

1
Si comparte sus archivos con otros usuarios en un grupo, por ejemplo, usa el bit adhesivo, cambiar de propietario no es realmente la solución. No usamos -t ni agregamos -O para evitar esta advertencia.
R. van Twisk

1
¿Puede ampliar la respuesta para explicar si un usuario es parte de un grupo que posee el archivo / directorio si eso debería O no debería funcionar?
Elijah Lynn el

4

Como @ racl101 ha comentado una respuesta, este problema podría estar relacionado con el propietario de la carpeta . El comando rsync debe ser realizado por el mismo usuario que el del propietario de la carpeta. Si no es lo mismo, puede cambiarlo.

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

2

El problema en mi caso fue que el "punto de montaje del receptor" estaba montado incorrectamente. Estaba en modo de solo lectura (por alguna extraña razón). Parecía que rsync estaba copiando los archivos, pero no fue así. Revisé mi archivo fstab y cambié las opciones de montaje a las predeterminadas, volví a montar el sistema de archivos y ejecuté rsync nuevamente. Todo bien entonces.


2

Yo tuve el mismo problema. Para mí, la solución es eliminar el archivo remoto y dejar de rsynccrear nuevamente.


0

He visto ese problema cuando escribo en un sistema de archivos que no maneja (correctamente) los tiempos: creo que SMB comparte o FAT o algo así.

¿Cuál es su sistema de archivos de destino?


Estoy en una Mac, rsync'ing a Linux (una máquina de servidor de corte).
Dreeves

Ah, extraño ... Sin embargo, dado que está utilizando rsync en la Mac, debo advertirle: no conserva correctamente todos los atributos del archivo OS X, por lo que podrían suceder cosas malas. Ver, por ejemplo: blog.plasticsfuture.org/2006/04/23/mac-backup-software-harmful
David Wolever

Sin embargo, puede usar la versión más reciente de MacPorts ( sudo port install rsync) y se romperá menos. Para verificarlo rsync --version: rsync versión 3.0.5, protocolo versión 30 ... agregar, ACL, xattrs, iconv, symtimes, archivos-flags ... (ACL y xattrs son los más importantes)
David Wolever

1
rsync en Macintosh establece todos los atributos de los archivos y lo ha hecho durante bastante tiempo, tenga en cuenta que la URL que hace referencia a "Cosas malas podrían suceder" está fechada en 2006.
tgunr

2
Las respuestas realmente no deberían incluir preguntas. Esto sería más apropiado como comentario.
Brian

0

Puede ser que no tenga privilegios para algunos de los archivos. Desde una cuenta de administrador, intente "sudo rsync -av" Alternativamente, habilite la cuenta raíz e inicie sesión como root. ¡Eso debería permitirle controlar completamente su sistema y forzar su rsync por fuerza bruta! ;-) No estoy seguro de si los atributos --extendidos-mencionados anteriormente ayudarán, pero también lo incluí, solo por si acaso.


0

Esto me sucedió en una partición de tipo xfs (rw,relatime,seclabel,attr2,inode64,noquota), donde los directorios pertenecían a otro usuario en un grupo del que ambos éramos miembros. La pertenencia al grupo ya se había establecido antes del inicio de sesión, y toda la estructura del directorio se podía escribir en grupo. Había corrido manualmente sudo chown -R otheruser.group directoryysudo chmod -R g+rw directory para confirmar esto.

Todavía no tengo idea de por qué no funcionó originalmente, pero tomar posesión de sudo chown -R myuser.group directory solucionó. ¿Quizás relacionado con SELinux?


La página de manual dice el UID de la aplicación. tiene que coincidir con el UID del archivo para utime()que funcione. También puede ejecutar como root y hacerlo. Pero si el UID del archivo es diferente, no le permiten cambiar la hora a otra cosa que "ahora".
Alexis Wilke

¿Puedes vincular a esa página de manual? Ninguno de los míos menciona utime().
Sam Brightman

1
linux.die.net/man/2/utime El párrafo pertinente: "Se permite cambiar las marcas de tiempo cuando: o el proceso tiene los privilegios apropiados, o la ID de usuario efectiva es igual a la ID de usuario del archivo, o el tiempo es NULL y el proceso tiene escribir permiso para el archivo ".
Alexis Wilke

0

Este error también puede aparecer si ejecuta el proceso rsync para archivos que no se han modificado recientemente en el origen o el destino ... porque no puede establecer la hora de los archivos modificados recientemente.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.