Como evitar a deriva de permissões nas pastas de dados do Immich

Prevenir a deriva de permissões no Immich significa tornar previsíveis a propriedade dos ficheiros e as regras de acesso antes que diferentes contentores, protocolos NAS, atualizações ou tarefas de manutenção criem novos ficheiros com identidades diferentes.

A solução duradoura não é repor periodicamente as permissões de forma recursiva. Registe o UID/GID numérico e o acesso de que cada fluxo de trabalho realmente necessita, mantenha deliberadas a propriedade dos pontos de montagem e a herança de ACL, separe os caminhos só de leitura dos caminhos com escrita e teste o processo de criação após cada alteração. A deriva de permissões é evitada quando o novo ficheiro de amanhã é criado corretamente sem um chown de emergência, não quando a biblioteca de hoje, por acaso, é legível.

Registe as identidades que leem e escrevem em cada caminho do Immich

Liste os caminhos do anfitrião montados no Immich e identifique quais os processos que devem ler, criar, renomear ou eliminar ficheiros em cada um deles. Para cada processo que escreve, registe o respetivo UID e GID numéricos no anfitrião e dentro do contentor. Os IDs numéricos são mais importantes do que a correspondência dos nomes de utilizador, porque os ficheiros armazenam a propriedade como números.

Inclua no inventário os processos que escrevem fora do Immich. Os carregamentos por SMB, os clientes NFS, as ferramentas de cópia de segurança, os scripts de importação, os contentores de gestão de multimédia e uma shell de administrador podem todos criar ficheiros na mesma árvore. Se o fizerem com identidades diferentes, a biblioteca pode acumular gradualmente proprietários e modos que funcionam num caminho, mas falham noutro.

Mantenha este mapa de identidades juntamente com a configuração do Compose. Uma futura atualização de imagem, migração do servidor ou conta NAS restaurada poderá então ser comparada com uma base conhecida e correta, em vez de descobrir a incompatibilidade apenas depois de os novos carregamentos começarem a falhar.

Use um modelo deliberado de proprietário, grupo partilhado e acesso mínimo

Decida qual deve ser a identidade proprietária dos dados geridos pela aplicação e qual o grupo partilhado, se existir, que precisa de acesso. Conceda a cada fluxo de trabalho apenas as permissões de leitura ou escrita de que necessita. Evite tornar toda a árvore do Immich acessível a todos para escrita simplesmente porque um contentor não consegue criar uma miniatura ou mover um ficheiro importado.

As incompatibilidades de UID/GID e os modos demasiado permissivos são causas comuns de falhas em volumes partilhados. O padrão mais seguro é alinhar as permissões dos contentores e dos volumes, em vez de conceder acesso irrestrito. Isto é importante num servidor doméstico onde vários serviços podem aceder ao mesmo conjunto de armazenamento.

Se vários serviços precisarem de acesso de escrita, use um grupo partilhado e permissões de grupo ou ACL consistentes, em vez de alternar a propriedade recursiva entre aplicações. Verifique primeiro um diretório representativo. Alterações recursivas abrangentes em toda a biblioteca de fotografias devem ser um último recurso, com uma cópia de segurança atual, e não uma tarefa de manutenção de rotina.

Torne previsíveis as permissões dos novos ficheiros

Os ficheiros existentes podem parecer perfeitos, enquanto os novos ficheiros sofrem imediatamente uma deriva porque as regras de criação estão erradas. Verifique a ACL do diretório-pai, as entradas de ACL predefinidas, a umask, a identidade do serviço e quaisquer definições de criação SMB ou NFS aplicáveis ao caminho. O objetivo da prevenção é a herança, não a limpeza.

Antes de alterar modos recursivamente, compare a propriedade numérica no anfitrião com o UID/GID efetivamente utilizado dentro do contentor. Esta verificação do UID/GID do bind mount permite distinguir rapidamente uma incompatibilidade de identidade de uma permissão realmente em falta. Corrija a relação entre proprietário e grupo, em vez de a ocultar com modos permissivos.

Crie um pequeno ficheiro de teste através de cada caminho normal de escrita: carregamento no Immich, fluxo de importação, transferência SMB/NFS, se utilizada, e restauro de uma cópia de segurança. Inspecione o proprietário, o grupo, o modo e a ACL após cada teste. Se dois caminhos de criação produzirem resultados incompatíveis, resolva esse conflito de políticas antes de importar mais dados.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Impeça que alterações de montagem e atualizações reescrevam a propriedade

Trate uma edição do Compose, uma atualização de imagem, uma remontagem do NAS ou uma migração como uma alteração sensível às permissões. Antes de a aplicar, registe a origem e o destino atuais da montagem, se o caminho é só de leitura ou permite escrita, o utilizador efetivo do contentor e uma amostra da propriedade numérica de cada diretório importante.

As transferências e o armazenamento de rede podem introduzir identidades SMB/NFS, IDs numéricos, herança de ACL e comportamentos de umask diferentes. Use os pontos de falha das alterações de permissões num NAS como lista de verificação antes da alteração sempre que os dados do Immich forem movidos entre sistemas de ficheiros ou métodos de acesso.

Após a alteração, compare as mesmas amostras antes de executar tarefas em massa. Se a propriedade mudar subitamente no arranque, pare a stack e identifique qual o entrypoint, tarefa de manutenção ou identidade remapeada que causou a alteração. Não permita que uma reescrita recursiva da propriedade, sem explicação, continue numa biblioteca de grandes dimensões.

Faça auditorias à deriva com testes pequenos e repetíveis

Execute uma auditoria ligeira às permissões de forma agendada ou após atualizações: verifique alguns originais estáveis, um carregamento recente, um derivado recém-gerado e qualquer montagem de biblioteca externa. Procure proprietários inesperados, acesso de grupo em falta, montagens só de leitura que se tornaram graváveis ou ACL que já não são herdadas conforme esperado.

Em seguida, execute um teste de escrita de ponta a ponta. Carregue um recurso descartável através do cliente normal, deixe que o Immich o processe, abra-o e remova-o através da aplicação. Se os caminhos de bibliotecas externas ou de importação fizerem parte da sua configuração, adicione um ficheiro representativo através desses caminhos e confirme que o Immich consegue lê-lo sem alterar a propriedade de forma inesperada.

O ciclo de prevenção só está completo quando os novos ficheiros continuam a receber a identidade e o acesso pretendidos após um reinício do Immich e um reinício do anfitrião. Se as permissões exigirem uma reparação manual após qualquer um desses eventos, o sistema continua a sofrer deriva; corrija a regra de criação ou o mapeamento de identidades antes de expandir o acesso.