Deze thread uit mei 2026 begon als een gefrustreerde eerste indruk na een lange nacht met ZimaOS. AdGuard Home en Pi-hole leken in geïsoleerde Docker-netwerken te draaien in plaats van op het LAN van de gebruiker, 192.168.60.0/24. Jellyfin werkte pas na meerdere pogingen en Time Machine-reservekopieën vanaf een MacBook Pro mislukten. Na verder testen veranderden echter twee van de oorspronkelijke conclusies: AdGuard Home werd werkend gekregen en het Time Machine-probleem deed zich ook voor op een TrueNAS-share, waardoor ZimaOS minder waarschijnlijk de oorzaak was.
De thread is daarom nuttiger als casestudy voor probleemoplossing dan als oordeel over het besturingssysteem. Hij laat zien waarom Docker-netwerken, applicatiesjablonen en back-upgedrag aan de clientzijde afzonderlijk moeten worden onderzocht voordat je het NAS-platform zelf de schuld geeft.
De installatiewizard van AdGuard toonde Docker-adressen in plaats van het LAN-IP-adres
Na een standaardinstallatie toonde het installatiescherm van AdGuard Home adressen zoals 127.0.0.1 en 172.17.0.2. De gebruiker verwachtte het statische LAN-adres van de ZimaOS-host te zien: 192.168.60.241.
Overschakelen naar hostnetwerken was geen probleemloze oplossing
De gebruiker vond een workaround uit de community waarbij de Compose-netwerkmodus werd gewijzigd in host. Nadat ook de app-instellingen waren aangepast, werd de installatie onbereikbaar. Dat negatieve resultaat is relevant, omdat hostnetwerken zowel het poortbeheer als de aannames van een App Store-sjabloon veranderen.
Beschouw network_mode: host niet als een universele oplossing voor DNS-containers. Het kan nuttig zijn wanneer de app echt zichtbaarheid op hostniveau nodig heeft, maar het kan ook poortconflicten veroorzaken met het ZimaOS-dashboard, een andere DNS-resolver of een andere container.
De gebruiker kreeg AdGuard uiteindelijk werkend met een andere appvariant
De oorspronkelijke poster voegde later een update aan de thread toe nadat die instructies had gevonden waarin de Network-versie van de AdGuard-app werd gebruikt in plaats van het standaardpakket, met de vereiste poortkoppelingen voor de webinterface. De gebruiker gaf aan dat de installatieassistent nog steeds niet het verwachte adres 192.168.60.x toonde, maar dat AdGuard wel werkte.
Dit bevestigt een belangrijk diagnostisch principe: de container hoeft het LAN-adres van de host niet in de installatiewizard te tonen om DNS-verzoeken van LAN-clients te kunnen beantwoorden. Belangrijk is of de gepubliceerde DNS- en webpoorten vanaf het netwerk bereikbaar zijn.
De ZimaOS-host zelf had een geldige statische netwerkconfiguratie
Voor DNS-containers zijn de juiste poorten belangrijker dan een correct ogend adres in de wizard
AdGuard Home en Pi-hole zijn netwerkgevoeliger dan een gewone webapplicatie, omdat clients DNS moeten kunnen bereiken via poort 53, meestal zowel via UDP als TCP. De beheerinterface gebruikt afzonderlijke webpoorten.
Als een DNS-app als gezond wordt gemarkeerd maar LAN-clients hem niet kunnen gebruiken, controleer dan de daadwerkelijk gepubliceerde poorten en of een andere service poort 53 al gebruikt voordat je het statische IP-adres van de host wijzigt.
Het feit dat Jellyfin werkte, hielp een volledige Docker- of opslagfout uitsluiten
De gebruiker gaf aan dat Jellyfin uiteindelijk werkte. Dat bewees niet dat de netwerkconfiguratie van AdGuard correct was, maar liet wel zien dat ZimaOS Docker-applicaties kon uitvoeren en op dezelfde installatie toegang had tot mediaopslag. De probleemoplossing kon zich daardoor richten op applicatiespecifieke netwerkconfiguratie, in plaats van de volledige containerstack als onbruikbaar te beschouwen.
De Time Machine-fout volgde de MacBook naar TrueNAS
De belangrijkste correctie in de thread kwam de volgende dag. De gebruiker wiste ZimaOS, installeerde het opnieuw en testte Time Machine nogmaals. De oudere Mac mini met Monterey maakte succesvol een reservekopie, terwijl de nieuwere MacBook nog steeds faalde.
Daarna probeerde de gebruiker een Time Machine-share op TrueNAS, maar ook daar faalde de MacBook. Deze vergelijking verschoof de waarschijnlijke oorzaak van ZimaOS naar de MacBook of het macOS-/SMB-gedrag daarvan.
Waarom testen met een andere NAS zo waardevol is
Als dezelfde client faalt tegen twee onafhankelijke NAS-platforms terwijl een andere Mac wel werkt met het ZimaOS-doel, ondersteunt het bewijs niet langer de conclusie dat “Time Machine op ZimaOS defect is” als eenvoudigste verklaring.
Dit is een nuttige algemene regel bij het oplossen van NAS-problemen: verander telkens één kant van de verbinding. Een tweede server of tweede client kan snel laten zien of de fout de server, de client of een specifieke combinatie volgt.
Beoordeel het huidige ZimaOS met de huidige opslag- en app-instellingen
De bronthread weerspiegelt ZimaOS in mei 2026. Sindsdien is het platform blijven veranderen, onder meer op het gebied van appconfiguratie, YAML-bewerking, opslagbeheer en back-upgedrag. Begin bij een nieuwe installatie met het huidige model voor ZimaOS-functies en opslag in plaats van ervan uit te gaan dat elk App Store-sjabloon uit 2026 ongewijzigd is gebleven.
Een betere testvolgorde voor een nieuwe installatie
- Stel de opslag en de locatie van appgegevens in voordat je veel apps installeert.
- Controleer één eenvoudige app, zoals Jellyfin of een andere webservice.
- Controleer bij DNS-apps poort 53 afzonderlijk van de webinterface.
- Schakel pas over op hostnetwerken nadat je de bestaande bridge- en poortkoppeling begrijpt.
- Test voor Time Machine indien mogelijk een andere Mac of een ander SMB-doel voor Time Machine.
- Beschouw een component pas als de waarschijnlijke hoofdoorzaak nadat de fout die component volgt.
Veelgestelde vragen over probleemoplossing bij een nieuwe ZimaOS-installatie
Werkte AdGuard Home uiteindelijk voor de gebruiker uit de bron?
Ja. De gebruiker gaf aan dat de Network-appvariant in combinatie met aanvullende poortconfiguratie werkte.
Toonde de installatiewizard van AdGuard ooit het verwachte adres 192.168.60.x?
Nee, maar de applicatie werkte wel. De wizard toonde interfaces die binnen de container zichtbaar waren.
Was bewezen dat ZimaOS de oorzaak van de Time Machine-fout was?
Nee. De MacBook faalde ook met een Time Machine-share op TrueNAS, terwijl een oudere Mac mini wel werkte met ZimaOS.
