web-dev-qa-db-pt.com

rsync - mkstemp falhou: Permissão Negada (13)

Eu tenho a seguinte configuração para periodicamente arquivos rsync do servidor A para o servidor B. O servidor B tem o daemon rsync em execução com a seguinte configuração:

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

Do servidor A, estou emitindo o seguinte comando:

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

O diretório BACKUP é totalmente lido/gravado/executado para todos. Quando executo o comando rsync do servidor A, vejo:

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

para cada e todo arquivo no diretório que eu desejo fazer backup. Ele falha quando eu começo a escrever arquivos tmp:

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

Horas de googling mais tarde e ainda não consigo resolver o que parece ser um problema de permissão muito simples. Conselhos? Desde já, obrigado.

Informação adicional

Eu só notei o seguinte ocorre no início do processo:

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

Está tentando definir permissão em "/"?

Editar

Eu estou logado como o usuário - someuser. Meu diretório de destino tem permissão completa de leitura/gravação/execução para todos, incluindo seu conteúdo. Além disso, o diretório de destino é de propriedade de algum usuário e do grupo de usuários.

Acompanhamento

Eu encontrei usando o SSH resolve isso

41
user320487

Certifique-se de que o usuário em que você está sendo rsync'd na máquina remota tenha acesso de gravação ao conteúdo da pasta E da própria pasta, pois o rsync tentou atualizar a hora da modificação na própria pasta.

13
Mauvis Ledford

Mesmo que você tenha conseguido esse trabalho, recentemente tive um encontro semelhante e não SO ou a pesquisa do Google foi de alguma ajuda, pois todos eles lidaram com problemas básicos de permissão em que a solução abaixo é um pouco pense em verificar a maioria das situações.

Uma coisa para verificar com permissão negada que eu encontrei recentemente tendo problemas com rsync-me onde as permissões eram exatamente os mesmos em ambos os servidores, incluindo o proprietário e grupo, mas as transferências rsync funcionou de uma maneira em um servidor, mas não o contrário.

Descobri que o servidor com problemas dos quais eu estava recebendo permissão negada tinha o SELinux ativado, o que, por sua vez, substitui as permissões POSIX em arquivos/pastas. Assim, mesmo que a pasta em questão pudesse ter sido 777 com raiz em execução, o comando SELinux foi habilitado e, por sua vez, sobrescreveria aquelas permissões que produziam um erro de "permissão negada" do rsync.

Você pode executar o comando getenforce para ver se o SELinux está habilitado na máquina.

Na minha situação eu acabei desabilitando o SELINUX completamente porque não era necessário e já estava desabilitado no servidor que estava funcionando bem e apenas causava problemas ao ser habilitado. Para desativar, abra /etc/selinux/config e defina SELINUX=disabled. Para desabilitar temporariamente, você pode executar o comando setenforce 0, que definirá o SELinux em um estado permissive, em vez de enforcing, o que faz com que ele imprima avisos em vez de reforçar.

13
Jeff Wilbert

O daemon do Rsync, por padrão, usa nobody/nogroup para todos os módulos se estiver executando sob o usuário root. Então você precisa definir params uid e gid para o usuário que você quer, ou configurá-los para root/root.

8
Marki555

Eu encontrei o mesmo problema e resolvi por chown o usuário da pasta de destino. O usuário atual não tem permissão para ler, gravar e executar os arquivos da pasta de destino. Tente adicionar a permissão por chmod a+rwx <folder/file name>.

6
hao

Isso pode não servir a todos, uma vez que não preserva as permissões do arquivo original, mas no meu caso não era importante e resolveu o problema para mim. O rsync tem uma opção --chmod:

- chmod Esta opção diz ao rsync para aplicar uma ou mais cadeias lqchmodrq separadas por vírgula à permissão dos arquivos na transferência. O valor resultante É tratado como se fossem as permissões que o lado de envio Forneceu para o arquivo, o que significa que essa opção pode Parecer não ter efeito nos arquivos existentes se --perms não está habilitado.

Isso força as permissões a serem o que você deseja em todos os arquivos/diretórios. Por exemplo:

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

adicionaria Ler, Escrever e Executar para o usuário a todos os diretórios transferidos.

3
Zitrax

Eu tive um problema semelhante, mas no meu caso foi porque o armazenamento tem apenas SFTP, sem daemons ssh ou rsync nele. Eu não poderia mudar nada, bcs este servidor foi fornecido pelo meu cliente.

rsync não pode alterar a data e hora para o arquivo, alguns outros utilitários (como csync) mostrou-me outros erros: "Não é possível criar arquivo temporário Clock skew detectado". Se você tiver acesso ao servidor de armazenamento - basta instalar o openssh-server ou iniciar o rsync como um daemon aqui.

No meu caso - eu não consegui fazer isso e a solução foi: lftp . O uso do lftp para sincronização está abaixo:

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

/ src/folder - é a pasta no meu PC, a pasta/rem/- é sftp: //sft.domain.tld/rem/folder.

você pode encontrar mans pelo link lftp.yar.ru/lftp-man.html

3
bolD

Windows: verifique as permissões das pastas de destino. Assuma a propriedade se você precisar dar direitos à conta que está executando o serviço rsync.

1
Shield Edge Technologies

Imagino que um erro comum não mencionado acima esteja tentando gravar em um espaço de montagem (por exemplo, /media/drivename) quando a partição não está montada. Isso produzirá esse erro também. 

Se for uma unidade criptografada configurada para montagem automática, mas não, pode ser um problema de desbloqueio automático da partição criptografada antes de tentar gravar no espaço em que ela deve ser montada.

0
Wolf

Eu tive o mesmo erro ao sincronizar arquivos dentro de um contêiner Docker e o destino era um volume montado (Docker para mac), eu corro rsync via su-exec <user>. Consegui resolvê-lo executando rsync como root com -og flags (mantenha o proprietário e o grupo para os arquivos de destino).

Eu ainda não sei o que causou esse problema, as permissões de destino foram OK (eu corro chown -R <user> para destino dir antes rsync), talvez de alguma forma relacionado ao Docker para Mac sistema de arquivos lento.

0
chingis