'sudo cp -a' muda a propriedade para root (ao invés de preservar o usuário original)

Question

Eu estava tentando fazer o backup de alguns diretórios e algumas das cópias feitas por sudo cp -av resultaram na propriedade do root, enquanto outras preservaram seus atributos. Isso é um problema conhecido ou estou faltando alguma coisa?

A fonte (ext4) é um antigo disco do sistema ubuntu sendo usado externamente, estrutura de diretórios intacta, mas é usada apenas para armazenamento, não para inicialização. O nome de usuário / groupname e uid / gid é o mesmo que no sistema anterior.

O destino (btrfs) formatado de NTFS, usando o 4.1.2 btrfs-progs.

$ sudo cp -av /mnt/src/home/user/thecakeisalie/ /mnt/dest/subvol/

drwx------ 6 user user 4096 Jul 18 09:11 /mnt/src/home/user/thecakeisalie/
drwx------ 3 root root 4096 Jul 18 20:36 /mnt/dest/subvol/thecakeisalie/

  File: ‘/mnt/src/home/user/thecakeisalie/’
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 812h/2066d  Inode: 9044504     Links: 6
Access: (0700/drwx------)  Uid: ( 1000/user)   Gid: ( 1000/user)
Access: 2015-07-18 20:21:08.725414953 -0700
Modify: 2015-07-18 09:11:06.873427304 -0700
Change: 2015-07-18 20:08:34.161737231 -0700
 Birth: -

  File: ‘/mnt/dest/subvol/thecakeisalie/’
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 805h/2053d  Inode: 660098      Links: 3
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-07-18 20:36:23.909377491 -0700
Modify: 2015-07-18 20:36:09.729089386 -0700
Change: 2015-07-18 20:36:09.729089386 -0700
 Birth: -

O teste de alguns outros diretórios em /mnt/src/home/user/thecakeisalie/ resultou no comportamento esperado com ls -l , stat saídas exatamente correspondentes.

Alguns diretórios 'bem-comportados' foram criados esta tarde, mas eu testei isso em alguns que não foram tocados antes de eu começar a usar o drive externamente e alguns deles estão ok também.

Após o backup, eu chown -ed tudo, então não há problema, mas estou realmente curioso para saber qual poderia ser a causa. Eu pesquisei muito, mas eu não estava usando a frase de pesquisa correta ou isso é bem conhecido.

O mjturner abaixo tinha um ponto, então eu tentei os comandos cp -a no meu ~/Download dir no disco do sistema interno (ext4) e os resultados são os mesmos, portanto não acho que seja um problema do btrfs.

Na semana passada eu consertei um laptop antigo onde as circunstâncias eram similares: para atualizar o Ubuntu 13.10 eu tive que instalar o Ubuntu 15.04 em outra nova partição e após o boot eu fiz sudo cp -a toda a casa do sistema antigo. 13.10 tinha 2 usuários (alfa, bravo) e 15.04 foram configurados com 1 usuário (alfa). As entradas do bravo acabaram mostrando o GID / UID (é claro) enquanto o alpha parecia e funcionava da mesma forma que antes. (Eu tenho que verificar se o GID / UID de alfa antigo e novo, onde o mesmo).

Algumas informações adicionais sobre o sistema atual, uname :
Linux 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:14:22 UTC 2015 i686

Eu vou fazer uma grande limpeza na unidade de origem (me livrar dos diretórios do sistema e mover os diretórios de armazenamento principal para a raiz) e testarei novamente.

Nesse meio tempo, existem outros comandos que eu possa usar para testar a origem e o destino das diferenças? Não importa o quão baixo eu tenha que cavar (eu queria escovar C de qualquer maneira).

    

Answer 1

Percebi que esqueci de mencionar que abortei cp -a depois de verificar o destino em outro terminal, pois estava copiando mais de 300 GB de dados.

Graças ao comentário de Gilles, comecei a testar para ver se isso acontece apenas nos diretórios ou não. Como os testes provam abaixo, basicamente todos os arquivos são escritos como root e os atributos antigos são aplicados ao diretório / arquivo depois de ter sido copiado.

TEST_1: pasta de 3 gb e CTRL-C durante sudo cp -a : o arquivo atual é truncado, deixado como raiz e o diretório também.

home/Download# ls -l
total 20
drwx------ 3 root      root       4096 Jul 19 15:11 ./
drwxr-xr-x 3 user user 12288 Jul 19 15:11 ../
drwx------ 2 root      root       4096 Jul 19 15:11 thecakeisalie/

home/Download# cd thecakeisalie/; ls -l
total 16164
drwx------ 2 root      root         4096 Jul 19 15:11 ./
drwx------ 3 root      root         4096 Jul 19 15:11 ../
-rw------- 1 user user 2109623 May 19  2013 file1
-rw------- 1 user user 2520465 May 19  2013 file2
-rw------- 1 root root 393216  Jul 19 15:11 file3

TEST_2: Permita que sudo cp -a termine:

home/Download# ls -l
total 20
drwx------ 3 user user  4096 Jul 19 15:11 ./
drwxr-xr-x 3 user user 12288 Jul 19 15:11 ../
drwx------ 2 user user  4096 Jul 19 15:11 thecakeisalie/

home/Download# cd thecakeisalie/; ls -l
total 16164
drwx------ 3 user user  4096 Jul 19 15:11 ./
drwxr-xr-x 3 user user 12288 Jul 19 15:11 ../
-rw------- 1 user user 2109623 May 19  2013 file1
(...)
-rw------- 1 user user 2520465 May 19  2013 last_file

    

Answer 2

Isso parece muito estranho para mim - o que você descreveu é definitivamente não um problema conhecido. Eu usei cp -a extensivamente (inclusive para clonar sistemas Linux inteiros) e a única vez que vi um problema, ele foi causado por um bug no XFS (que foi corrigido posteriormente).

Meu palpite é que é um bug em btrfs , que ainda está em desenvolvimento extenso. É reproduzível? Você pode tentar copiar esses mesmos diretórios de origem para um novo local em seu sistema de arquivos de destino e ver se as permissões são preservadas. Se for reproduzível, você pode enviar um relatório de bug .