Por que motivo o Immich recria ficheiros em falta com o proprietário errado?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

O Immich não deve recriar silenciosamente um original de origem em falta como uma funcionalidade genérica de recuperação. Se um objeto eliminado reaparecer, identifique primeiro se é uma miniatura gerada, um vídeo codificado, um artefacto de perfil, um ficheiro sidecar XMP ou outro ficheiro gravável; estes podem ser recriados ou reescritos por processos diferentes e herdar um proprietário diferente.

Utilize um objeto regenerado descartável e o respetivo diretório principal. Compare o UID/GID numérico e as ACL no anfitrião com o escritor efetivo dentro do contentor e, em seguida, identifique se foi o Immich, uma funcionalidade de escrita de sidecars, um protocolo NAS ou outro processo do anfitrião que o criou. Evite executar chown recursivo ou chmod 777 até conhecer esse escritor.

Compare o Ficheiro Recriado com o Diretório Principal e com um Ficheiro Vizinho que Funcione

Registe o proprietário, o grupo, o modo, a ACL, os atributos estendidos, se relevantes, e o UID/GID numérico do ficheiro recriado, do respetivo diretório principal e de um ficheiro mais antigo que funcione corretamente. Os nomes podem induzir em erro entre um NAS e um contentor; os IDs numéricos revelam se “immich” num sistema corresponde à mesma identidade no outro.

O fluxo de permissões da ZimaSpace para ficheiros movidos para um NAS aplica-se diretamente: os novos objetos são regidos pela ACL de destino, pela identidade do contentor, pelo mapeamento do protocolo e pelas regras de criação. Assim, um ficheiro substituto pode ser legível e, ainda assim, adquirir um proprietário que interrompa o fluxo de trabalho de outra ferramenta. Se o ficheiro recriado corresponder à herança do diretório principal e apenas o nome apresentado parecer desconhecido, mapeie o ID numérico antes de alterar qualquer coisa. Se diferir tanto do diretório principal como dos ficheiros corretos conhecidos, prossiga para a identidade do escritor; o problema pode estar na configuração do contentor e não na ACL do sistema de ficheiros.

Identifique o Processo e o UID/GID Efetivo que Escrevem o Substituto

Acione uma regeneração segura enquanto monitoriza os registos e o sistema de ficheiros relevantes. Inspecione o utilizador efetivo e os grupos dentro do contentor que executa a escrita. Se for um sidecar, uma ferramenta de metadados, um processo de cópia de segurança ou um script do anfitrião a criar o ficheiro, inspecione esse serviço em vez de alterar a identidade de execução do Immich.

A propriedade dos contentores é numérica e não baseada em nomes. Uma explicação sobre a propriedade de ficheiros no Docker mostra por que motivo o mesmo ficheiro montado por bind pode apresentar um nome de utilizador diferente no anfitrião e no contentor quando os mapeamentos de UID/GID não coincidem. Utilize os IDs numéricos como referência comum.

Uma discussão sobre a propriedade de bibliotecas externas do Immich documentou sidecars XMP escritos como root numa implementação. Isto constitui evidência para verificar o escritor efetivo e a identidade de execução suportada, não uma afirmação de que todas as instalações atuais do Immich escrevam todos os ficheiros regenerados como root.

Se o contentor estiver intencionalmente a ser executado como um utilizador não root, confirme que o UID/GID existe efetivamente no anfitrião ou no NAS e que tem o acesso necessário ao caminho montado. Um nome de utilizador simbólico dentro de um contentor não corresponde automaticamente a uma conta do anfitrião com o mesmo nome.

Corrija a Regra de Criação em vez de Corrigir Repetidamente os Ficheiros Existentes

Corrija o limite mínimo confirmado: alinhe o UID/GID do serviço quando suportado, repare a herança do grupo ou da ACL do diretório principal, defina uma umask adequada ou altere o mapeamento da partilha NAS que fornece a identidade errada. Preserve a capacidade de o Immich e de qualquer outro leitor legítimo acederem aos originais e aos ficheiros gerados.

Não utilize permissões de escrita para todos como correção predefinida. Isso oculta a incompatibilidade de identidades e amplia desnecessariamente o acesso de escrita. Do mesmo modo, não altere recursivamente a propriedade da base de dados PostgreSQL, da cache de modelos, dos carregamentos e das bibliotecas externas com um único comando; esses caminhos podem utilizar intencionalmente identidades de serviço diferentes.

Se uma biblioteca externa se destinar a ser imutável, considere montar o volume como só de leitura e manter noutro local o estado gravável pertencente à aplicação, mas apenas se as funcionalidades que utiliza não exigirem escrita de sidecars nesse local. A decisão diz respeito à propriedade e ao comportamento de escrita pretendidos, não a forçar todos os ficheiros do arquivo fotográfico a partilharem a mesma conta.

Recrie Novamente um Ficheiro e Valide Após um Reinício

Remova apenas um objeto gerado descartável ou um sidecar de teste que possa ser recriado em segurança e, em seguida, acione novamente a operação exata do Immich. Verifique o novo proprietário, grupo, ACL e legibilidade tanto no Immich como no outro programa que anteriormente falhou. Mantenha os ficheiros multimédia originais intactos durante este teste.

Reinicie o contentor e, depois, reinicie o anfitrião uma vez para garantir que a identidade e as montagens corrigidas sobrevivem às alterações do ciclo de vida. Uma correção bem-sucedida cria automaticamente o ficheiro seguinte com a propriedade esperada; não depende de um script chown executado após o arranque e que entre em conflito com as escritas do Immich.

Pare e restaure a partir da configuração preservada se as alterações de propriedade se propagarem inesperadamente à base de dados ou aos originais, ou se o serviço perder acesso de leitura/escrita após o reinício. Ao escalar o problema, inclua os IDs numéricos, o resultado das ACL, as opções de montagem, o utilizador efetivo do contentor, o fragmento do Compose e o tipo exato de ficheiro recriado pelo Immich.

Suporte e Dicas

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.