Este tópico de maio de 2026 começou como uma primeira impressão frustrada após uma longa noite com o ZimaOS. O AdGuard Home e o Pi-hole pareciam funcionar em redes Docker isoladas, em vez da LAN 192.168.60.0/24 do utilizador, o Jellyfin só funcionou após várias tentativas e as cópias de segurança do Time Machine de um MacBook Pro falharam. No entanto, depois de mais testes, duas das conclusões originais mudaram: o AdGuard Home passou a funcionar e o problema do Time Machine acompanhou o MacBook até uma partilha TrueNAS, afastando a hipótese de a causa ser o ZimaOS.
Por isso, o tópico é mais útil como estudo de caso de resolução de problemas do que como um veredicto sobre o sistema operativo. Mostra por que motivo é necessário isolar as redes Docker, os modelos de aplicações e o comportamento das cópias de segurança no lado do cliente antes de culpar a própria plataforma NAS.
O assistente de configuração do AdGuard apresentava endereços Docker em vez do IP da LAN
Após uma instalação normal, o ecrã de configuração do AdGuard Home apresentava endereços como 127.0.0.1 e 172.17.0.2. O utilizador esperava ver o endereço LAN estático do anfitrião ZimaOS, 192.168.60.241.
Mudar para a rede do anfitrião não foi uma solução simples
O utilizador encontrou uma solução alternativa ao estilo da comunidade que alterava o modo de rede do Compose para host. Depois de também alterar as definições da aplicação, a instalação deixou de estar acessível. Este resultado negativo é importante, porque a rede do anfitrião altera tanto a posse das portas como os pressupostos de um modelo da App Store.
Não trate network_mode: host como uma resposta universal para contentores DNS. Pode ser útil quando a aplicação precisa realmente de visibilidade ao nível do anfitrião, mas também pode criar conflitos de portas com o painel do ZimaOS, outro resolvedor DNS ou outro contentor.
O utilizador acabou por conseguir pôr o AdGuard a funcionar com uma variante diferente da aplicação
Mais tarde, o autor original atualizou o tópico depois de encontrar instruções que utilizavam a versão Network da aplicação AdGuard, em vez do pacote predefinido, e que adicionavam os mapeamentos de portas necessários para a interface Web. Disse que o assistente de configuração continuava sem mostrar o endereço 192.168.60.x esperado, mas que o AdGuard funcionava.
Isto confirma um princípio de diagnóstico importante: o contentor não precisa de apresentar o endereço LAN do anfitrião no assistente de configuração para responder a pedidos DNS de clientes da LAN. O que importa é saber se as portas DNS e Web publicadas estão acessíveis a partir da rede.
O próprio anfitrião ZimaOS tinha uma configuração de rede estática válida
Os contentores DNS precisam mais das portas corretas do que de um endereço aparentemente correto no assistente
O AdGuard Home e o Pi-hole são mais sensíveis à rede do que uma aplicação Web comum, porque os clientes precisam de aceder ao DNS na porta 53, normalmente através de UDP e TCP. A interface de gestão utiliza portas Web separadas.
Se uma aplicação DNS for considerada saudável, mas os clientes da LAN não conseguirem utilizá-la, verifique as portas efetivamente publicadas e se outro serviço já está a utilizar a porta 53 antes de alterar o IP estático do anfitrião.
O funcionamento do Jellyfin ajudou a excluir uma falha total do Docker ou do armazenamento
O utilizador afirmou que o Jellyfin acabou por funcionar. Isso não provou que a rede do AdGuard estivesse correta, mas mostrou que o ZimaOS conseguia executar aplicações Docker e aceder ao armazenamento multimédia na mesma instalação. Assim, a resolução de problemas podia manter-se centrada na configuração de rede específica da aplicação, em vez de considerar toda a pilha de contentores inutilizável.
A falha do Time Machine acompanhou o MacBook até ao TrueNAS
A correção mais importante no tópico surgiu no dia seguinte. O utilizador apagou e reinstalou o ZimaOS e voltou a testar o Time Machine. O Mac mini mais antigo, com Monterey, fez a cópia de segurança com sucesso, enquanto o MacBook mais recente continuou a falhar.
Em seguida, experimentou uma partilha do Time Machine no TrueNAS e o MacBook também falhou aí. Este teste cruzado transferiu a causa provável do ZimaOS para o MacBook ou para o comportamento do macOS/SMB.
Por que motivo testar outro NAS é tão útil
Se o mesmo cliente falhar com duas plataformas NAS independentes, enquanto outro Mac funcionar com o destino ZimaOS, as evidências deixam de sustentar “o Time Machine do ZimaOS está avariado” como a explicação mais simples.
Esta é uma regra geral útil na resolução de problemas de NAS: altere apenas um dos lados da ligação de cada vez. Um segundo servidor ou um segundo cliente pode revelar rapidamente se a falha acompanha o servidor, o cliente ou uma combinação específica de ambos.
O ZimaOS atual deve ser avaliado com as definições atuais de armazenamento e aplicações
O tópico original reflete o ZimaOS em maio de 2026. Desde então, a plataforma continuou a evoluir, incluindo a configuração de aplicações, a edição de YAML, a gestão do armazenamento e o comportamento das cópias de segurança. Numa instalação nova, comece por consultar o modelo atual de funcionalidades e armazenamento do ZimaOS, em vez de presumir que todos os modelos da App Store de 2026 permanecem inalterados.
Uma melhor sequência de testes após uma instalação nova
- Configure o armazenamento e a localização dos dados das aplicações antes de instalar muitas aplicações.
- Verifique uma aplicação simples, como o Jellyfin ou outro serviço Web.
- Nas aplicações DNS, verifique a porta 53 separadamente da interface Web.
- Não mude para a rede do anfitrião até compreender a ponte e o mapeamento de portas existentes.
- Para o Time Machine, teste outro Mac ou outro destino SMB do Time Machine, quando possível.
- Só depois de a falha acompanhar um componente deverá considerar esse componente como a causa provável.
Perguntas frequentes sobre a resolução de problemas de uma instalação nova do ZimaOS
O AdGuard Home acabou por funcionar para o utilizador original?
Sim. O utilizador afirmou que a variante Network da aplicação, juntamente com uma configuração adicional de portas, funcionou.
O assistente de configuração do AdGuard chegou a apresentar o endereço 192.168.60.x esperado?
Não, mas a aplicação funcionou na mesma. O assistente apresentava as interfaces visíveis dentro do contentor.
Foi provado que o ZimaOS era a causa da falha do Time Machine?
Não. O MacBook também falhou com uma partilha do Time Machine no TrueNAS, enquanto um Mac mini mais antigo funcionou com o ZimaOS.
