Porque é que o Home Assistant recria ficheiros em falta com o proprietário errado?

Eva Wong

IceWhale author

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.

Why Does Home Assistant Recreate Missing Files With the Wrong Owner? - Zima Store Online

O Home Assistant não escolhe um nome de utilizador amigável para o anfitrião quando recria um ficheiro. Normalmente, o novo ficheiro herda o UID numérico, o GID, a umask, a ACL e as regras do sistema de ficheiros do processo que o criou dentro do contentor.

Isto torna-se visível numa montagem bind porque o Linux regista identidades numéricas, enquanto o anfitrião e o contentor podem associar nomes diferentes ao mesmo número. Antes de alterar permissões, pare o Home Assistant, registe os proprietários numéricos antigo e novo, identifique o processo em execução e determine se o ficheiro foi criado pelo Home Assistant, por um entrypoint, por uma ferramenta de cópia de segurança ou pelo anfitrião.

Confirme qual foi o processo que criou o ficheiro

Compare a hora de criação ou modificação do ficheiro com o arranque do contentor, o restauro, a atualização ou a tarefa do suplemento. Em seguida, verifique o UID e o GID numéricos no anfitrião e a identidade do processo do Home Assistant dentro do contentor. Os nomes de utilizador podem diferir; os números são a comparação fiável.

O problema subjacente do contentor é que os ficheiros montados por bind são criados com a identidade utilizada pelo processo do contentor. Uma explicação independente sobre a diferença entre o proprietário do sistema de ficheiros do anfitrião mostra por que motivo corresponder apenas os nomes não resolve as diferenças entre UID e GID numéricos.

Se o novo proprietário corresponder ao processo do contentor, a causa principal fica confirmada. Se corresponder ao root ou a outro auxiliar, inspecione o entrypoint, a ferramenta de restauro, a tarefa agendada ou o script executado no anfitrião antes de alterar o utilizador de execução do Home Assistant.

Verifique a montagem, a ACL e os limites do sistema de ficheiros

Confirme que o caminho é a montagem bind pretendida e não um volume nomeado ou um diretório da imagem ocultado pela montagem. Verifique o proprietário do diretório principal, o modo, a ACL predefinida e se o sistema de ficheiros é local, NFS, SMB ou outro caminho suportado pela rede.

Um processo só pode criar um ficheiro de acordo com as permissões e o mapeamento apresentados pelo sistema de ficheiros. O mapeamento de identidades NFS, a supressão do root, as opções de montagem SMB, as ACL predefinidas e uma umask restritiva podem alterar o proprietário aparente ou o acesso de escrita, mesmo quando o UID do contentor está correto.

Se um ficheiro temporário criado como UID de execução receber o proprietário esperado, prossiga para o criador específico da aplicação. Se receber o proprietário errado, repare primeiro o mapeamento da montagem ou do sistema de ficheiros; alterar a configuração do Home Assistant não substituirá essa camada.

Repare apenas a incompatibilidade de propriedade confirmada

Pare o Home Assistant antes de alterar a propriedade de bases de dados, registos ou ficheiros de configuração ativos. Crie uma cópia de segurança ou um instantâneo e altere apenas o caminho afetado para o UID e GID de serviço verificados. Preserve os bits de execução, as ACL e as permissões especiais, em vez de aplicar um modo abrangente, como acesso de escrita para todos.

Atualize a definição da implementação para que seja utilizada a mesma identidade de execução após a recriação ou documente por que motivo a imagem tem de ser executada com a sua identidade predefinida e faça corresponder o caminho do anfitrião a essa identidade. Evite executar um chown de todo o diretório no arranque em todas as inicializações; pode ser lento, ocultar erros de conceção e alterar ficheiros pertencentes a outros serviços.

O guia da ZimaSpace para evitar desvios de permissões fornece a lista de verificação operacional mais abrangente para montagens, propriedade, testes de escrita e comportamento do restauro depois de corrigida a incompatibilidade imediata de proprietário.

-15% OFF

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

Single board computer zimaboard2

Verifique a propriedade após a recriação e uma escrita real

Inicie o Home Assistant e acione exatamente a operação que recriou o ficheiro. Confirme que o novo ficheiro tem o proprietário numérico pretendido, que o Home Assistant consegue atualizá-lo e que o processo de cópia de segurança do anfitrião consegue lê-lo. Um arranque bem-sucedido sem uma escrita não comprova a correção.

Reinicie uma vez e recrie o contentor a partir da configuração guardada. A propriedade, a ACL e o comportamento de escrita devem permanecer estáveis após ambos os eventos. Verifique nos registos erros de permissão negada, base de dados só de leitura, cópia de segurança falhada ou erros de configuração da integração.

Peça assistência ao responsável pela manutenção da imagem ou ao administrador do armazenamento se a identidade criadora mudar inesperadamente entre versões, se um sistema de ficheiros de rede reescrever a propriedade ou se um serviço necessário não puder partilhar o caminho com segurança. Preserve os IDs numéricos, a definição da montagem, o tipo de sistema de ficheiros e uma reprodução mínima.