Se o PeaNUT continuar a detetar a sua UPS depois de reiniciar o ZimaOS, mas as definições guardadas desaparecerem, o problema costuma estar na persistência e não na conectividade com a UPS. O diretório de configuração tem de ser associado a um armazenamento persistente do ZimaOS e o contentor tem de conseguir escrever nesse diretório.
O tópico do fórum de março de 2026 confirmou uma solução para a compilação do PeaNUT instalada nessa altura: associar uma pasta persistente do anfitrião a /app/config. Entretanto, a documentação atual do PeaNUT normalizou a configuração persistente em /config, pelo que as novas instalações devem seguir o caminho atual, em vez de copiarem cegamente o caminho antigo do contentor.
O que a solução do fórum comprovou realmente
O autor original relatou que todas as definições do PeaNUT desapareciam após cada reinício do ZimaOS, embora o Home Assistant continuasse a receber dados da UPS. Um membro da comunidade analisou o pacote e sugeriu alterar o mapeamento do volume para que uma pasta do anfitrião, dentro dos dados de aplicações do ZimaOS, fosse montada em /app/config. O autor original respondeu que isso “resolveu o problema”, tornando-a uma solução verificada para essa versão específica do pacote.
Esse resultado não significa que /app/config seja o destino correto para todas as imagens atuais do PeaNUT. Os caminhos dos contentores fazem parte do contrato da imagem e podem mudar entre compilações.
Nas compilações atuais do PeaNUT, use /config
A atual documentação Docker do PeaNUT utiliza /config para as definições persistentes. A imagem atual também espera que esse diretório possa ser escrito pelo utilizador do serviço, normalmente UID/GID 1000:1000.
No ZimaOS, associe um diretório persistente do anfitrião, como uma pasta de dados de aplicações, a /config e, em seguida, reinicie o contentor e faça uma alteração inofensiva nas definições. Reinicie novamente e confirme que a alteração permanece. O mesmo princípio de persistência é abordado no guia de migração de dados de aplicações do ZimaOS.
Verifique as permissões de escrita antes de alterar novamente os caminhos
Se o mapeamento estiver correto, mas as definições continuarem a ser repostas, verifique nos registos do PeaNUT se existem erros de permissões. O código atual a montante avisa explicitamente quando não é possível escrever em /config. Não assuma que adicionar variáveis de ambiente PUID ou PGID não suportadas irá corrigir a imagem; as orientações atuais a montante centram-se, em vez disso, em tornar a pasta do anfitrião gravável pelo utilizador de serviço efetivamente utilizado pelo contentor.
O fórum de discussões do PeaNUT a montante é útil quando uma imagem atual produz erros específicos de permissões.
Porque pode falhar o docker exec
O tópico original também mostrou que docker exec -it PeaNUT sh falhava porque essa imagem do PeaNUT não continha uma shell. Isso não é prova de que o contentor esteja avariado. As imagens mínimas podem omitir intencionalmente sh ou bash.
Comece pelos registos do contentor e pelo mapeamento de volumes configurado. Para obter noções gerais sobre a persistência de contentores, o guia introdutório de aplicações Docker do ZimaOS explica por que razão os dados montados a partir do anfitrião sobrevivem à recriação e aos reinícios do contentor.
Em resumo
A antiga solução da comunidade era válida para o pacote PeaNUT utilizado em março de 2026, mas as compilações atuais do PeaNUT documentam /config como diretório persistente. Utilize o caminho do contentor documentado pela imagem instalada, torne a pasta do anfitrião gravável e verifique a persistência através de um reinício antes de alterar qualquer outra coisa.
