Dieser im Mai 2026 gestartete Thread begann als frustrierter erster Eindruck nach einer langen Nacht mit ZimaOS. AdGuard Home und Pi-hole schienen in isolierten Docker-Netzwerken statt im LAN des Benutzers (192.168.60.0/24) zu laufen, Jellyfin funktionierte erst nach mehreren Versuchen, und Time-Machine-Backups von einem MacBook Pro schlugen fehl. Nach weiteren Tests änderten sich jedoch zwei der ursprünglichen Schlussfolgerungen: AdGuard Home konnte funktionsfähig eingerichtet werden, und das Time-Machine-Problem folgte dem MacBook zu einer TrueNAS-Freigabe, was gegen ZimaOS als Ursache sprach.
Der Thread eignet sich daher eher als Fallstudie zur Fehlerbehebung denn als Urteil über das Betriebssystem. Er zeigt, warum Docker-Netzwerke, Anwendungsvorlagen und clientseitiges Backup-Verhalten getrennt untersucht werden müssen, bevor man die NAS-Plattform selbst verantwortlich macht.
Der Einrichtungsassistent von AdGuard zeigte Docker-Adressen statt der LAN-IP
Nach einer Standardinstallation zeigte der Einrichtungsbildschirm von AdGuard Home Adressen wie 127.0.0.1 und 172.17.0.2. Der Benutzer erwartete stattdessen die statische LAN-Adresse des ZimaOS-Hosts: 192.168.60.241.
Der Wechsel zum Host-Netzwerk war keine saubere Lösung
Der Benutzer fand eine Workaround-Anleitung aus der Community, die den Compose-Netzwerkmodus auf host änderte. Nachdem zusätzlich die App-Einstellungen geändert worden waren, war die Installation nicht mehr erreichbar. Dieses negative Ergebnis ist relevant, weil das Host-Netzwerk sowohl die Portzuordnung als auch die Annahmen einer App-Store-Vorlage verändert.
Betrachte network_mode: host nicht als universelle Lösung für DNS-Container. Es kann sinnvoll sein, wenn die App tatsächlich Sichtbarkeit auf Netzwerkebene des Hosts benötigt, kann aber auch zu Portkonflikten mit dem ZimaOS-Dashboard, einem anderen DNS-Resolver oder einem anderen Container führen.
Der Benutzer bekam AdGuard schließlich mit einer anderen App-Variante zum Laufen
Der ursprüngliche Verfasser aktualisierte den Thread später, nachdem er Anweisungen gefunden hatte, die statt des Standardpakets die AdGuard-App-Variante Network verwendeten und die erforderlichen Portweiterleitungen für die Weboberfläche hinzufügten. Er berichtete, dass der Einrichtungsassistent weiterhin nicht die erwartete Adresse 192.168.60.x anzeigte, AdGuard jedoch funktionierte.
Dies bestätigt ein wichtiges Diagnoseprinzip: Der Container muss die LAN-Adresse des Hosts in seinem Einrichtungsassistenten nicht anzeigen, damit er DNS-Anfragen von LAN-Clients beantworten kann. Entscheidend ist, ob die veröffentlichten DNS- und Web-Ports aus dem Netzwerk erreichbar sind.
Der ZimaOS-Host selbst verfügte über eine gültige statische Netzwerkkonfiguration
Bei DNS-Containern sind die richtigen Ports wichtiger als eine korrekt aussehende Adresse im Assistenten
AdGuard Home und Pi-hole reagieren empfindlicher auf die Netzwerkkonfiguration als gewöhnliche Webanwendungen, da Clients DNS normalerweise sowohl über UDP als auch über TCP auf Port 53 erreichen müssen. Die Verwaltungsoberfläche verwendet separate Web-Ports.
Wenn eine DNS-App als fehlerfrei angezeigt wird, LAN-Clients sie aber nicht verwenden können, überprüfe die tatsächlich veröffentlichten Ports und ob ein anderer Dienst bereits Port 53 belegt, bevor du die statische IP-Adresse des Hosts änderst.
Dass Jellyfin funktionierte, sprach gegen einen vollständigen Docker- oder Speicherausfall
Der Benutzer berichtete, dass Jellyfin schließlich funktionierte. Das bewies zwar nicht, dass die Netzwerkkonfiguration von AdGuard korrekt war, zeigte aber, dass ZimaOS Docker-Anwendungen ausführen und auf den Medienspeicher derselben Installation zugreifen konnte. Die Fehlerbehebung konnte sich daher auf die anwendungsspezifische Netzwerkkonfiguration konzentrieren, statt den gesamten Container-Stack als unbrauchbar zu betrachten.
Der Time-Machine-Fehler folgte dem MacBook zu TrueNAS
Die wichtigste Korrektur im Thread kam am nächsten Tag. Der Benutzer löschte ZimaOS, installierte es neu und testete Time Machine erneut. Sein älterer Mac mini mit Monterey wurde erfolgreich gesichert, während das neuere MacBook weiterhin fehlschlug.
Anschließend testete er eine Time-Machine-Freigabe auf TrueNAS, und auch dort schlug das MacBook fehl. Dieser Vergleich verlagerte die wahrscheinliche Ursache von ZimaOS auf das MacBook oder dessen Verhalten mit macOS/SMB.
Warum der Vergleich mit einem anderen NAS so wertvoll ist
Wenn derselbe Client bei zwei unabhängigen NAS-Plattformen fehlschlägt, während ein anderer Mac das ZimaOS-Ziel erfolgreich verwendet, sprechen die Belege nicht mehr dafür, dass „ZimaOS Time Machine defekt“ die einfachste Erklärung ist.
Das ist eine nützliche allgemeine Regel bei der NAS-Fehlerbehebung: Ändere jeweils nur eine Seite der Verbindung. Ein zweiter Server oder ein zweiter Client kann schnell zeigen, ob der Fehler dem Server, dem Client oder einer bestimmten Kombination folgt.
Aktuelles ZimaOS sollte mit aktuellen Speicher- und App-Einstellungen bewertet werden
Der Quellthread beschreibt ZimaOS im Mai 2026. Die Plattform wurde seitdem weiterentwickelt, unter anderem bei App-Konfiguration, YAML-Bearbeitung, Speicherverwaltung und Backup-Verhalten. Beginne bei einer neuen Installation mit dem aktuellen ZimaOS-Modell für Funktionen und Speicher, statt davon auszugehen, dass jede App-Store-Vorlage aus dem Jahr 2026 unverändert ist.
Eine bessere Testsequenz für eine Neuinstallation
- Richte den Speicher und den Speicherort für App-Daten ein, bevor du viele Apps installierst.
- Überprüfe zunächst eine einfache App wie Jellyfin oder einen anderen Webdienst.
- Prüfe bei DNS-Apps Port 53 getrennt von der Weboberfläche.
- Wechsle nicht zum Host-Netzwerk, bevor du die bestehende Bridge-Konfiguration und die Portzuordnung verstanden hast.
- Teste für Time Machine nach Möglichkeit einen anderen Mac oder ein anderes SMB-Time-Machine-Ziel.
- Erst wenn der Fehler einer bestimmten Komponente folgt, solltest du diese Komponente als wahrscheinlichste Ursache betrachten.
Häufig gestellte Fragen zur Fehlerbehebung bei einer neuen ZimaOS-Installation
Funktionierte AdGuard Home für den Benutzer am Ende?
Ja. Der Benutzer berichtete, dass die Network-App-Variante zusammen mit einer zusätzlichen Portkonfiguration funktionierte.
Zeigte der Einrichtungsassistent von AdGuard jemals die erwartete Adresse 192.168.60.x an?
Nein, die Anwendung funktionierte jedoch trotzdem. Der Assistent zeigte die innerhalb des Containers sichtbaren Schnittstellen.
Wurde nachgewiesen, dass ZimaOS die Ursache des Time-Machine-Fehlers war?
Nein. Das MacBook schlug auch bei einer Time-Machine-Freigabe auf TrueNAS fehl, während ein älterer Mac mini ZimaOS erfolgreich verwenden konnte.
