Porque é que os proprietários dos ficheiros dos contentores mudam depois de copiar os dados das aplicações?

Os proprietários dos ficheiros de um contentor mudam após uma cópia quando os valores numéricos de UID/GID não são preservados ou quando o runtime de destino os remapeia ou reescreve.

Num NAS doméstico, o mesmo ficheiro pode apresentar um nome de utilizador no anfitrião e outro dentro de um contentor, porque a propriedade é armazenada como números, enquanto cada ambiente resolve esses números através de uma base de dados de contas diferente. As cópias efetuadas através de uma interface gráfica, partilha SMB, arquivo, shell de root, ferramenta de migração ou ponto de entrada do contentor também podem substituir a propriedade. Diagnostique primeiro a identidade numérica e, em seguida, distinga o comportamento da cópia, as definições do utilizador do runtime, os scripts de arranque, os namespaces de utilizadores e o mapeamento de sistemas de ficheiros de rede antes de alterar as permissões em toda a árvore de dados da aplicação.

Compare os UID e GID numéricos antes de comparar os nomes de utilizador

Inspecione a origem e o destino com a propriedade numérica, não apenas com os nomes. Registe o UID, o GID, o modo, as ACL, os atributos estendidos e o sistema de ficheiros de um ficheiro representativo e do respetivo diretório-pai, tanto no anfitrião como dentro do contentor.

Os bind mounts do Docker expõem ficheiros do anfitrião a processos que podem utilizar uma base de dados de utilizadores diferente. Uma discussão da comunidade Docker explica por que motivo o acesso fiável depende do alinhamento numérico de UID/GID, e não apenas da correspondência dos nomes de utilizador.

Se os números forem idênticos, mas os nomes apresentados forem diferentes, a propriedade pode não ter mudado. Corrija a documentação ou o mapeamento de contas, em vez de reescrever recursivamente os dados. Se os números forem diferentes, preserve os dados recolhidos e avance para as fases da cópia e do runtime.

Identifique se a cópia preservou ou recriou a propriedade

Anote o percurso exato da cópia: gestor de ficheiros do anfitrião, cp, rsync, arquivo tar, cliente SMB/NFS, restauro de cópia de segurança, comando de cópia do Docker ou contentor de migração temporário. Cada método tem predefinições diferentes para proprietário, grupo, ACL e atributos estendidos.

Uma cópia executada como root pode preservar a propriedade numérica quando são utilizadas opções explícitas de arquivo, enquanto outra ferramenta pode criar todos os ficheiros de destino com a conta que executa a cópia. Um problema recente de migração de contentores mostra como os dados de uma aplicação copiados podem ficar inacessíveis quando o UID de destino é diferente da identidade de runtime da aplicação.

Repita a operação com um pequeno diretório de teste e inspecione imediatamente a propriedade antes de a aplicação arrancar. Se os números já estiverem errados, corrija o método de cópia ou as opções de restauro. Se mudarem apenas após o arranque, não altere a cópia e investigue o ponto de entrada do contentor.

Faça corresponder o utilizador do runtime do contentor ao proprietário do armazenamento no anfitrião

Inspecione o utilizador efetivo dentro do contentor em execução e o proprietário numérico do diretório de dados da aplicação montado através de bind mount. Verifique também user: no Compose, os grupos suplementares, as variáveis PUID/PGID da plataforma e quaisquer definições de contas específicas da imagem.

Executar um contentor com um utilizador sem privilégios não concede automaticamente acesso a um diretório do anfitrião pertencente a outra identidade numérica. Um caso no fórum Docker resolve esta fronteira fazendo corresponder o utilizador do contentor às permissões do anfitrião, em vez de tornar o diretório universalmente editável.

Escolha um modelo de propriedade estável para a aplicação e documente-o no Compose. Adicione apenas os grupos necessários para o acesso partilhado. Evite chmod 777, pois isso oculta a incompatibilidade de identidades, enfraquece a separação e não preserva o proprietário pretendido para ficheiros futuros.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique se o ponto de entrada altera a propriedade no arranque

Muitas imagens arrancam brevemente como root, criam diretórios em falta, aplicam um UID/GID configurado e alteram recursivamente a propriedade antes de removerem os privilégios. Esse comportamento pode fazer com que uma cópia correta pareça alterar-se sozinha após o primeiro arranque do contentor.

Os runtimes de contentores e as imagens também podem disponibilizar comportamentos de montagem que alteram a propriedade. Um problema do Podman indica que a opção :U pode reescrever a propriedade da origem, enquanto os scripts de ponto de entrada podem efetuar uma alteração recursiva semelhante durante o arranque da aplicação.

Inicie o contentor uma vez com os registos visíveis e monitorize uma pequena subárvore de teste. Procure no ponto de entrada e nas notas de lançamento da imagem referências a chown, migração de utilizadores, PUID/PGID e correções de permissões. Desative ou limite esse comportamento apenas quando a imagem suportar uma alternativa estável.

Tenha em conta o Docker sem root, os namespaces de utilizadores e os sistemas de ficheiros de rede

O Docker sem root e o remapeamento de namespaces de utilizadores traduzem os IDs do contentor para outro intervalo no anfitrião. O NFS, o CIFS e algumas opções de montagem de NAS podem, de forma independente, aplicar squash ao root ou forçar todos os ficheiros para um UID e GID configurados.

Um relatório sobre permissões no Docker sem root mostra ficheiros com uma propriedade inesperada porque a identidade do contentor é mapeada através de um intervalo subordinado do anfitrião. A pista de diagnóstico é o mapeamento da propriedade através do namespace de utilizadores, e não uma falha de cópia convencional.

Verifique se o caminho dos dados é local, NFS, CIFS, FUSE ou outro sistema de ficheiros montado e registe o respetivo comportamento de UID/GID, root-squash e ACL. Teste separadamente a criação de propriedade a partir do anfitrião e do contentor. Não execute chown recursivo numa partilha de rede antes de compreender a política de identidade do lado do servidor.

Corrija a propriedade a partir de uma identidade conhecida da aplicação

Pare a aplicação, faça uma cópia de segurança dos metadados atuais e defina o UID, o GID, os modos dos diretórios, os modos dos ficheiros, as ACL e as etiquetas de segurança exatos esperados pela imagem. Corrija apenas os caminhos pertencentes à aplicação, excluindo multimédia partilhada ou conjuntos de dados não relacionados.

O guia da ZimaSpace sobre como separar falhas de permissões de montagens só de leitura é a verificação seguinte quando a propriedade correta continua a não permitir escritas.

Reinicie o contentor e crie, modifique e elimine um ficheiro de teste como o utilizador real do serviço. Em seguida, recrie o contentor e repita o teste. A reparação só está concluída quando a propriedade permanece estável após a cópia, o arranque, o reinício e a recriação do contentor, e a aplicação consegue ler e escrever sem exceções de permissões abrangentes.