Den här tråden från maj 2026 började som ett frustrerat första intryck efter en lång natt med ZimaOS. AdGuard Home och Pi-hole verkade köras i isolerade Docker-nätverk i stället för i användarens 192.168.60.0/24-LAN, Jellyfin fungerade först efter flera försök och Time Machine-säkerhetskopieringar från en MacBook Pro misslyckades. Efter ytterligare tester ändrades dock två av de ursprungliga slutsatserna: AdGuard Home kunde fås att fungera, och Time Machine-problemet följde med MacBook-datorn till en TrueNAS-resurs, vilket talade emot att ZimaOS var orsaken.
Tråden är därför mer användbar som en fallstudie i felsökning än som ett omdöme om operativsystemet. Den visar varför Docker-nätverk, appmallar och klientens säkerhetskopieringsbeteende måste isoleras innan man skyller på själva NAS-plattformen.
AdGuards installationsguide visade Docker-adresser i stället för LAN-IP-adressen
Efter en standardinstallation visade användarens installationsskärm för AdGuard Home adresser som 127.0.0.1 och 172.17.0.2. Användaren förväntade sig att se ZimaOS-värdens statiska LAN-adress, 192.168.60.241.
Att byta till värdnätverk var ingen problemfri lösning
Användaren hittade en lösning från communityn som ändrade Compose-nätverksläget till host. Efter att även ha ändrat appinställningarna blev installationen otillgänglig. Det negativa resultatet är viktigt, eftersom värdnätverk ändrar både portägarskap och de antaganden som görs av en App Store-mall.
Betrakta inte network_mode: host som ett universellt svar för DNS-containrar. Det kan vara användbart när appen verkligen behöver insyn i värdens nätverk, men det kan också skapa portkonflikter med ZimaOS-instrumentpanelen, en annan DNS-resolver eller en annan container.
Användaren fick till slut AdGuard att fungera med en annan appvariant
Den ursprungliga trådskaparen uppdaterade senare tråden efter att ha hittat instruktioner som använde Network-versionen av AdGuard-appen i stället för standardpaketet och lade till de portmappningar som krävdes för webbgränssnittet. De uppgav att installationsassistenten fortfarande inte visade den förväntade adressen 192.168.60.x, men att AdGuard fungerade.
Det bekräftar en viktig diagnostisk princip: containern behöver inte visa värdens LAN-adress i installationsguiden för att kunna besvara DNS-förfrågningar från LAN-klienter. Det viktiga är om de publicerade DNS- och webbportarna kan nås från nätverket.
ZimaOS-värden hade själv en giltig statisk nätverkskonfiguration
DNS-containrar behöver rätt portar mer än en adress i installationsguiden som ser korrekt ut
AdGuard Home och Pi-hole är känsligare för nätverkskonfiguration än vanliga webbappar, eftersom klienterna behöver nå DNS på port 53, vanligtvis via både UDP och TCP. Administrationsgränssnittet använder separata webbportar.
Om en DNS-app är markerad som frisk men LAN-klienter inte kan använda den bör du kontrollera de faktiska publicerade portarna och om en annan tjänst redan använder port 53 innan du ändrar värdens statiska IP-adress.
Att Jellyfin fungerade bidrog till att utesluta ett totalt fel i Docker eller lagringen
Användaren uppgav att Jellyfin till slut fungerade. Det bevisade inte att AdGuards nätverk var korrekt, men visade att ZimaOS kunde köra Docker-appar och komma åt medielagring i samma installation. Felsökningen kunde därför fokusera på appspecifik nätverkskonfiguration i stället för att betrakta hela containerstacken som obrukbar.
Time Machine-felet följde med MacBook-datorn till TrueNAS
Den viktigaste korrigeringen i tråden kom nästa dag. Användaren raderade och installerade om ZimaOS och testade sedan Time Machine igen. Den äldre Mac mini-datorn med Monterey säkerhetskopierades utan problem, medan den nyare MacBook-datorn fortfarande misslyckades.
Därefter provade användaren en TrueNAS-resurs för Time Machine, och även där misslyckades MacBook-datorn. Detta flyttade den sannolika orsaken från ZimaOS till MacBook-datorn eller dess macOS-/SMB-beteende.
Varför det är så värdefullt att kors testa med en annan NAS
Om samma klient misslyckas mot två oberoende NAS-plattformar medan en annan Mac fungerar mot ZimaOS-målet, stöder bevisen inte längre påståendet att ”ZimaOS Time Machine är trasigt” som den enklaste förklaringen.
Detta är en användbar generell regel vid NAS-felsökning: ändra en sida av anslutningen i taget. En andra server eller en andra klient kan snabbt visa om felet följer servern, klienten eller en specifik kombination.
Aktuella ZimaOS bör utvärderas med aktuella lagrings- och appinställningar
Källtråden beskriver ZimaOS i maj 2026. Plattformen har fortsatt att förändras sedan dess, bland annat när det gäller appkonfiguration, YAML-redigering, lagringshantering och säkerhetskopieringsbeteende. För en ny installation bör du utgå från den aktuella modellen för ZimaOS-funktioner och lagring i stället för att anta att alla App Store-mallar från 2026 är oförändrade.
En bättre testsekvens för en ny installation
- Konfigurera lagring och plats för appdata innan du installerar många appar.
- Verifiera en enkel app, till exempel Jellyfin eller en annan webbtjänst.
- För DNS-appar: verifiera port 53 separat från webbgränssnittet.
- Byt inte till värdnätverk förrän den befintliga bryggan och portmappningen är förstådda.
- För Time Machine: testa om möjligt en annan Mac eller ett annat SMB-mål för Time Machine.
- Först när felet följer en viss komponent bör du betrakta den komponenten som den sannolika grundorsaken.
Vanliga frågor om felsökning av en ny ZimaOS-installation
Fungerade AdGuard Home till slut för användaren i källan?
Ja. Användaren uppgav att Network-appvarianten tillsammans med ytterligare portkonfiguration fungerade.
Visade installationsguiden för AdGuard någonsin den förväntade adressen 192.168.60.x?
Nej, men appen fungerade ändå. Guiden visade gränssnitt som var synliga inifrån containern.
Bevisades det att ZimaOS orsakade Time Machine-felet?
Nej. MacBook-datorn misslyckades även mot en TrueNAS-resurs för Time Machine, medan en äldre Mac mini fungerade mot ZimaOS.
