linux - rsync-mkstemp falló: permiso denegado(13)

rsync preserve all attributes

Question

Tengo la siguiente configuración para rsync periódicamente los archivos desde el servidor A al servidor B. El servidor B tiene el demonio rsync ejecutándose con la siguiente configuración:

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

Desde el servidor AI estoy emitiendo el siguiente comando:

rsync -adzPvO --delete --password-file=/path/to/pwd/file/pwd.dat /dir/to/be/backedup/ [email protected]::BACKUP

El directorio de BACKUP es completamente de lectura / escritura / ejecución para todos. Cuando ejecuto el comando rsync desde el servidor A, veo:

afile.txt
         989 100%    2.60kB/s    0:00:00 (xfer#78, to-check=0/79)

para todos y cada uno de los archivos en el directorio deseo hacer una copia de seguridad. Falla cuando llego a escribir archivos tmp:

rsync: mkstemp "/.afile.txt.PZQvTe" (in BACKUP) failed: Permission denied (13)

Horas de googlear más tarde y todavía no puedo resolver lo que parece ser un problema de permiso muy simple. ¿Consejo? Gracias por adelantado.

Información Adicional

Acabo de notar que ocurre lo siguiente al comienzo del proceso:

rsync: failed to set permissions on "/." (in BACKUP): Permission denied (13)

¿Está tratando de establecer el permiso en "/"?

Editar

Estoy conectado como el usuario - someuser. Mi directorio de destino tiene permiso completo de lectura / escritura / ejecución para todos, incluido su contenido. Además, el directorio de destino es propiedad de algún usuario y está en el grupo de alguien que lo envía.

Seguir

He encontrado usando SSH resuelve esto

Answer 1

A pesar de que funcionó, recientemente tuve un encuentro similar y ninguna búsqueda de SO o Google fue de alguna ayuda, ya que todos ellos se ocuparon de problemas de permisos básicos. La solución que se encuentra a continuación es un poco una configuración que ni siquiera pensaría revisar. en la mayoría de las situaciones

Una cosa para verificar con permiso fue que recientemente encontré problemas con rsync, donde los permisos eran exactamente iguales en ambos servidores, incluidos el propietario y el grupo, pero las transferencias de rsync funcionaban de una manera en un servidor pero no de la otra.

Resultó que el servidor con problemas de los que estaba obteniendo permiso denegado tenía SELinux habilitado, lo que a su vez anula los permisos POSIX de los archivos / carpetas. Entonces, aunque la carpeta en cuestión podría haber sido 777 con la raíz ejecutándose, el comando SELinux estaba habilitado y, a su vez, sobrescribía los permisos que producían un error de "permiso denegado" de rsync.

Puede ejecutar el comando getenforce para ver si SELinux está habilitado en la máquina.

En mi situación terminé simplemente deshabilitando SELINUX completamente porque no era necesario y ya estaba deshabilitado en el servidor que estaba funcionando bien y solo causó problemas para habilitarlo. Para deshabilitar, abra /etc/selinux/config y establezca SELINUX=disabled . Para deshabilitarlo temporalmente, puede ejecutar el comando setenforce 0 que establecerá SELinux en un estado permissive lugar de enforcing estado que hace que se impriman advertencias en lugar de aplicarlas.

Answer 2

Asegúrese de que el usuario al que está sincronizando en la máquina remota tenga acceso de escritura al contenido de la carpeta Y a la carpeta en sí, ya que rsync intentó actualizar la hora de modificación en la misma carpeta.

Answer 3

El daemon Rsync de forma predeterminada no utiliza nobody / nogroup para todos los módulos si se está ejecutando bajo un usuario root. Por lo tanto, debe definir los parámetros uid y gid para el usuario que desee, o establecerlos en root / root.

Answer 4

Encontré el mismo problema y lo resolví chown el usuario de la carpeta de destino. El usuario actual no tiene permiso para leer, escribir y ejecutar los archivos de la carpeta de destino. Intente agregar el permiso mediante chmod a+rwx <folder/file name> .

Answer 5

Esto podría no ser adecuado para todos, ya que no conserva los permisos del archivo original, pero en mi caso no fue importante y resolvió el problema por mí. rsync tiene una opción --chmod :

--chmod Esta opción le dice a rsync que aplique una o más cadenas lqchmodrq separadas por comas al permiso de los archivos en la transferencia. El valor resultante se trata como si fueran los permisos que el lado de envío proporcionó para el archivo, lo que significa que esta opción puede parecer que no tiene efecto en los archivos existentes si --perms no está habilitado.

Esto obliga a que los permisos sean lo que usted desea en todos los archivos / directorios. Por ejemplo:

rsync -av --chmod=Du+rwx SRC DST

agregaría lectura, escritura y ejecución para el usuario a todos los directorios transferidos.

Answer 6

Me imagino que un error común que no se menciona anteriormente al intentar escribir en un espacio de montaje (por ejemplo, /media/drivename ) cuando la partición no está montada. Eso producirá este error también.

Si se trata de una unidad cifrada configurada para que se monte automáticamente, pero no lo hace, podría tratarse de un desbloqueo automático de la partición cifrada antes de intentar escribir en el espacio donde se supone que se debe montar.

Answer 7

Tuve el mismo error al sincronizar archivos dentro de un contenedor Docker y el destino era un volumen montado (Docker para mac), ejecuto rsync través de su-exec <user> . Pude resolverlo ejecutando rsync como root con indicadores -og (mantener propietario y grupo para los archivos de destino).

Todavía no estoy seguro de qué causó ese problema, los permisos de destino estaban bien ( chown -R <user> para el directorio de destino antes de rsync ), quizás de alguna manera relacionado con el sistema de archivos lento Docker para Mac.

Answer 8

Tuve un problema similar, pero en mi caso fue porque el almacenamiento solo tiene SFTP, sin ssh o rsync daemons. No pude cambiar nada, porque este servidor fue proporcionado por mi cliente.

rsync no pudo cambiar la fecha y la hora del archivo, algunas otras aplicaciones (como csync) me mostraron otros errores: "No se puede crear el archivo temporal Se ha detectado una desviación del reloj". Si tiene acceso al servidor de almacenamiento, simplemente instale openssh-server o inicie rsync como un demonio aquí.

En mi caso, no pude hacer esto y la solución fue: lftp . El uso de lftp para la sincronización es a continuación:

lftp -c "open -u login,password sftp://sft.domain.tld/; mirror -c --verbose=9 -e -R -L /srs/folder /rem/folder"

/ src / folder - es la carpeta en mi PC, / rem / folder - es sftp: //sft.domain.tld/rem/folder.

puede encontrar mans por el enlace lftp.yar.ru/lftp-man.html

Answer 9

Windows: Compruebe los permisos de las carpetas de destino. Tomar posesión si debe otorgar derechos a la cuenta que ejecuta el servicio rsync.

Answer 10

ejecutar en el acceso root ssh chould resolver este problema

o chmod 0777 /dir/to/be/backedup/

o chown username:user /dir/to/be/backedup/