rsync - mkstemp fallito: Permesso negato (13)

Question

Ho la seguente configurazione per i file periodicamente rsync dal server A al server B. Server B ha il demone rsync in esecuzione con la seguente configurazione:

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 

Dal server AI sto emettendo il seguente comando:

rsync -adzPvO --delete --password-file=/path/to/pwd/file/pwd.dat /dir/to/be/backedup/ someuser@192.168.100.100::BACKUP 

La directory BACKUP è completamente in lettura/scrittura/esecuzione per tutti. Quando eseguo il comando rsync dal server A, vedo:

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

per ciascuno e everyfile nella directory desidero backup. Viene a mancare quando arrivo a scrittura di file TMP:

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

Ore di googling più tardi e ancora non riesco a risolvere quello che sembra essere un semplice problema di autorizzazione. Consigli? Grazie in anticipo.

Informazioni aggiuntive

ho appena notato il seguente avviene all'inizio del processo:

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

Sta cercando di impostare l'autorizzazione su "/"?

Modifica

sono entrato come l'utente - someuser. La mia directory di destinazione ha il pieno permesso di lettura/scrittura/esecuzione per tutti, inclusi i suoi contenuti. Inoltre, la directory di destinazione è di proprietà di un utente e nel gruppo di un utente.

Follow-up

ho trovato usando SSH risolve questo

Answer 1

Assicurarsi che l'utente si sta rsync'd in sulla macchina remota ha accesso in scrittura ai contenuti della cartella e la cartella stessa, come rsync ha cercato di aggiornare l'ora di modifica sulla cartella stessa.

Answer 2

Anche se hai funzionato, di recente ho avuto un incontro simile e nessuna ricerca SO o Google è stata di alcun aiuto in quanto tutti riguardavano problemi di autorizzazione di base in cui la soluzione di seguito è un po 'off impostazione che non si anche pensare di controllare nella maggior parte delle situazioni.

Una cosa da verificare con il permesso negato che di recente ho trovato ad avere problemi con rsync me stesso in cui le autorizzazioni erano esattamente gli stessi su entrambi i server, tra cui il proprietario e il gruppo ma i trasferimenti rsync lavorato in un modo su un server, ma non il contrario.

Si è scoperto il server con problemi con i quali ho ricevuto il permesso negato se SELinux era abilitato, il quale a sua volta ha annullato le autorizzazioni POSIX su file/cartelle. Quindi, anche se la cartella in questione poteva essere 777 con root in esecuzione, il comando SELinux era abilitato e, a sua volta, sovrascriveva quelle autorizzazioni che producevano un "permesso negato" - errore da rsync.

È possibile eseguire il comando getenforce per verificare se SELinux è abilitato sulla macchina.

Nella mia situazione ho finito per disabilitare SELINUX completamente perché non era necessario e già disabilitato sul server che stava funzionando bene e solo causato problemi attivati. Per disabilitare, apri /etc/selinux/config e imposta SELINUX=disabled. Per disabilitare temporaneamente è possibile eseguire il comando setenforce 0 che imposterà SELinux in uno stato permissive piuttosto che nello stato enforcing che provoca la stampa di avvisi anziché l'imposizione.

Answer 3

Il daemon Rsync per impostazione predefinita utilizza nessuno/nogroup per tutti i moduli se è in esecuzione con l'utente root. Quindi è necessario definire i parametri uid e gid per l'utente desiderato oppure impostarli su root/root.

Answer 4

Avevo un problema simile, ma nel mio caso era perché lo storage ha solo SFTP, senza i daemon ssh o rsync su di esso. Non ho potuto cambiare nulla, bcs questo server è stato fornito dal mio cliente.

rsync non ha potuto modificare la data e l'ora del file, alcuni altri programmi di utilità (come csync) mi hanno mostrato altri errori: "Impossibile creare il file temporaneo rilevato dall'oscillazione dell'orologio". Se si ha accesso al server di archiviazione - basta installare openssh-server o avviare rsync come demone qui.

Nel mio caso, non ho potuto farlo e la soluzione era: lftp. utilizzo di lftp per sincronizzazione è qui sotto:

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

/src/cartella - è la cartella sul mio PC,/rem/cartella - è sftp: //sft.domain.tld/rem/folder.

si può trovare mans dal collegamento lftp.yar.ru/lftp-man.html

Answer 5

corsa nel accesso root ssh chould risolvere questo problema

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

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

Answer 6

Windows: controlla i permessi delle cartelle di destinazione. Diventa proprietario se devi dare i diritti all'account che esegue il servizio rsync.

Answer 7

Questo potrebbe non essere adatto a tutti dal momento che non conserva le autorizzazioni del file originale ma nel mio caso non era importante e ha risolto il problema per me. rsync ha un'opzione --chmod:

--chmod Questa opzione dice a rsync di applicare una o più stringhe lqchmodrq separate da virgole al permesso dei file nel trasferimento. Il valore risultante viene considerato come se fossero le autorizzazioni che il lato di invio fornito per il file, il che significa che questa opzione può sembra non avere alcun effetto sui file esistenti se --perms non è abilitato.

Ciò impone che le autorizzazioni siano ciò che si desidera su tutti i file/directory. Ad esempio:

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

aggiungere Read, Write ed Execute per l'utente a tutte le directory trasferite.

Answer 8

Immagino che un errore comune non menzionato sopra stia cercando di scrivere su uno spazio di montaggio (ad esempio, /media/drivename) quando la partizione non è montata. Ciò produrrà anche questo errore.

Se si tratta di un'unità crittografata impostata per il montaggio automatico ma non lo fa, potrebbe essere un problema di sblocco automatico della partizione crittografata prima di tentare di scrivere nello spazio in cui deve essere montata.

Answer 9

Ho avuto lo stesso errore durante la sincronizzazione dei file all'interno di un contenitore Docker e la destinazione era un volume montato (Docker per mac), eseguotramite su-exec <user>. Sono stato in grado di risolverlo eseguendo rsync come root con i flag -og (mantenere il proprietario e il gruppo per i file di destinazione).

Non sono ancora sicuro di quale sia stato il problema, i permessi di destinazione erano OK (eseguo chown -R <user> per dir destinazione prima dello rsync), forse in qualche modo collegato al file system lento Docker per Mac.

Answer 10

Incontro anche questo problema e lo risolvo "chown" l'utente del floder di destinazione. Penso che sia ok per chmod a + rwx.