Ten wątek z maja 2026 roku rozpoczął się jako pełna frustracji relacja z pierwszych wrażeń po jednej długiej nocy spędzonej z ZimaOS. AdGuard Home i Pi-hole wydawały się działać w odizolowanych sieciach Dockera zamiast w sieci LAN użytkownika 192.168.60.0/24, Jellyfin działał dopiero po kilku próbach, a kopie zapasowe Time Machine z MacBooka Pro kończyły się niepowodzeniem. Po dalszych testach dwa pierwotne wnioski uległy jednak zmianie: udało się uruchomić AdGuard Home, a problem z Time Machine występował również przy udziale MacBooka w połączeniu z udziałem TrueNAS, co wskazywało, że jego przyczyną raczej nie był ZimaOS.
Wątek jest więc bardziej przydatny jako analiza przypadku diagnostycznego niż jako jednoznaczna ocena systemu operacyjnego. Pokazuje, dlaczego przed obwinieniem samej platformy NAS należy osobno przeanalizować sieci Dockera, szablony aplikacji i zachowanie kopii zapasowych po stronie klienta.
Kreator konfiguracji AdGuard wyświetlał adresy Dockera zamiast adresu LAN
Po standardowej instalacji ekran konfiguracji AdGuard Home wyświetlał adresy takie jak 127.0.0.1 i 172.17.0.2. Użytkownik oczekiwał adresu statycznego interfejsu LAN hosta ZimaOS, czyli 192.168.60.241.
Przejście na sieć hosta nie było prostym rozwiązaniem
Użytkownik znalazł obejście stosowane w społeczności, które zmieniało tryb sieci Compose na host. Po dodatkowej zmianie ustawień aplikacji instalacja stała się niedostępna. Ten negatywny rezultat jest istotny, ponieważ sieć hosta zmienia zarówno sposób zajmowania portów, jak i założenia przyjęte przez szablon aplikacji w App Store.
Nie należy traktować network_mode: host jako uniwersalnej odpowiedzi w przypadku kontenerów DNS. Może być przydatny, gdy aplikacja rzeczywiście wymaga widoczności sieci na poziomie hosta, ale może też powodować konflikty portów z panelem ZimaOS, innym resolverem DNS lub innym kontenerem.
Użytkownik ostatecznie uruchomił AdGuard, korzystając z innego wariantu aplikacji
Autor wpisu później zaktualizował wątek po znalezieniu instrukcji, które wykorzystywały wersję aplikacji AdGuard oznaczoną jako Network, a nie pakiet domyślny, oraz dodawały wymagane mapowania portów interfejsu WWW. Użytkownik poinformował, że kreator konfiguracji nadal nie wyświetlał oczekiwanego adresu 192.168.60.x, ale AdGuard działał.
Potwierdza to ważną zasadę diagnostyczną: kontener nie musi wyświetlać w kreatorze konfiguracji adresu LAN hosta, aby odpowiadać na zapytania DNS klientów w sieci LAN. Liczy się to, czy opublikowane porty DNS i WWW są dostępne z sieci.
Sam host ZimaOS miał prawidłową statyczną konfigurację sieci
Kontenery DNS potrzebują prawidłowych portów bardziej niż adresu poprawnie wyglądającego w kreatorze
AdGuard Home i Pi-hole są bardziej wrażliwe na konfigurację sieci niż zwykła aplikacja internetowa, ponieważ klienci muszą mieć dostęp do DNS na porcie 53, zazwyczaj zarówno przez UDP, jak i TCP. Panel administracyjny używa oddzielnych portów WWW.
Jeśli aplikacja DNS ma status „działa”, ale klienci w sieci LAN nie mogą z niej korzystać, sprawdź rzeczywiście opublikowane porty oraz to, czy inna usługa nie zajmuje już portu 53, zanim zmienisz statyczny adres IP hosta.
Działający Jellyfin pomógł wykluczyć całkowitą awarię Dockera lub pamięci masowej
Użytkownik poinformował, że Jellyfin ostatecznie działał. Nie dowodziło to poprawności konfiguracji sieci AdGuard, ale pokazywało, że ZimaOS potrafił uruchamiać aplikacje Dockera i uzyskiwać dostęp do pamięci masowej z multimediami w ramach tej samej instalacji. Diagnostykę można było więc skoncentrować na konfiguracji sieci konkretnej aplikacji, zamiast uznawać cały stos kontenerów za niesprawny.
Awaria Time Machine występowała również na MacBooku przy użyciu TrueNAS
Najważniejsza korekta w wątku pojawiła się następnego dnia. Użytkownik wymazał system, ponownie zainstalował ZimaOS, a następnie jeszcze raz przetestował Time Machine. Starszy Mac mini z Monterey wykonał kopię zapasową pomyślnie, podczas gdy nowszy MacBook nadal kończył operację niepowodzeniem.
Następnie użytkownik wypróbował udział Time Machine w TrueNAS, ale MacBook również tam nie działał. Ten test porównawczy przesunął prawdopodobną przyczynę z ZimaOS na MacBooka lub sposób obsługi macOS/SMB.
Dlaczego testowanie z innym serwerem NAS jest tak wartościowe
Jeśli ten sam klient nie działa z dwiema niezależnymi platformami NAS, podczas gdy inny Mac działa z urządzeniem docelowym ZimaOS, dowody nie potwierdzają już tezy, że najprostszym wyjaśnieniem jest „zepsuty Time Machine w ZimaOS”.
To przydatna ogólna zasada diagnostyki NAS: zmieniaj za każdym razem tylko jedną stronę połączenia. Drugi serwer lub drugi klient może szybko ujawnić, czy problem podąża za serwerem, klientem czy konkretną kombinacją obu.
Obecny ZimaOS należy oceniać z użyciem aktualnych ustawień pamięci masowej i aplikacji
Źródłowy wątek opisuje ZimaOS z maja 2026 roku. Od tego czasu platforma nadal się zmieniała, między innymi w zakresie konfiguracji aplikacji, edycji YAML, zarządzania pamięcią masową i działania kopii zapasowych. W przypadku nowej instalacji zacznij od aktualnego modelu funkcji i pamięci masowej ZimaOS, zamiast zakładać, że każdy szablon App Store z 2026 roku pozostał niezmieniony.
Lepsza sekwencja testów po świeżej instalacji
- Skonfiguruj pamięć masową i lokalizację danych aplikacji przed zainstalowaniem wielu aplikacji.
- Sprawdź jedną prostą aplikację, taką jak Jellyfin lub inna usługa WWW.
- W przypadku aplikacji DNS sprawdź port 53 osobno od panelu WWW.
- Nie przełączaj się na sieć hosta, dopóki nie zrozumiesz istniejącego trybu bridge i mapowania portów.
- W przypadku Time Machine, jeśli to możliwe, przetestuj innego Maca lub inny udział SMB przeznaczony dla Time Machine.
- Dopiero gdy problem podąża za jednym z komponentów, uznaj ten komponent za prawdopodobne źródło problemu.
Często zadawane pytania dotyczące diagnostyki świeżej instalacji ZimaOS
Czy AdGuard Home ostatecznie działał u autora źródłowego wpisu?
Tak. Użytkownik poinformował, że wariant aplikacji Network wraz z dodatkową konfiguracją portów działał.
Czy kreator konfiguracji AdGuard kiedykolwiek wyświetlił oczekiwany adres 192.168.60.x?
Nie, ale aplikacja nadal działała. Kreator wyświetlał interfejsy widoczne z poziomu kontenera.
Czy udowodniono, że przyczyną awarii Time Machine był ZimaOS?
Nie. MacBook również nie działał z udziałem Time Machine w TrueNAS, podczas gdy starszy Mac mini działał z ZimaOS.
