Cette discussion de mai 2026 a commencé par une première impression frustrante après une longue nuit passée avec ZimaOS. AdGuard Home et Pi-hole semblaient fonctionner dans des réseaux Docker isolés, plutôt que sur le réseau local 192.168.60.0/24 de l'utilisateur, Jellyfin n'a fonctionné qu'après plusieurs tentatives et les sauvegardes Time Machine d'un MacBook Pro échouaient. Après plusieurs tests supplémentaires, toutefois, deux des conclusions initiales ont changé : AdGuard Home a finalement été rendu fonctionnel et le problème de Time Machine s'est également manifesté sur un partage TrueNAS depuis le MacBook, ce qui écartait ZimaOS.
Cette discussion est donc plus utile comme étude de cas de dépannage que comme jugement sur le système d'exploitation. Elle montre pourquoi il faut isoler le réseau Docker, les modèles d'applications et le comportement des sauvegardes côté client avant d'accuser la plateforme NAS elle-même.
L'assistant de configuration d'AdGuard affichait des adresses Docker au lieu de l'adresse du réseau local
Après une installation standard, l'écran de configuration d'AdGuard Home de l'utilisateur affichait des adresses telles que 127.0.0.1 et 172.17.0.2. L'utilisateur s'attendait à voir l'adresse statique du réseau local de l'hôte ZimaOS, 192.168.60.241.
Le passage au réseau de l'hôte n'a pas constitué une solution fiable
L'utilisateur a trouvé une solution de contournement proposée par la communauté, qui modifiait le mode réseau de Compose en host. Après avoir également modifié les paramètres de l'application, l'installation est devenue inaccessible. Ce résultat négatif est important, car le réseau de l'hôte modifie à la fois la gestion des ports et les hypothèses formulées par un modèle de l'App Store.
Ne considérez pas network_mode: host comme une solution universelle pour les conteneurs DNS. Ce mode peut être utile lorsque l'application a réellement besoin d'une visibilité réseau au niveau de l'hôte, mais il peut aussi créer des conflits de ports avec le tableau de bord ZimaOS, un autre résolveur DNS ou un autre conteneur.
L'utilisateur a finalement réussi à faire fonctionner AdGuard avec une autre variante de l'application
L'auteur du message a ensuite mis à jour la discussion après avoir trouvé des instructions utilisant la version Network de l'application AdGuard, plutôt que le paquet par défaut, et ajoutant les mappages de ports requis pour l'interface Web. Il a indiqué que l'assistant de configuration n'affichait toujours pas l'adresse 192.168.60.x attendue, mais qu'AdGuard fonctionnait.
Cela confirme un principe de diagnostic important : le conteneur n'a pas besoin d'afficher l'adresse du réseau local de l'hôte dans son assistant de configuration pour répondre aux requêtes DNS des clients du réseau local. L'essentiel est que les ports DNS et Web publiés soient accessibles depuis le réseau.
L'hôte ZimaOS disposait lui-même d'une configuration réseau statique valide
Les conteneurs DNS ont davantage besoin des bons ports que d'une adresse d'assistant qui semble correcte
AdGuard Home et Pi-hole sont plus sensibles au réseau qu'une application Web ordinaire, car les clients doivent pouvoir accéder au DNS sur le port 53, généralement en UDP et en TCP. L'interface d'administration utilise des ports Web distincts.
Si une application DNS est indiquée comme fonctionnelle, mais que les clients du réseau local ne peuvent pas l'utiliser, vérifiez les ports réellement publiés et assurez-vous qu'un autre service n'utilise pas déjà le port 53 avant de modifier l'adresse IP statique de l'hôte.
Le fonctionnement de Jellyfin a contribué à écarter une défaillance générale de Docker ou du stockage
L'utilisateur a indiqué que Jellyfin avait finalement fonctionné. Cela ne prouvait pas que la configuration réseau d'AdGuard était correcte, mais montrait que ZimaOS pouvait exécuter des applications Docker et accéder au stockage multimédia dans la même installation. Le dépannage pouvait donc rester centré sur la configuration réseau propre à l'application, plutôt que de considérer toute la pile de conteneurs comme inutilisable.
L'échec de Time Machine a suivi le MacBook sur TrueNAS
La correction la plus importante de la discussion est arrivée le lendemain. L'utilisateur a effacé et réinstallé ZimaOS, puis a de nouveau testé Time Machine. Son ancien Mac mini sous Monterey a effectué la sauvegarde avec succès, tandis que le MacBook plus récent échouait toujours.
Il a ensuite essayé un partage Time Machine sur TrueNAS, et le MacBook a également échoué. Ce test croisé a déplacé la cause probable de ZimaOS vers le MacBook ou son comportement avec macOS/SMB.
Pourquoi tester un autre NAS est si utile
Si le même client échoue avec deux plateformes NAS indépendantes alors qu'un autre Mac fonctionne avec la cible ZimaOS, les éléments disponibles ne permettent plus de considérer « Time Machine est défaillant sur ZimaOS » comme l'explication la plus simple.
Il s'agit d'une règle générale utile pour le dépannage des NAS : ne modifiez qu'un côté de la connexion à la fois. Un deuxième serveur ou un deuxième client peut rapidement révéler si la défaillance suit le serveur, le client ou une combinaison précise des deux.
ZimaOS doit aujourd'hui être évalué avec les paramètres de stockage et d'applications actuels
La discussion d'origine décrit ZimaOS en mai 2026. La plateforme a continué d'évoluer depuis, notamment en ce qui concerne la configuration des applications, la modification des fichiers YAML, la gestion du stockage et le comportement des sauvegardes. Pour une nouvelle installation, commencez par le modèle actuel des fonctionnalités et du stockage de ZimaOS, plutôt que de supposer que chaque modèle de l'App Store de 2026 est resté inchangé.
Une meilleure séquence de tests après une nouvelle installation
- Configurez le stockage et l'emplacement des données des applications avant d'installer de nombreuses applications.
- Vérifiez une application simple, comme Jellyfin ou un autre service Web.
- Pour les applications DNS, vérifiez séparément le port 53 et l'interface Web.
- Ne passez pas au réseau de l'hôte avant d'avoir compris la configuration existante du réseau pont et des mappages de ports.
- Pour Time Machine, testez si possible un autre Mac ou une autre cible SMB compatible avec Time Machine.
- Ce n'est qu'après avoir constaté que la défaillance suit un composant que vous devez considérer celui-ci comme la cause première probable.
FAQ sur le dépannage d'une nouvelle installation de ZimaOS
AdGuard Home a-t-il finalement fonctionné pour l'utilisateur à l'origine de la discussion ?
Oui. L'utilisateur a indiqué que la variante de l'application Network, accompagnée d'une configuration supplémentaire des ports, fonctionnait.
L'assistant de configuration d'AdGuard a-t-il fini par afficher l'adresse 192.168.60.x attendue ?
Non, mais l'application fonctionnait malgré tout. L'assistant affichait les interfaces visibles depuis le conteneur.
ZimaOS a-t-il été établi comme la cause de l'échec de Time Machine ?
Non. Le MacBook échouait également avec un partage Time Machine TrueNAS, tandis qu'un ancien Mac mini fonctionnait avec ZimaOS.
