Questo thread di maggio 2026 è iniziato come una prima impressione frustrata dopo una lunga notte trascorsa con ZimaOS. AdGuard Home e Pi-hole sembravano funzionare in reti Docker isolate invece che nella LAN dell'utente 192.168.60.0/24, Jellyfin ha funzionato solo dopo diversi tentativi e i backup di Time Machine da un MacBook Pro non riuscivano. Dopo ulteriori test, tuttavia, due delle conclusioni iniziali sono cambiate: AdGuard Home è stato reso funzionante e il problema di Time Machine si è ripresentato anche su una condivisione TrueNAS, indicando che la causa probabilmente non era ZimaOS.
Il thread è quindi più utile come caso di studio per la risoluzione dei problemi che come giudizio sul sistema operativo. Mostra perché sia necessario isolare il networking Docker, i modelli delle applicazioni e il comportamento dei backup lato client prima di attribuire la colpa alla piattaforma NAS.
La procedura guidata di configurazione di AdGuard mostrava indirizzi Docker invece dell'IP della LAN
Dopo un'installazione standard, la schermata di configurazione di AdGuard Home mostrava indirizzi come 127.0.0.1 e 172.17.0.2. L'utente si aspettava di vedere l'indirizzo LAN statico dell'host ZimaOS, 192.168.60.241.
Il passaggio al networking dell'host non è stato una soluzione pulita
L'utente ha trovato una soluzione alternativa, in stile community, che modificava la modalità di rete di Compose impostandola su host. Dopo aver modificato anche le impostazioni dell'app, l'installazione è diventata irraggiungibile. Questo risultato negativo è importante perché il networking dell'host modifica sia l'assegnazione delle porte sia le ipotesi su cui si basa un modello dell'App Store.
Non considerare network_mode: host una risposta universale per i container DNS. Può essere utile quando l'app ha davvero bisogno di visibilità a livello di rete dell'host, ma può anche creare conflitti di porte con il pannello di controllo di ZimaOS, un altro resolver DNS o un altro container.
Alla fine l'utente è riuscito a far funzionare AdGuard con una variante diversa dell'app
In seguito, l'autore originale ha aggiornato il thread dopo aver trovato istruzioni che utilizzavano la versione Network dell'app AdGuard invece del pacchetto predefinito e aggiungevano le mappature delle porte richieste per l'interfaccia web. Ha riferito che la procedura guidata continuava a non mostrare l'indirizzo 192.168.60.x previsto, ma AdGuard funzionava.
Questo conferma un importante principio diagnostico: il container non deve necessariamente mostrare l'indirizzo LAN dell'host nella procedura guidata per poter rispondere alle richieste DNS dei client della LAN. Ciò che conta è che le porte DNS e web pubblicate siano raggiungibili dalla rete.
L'host ZimaOS aveva una configurazione di rete statica valida
I container DNS hanno bisogno soprattutto delle porte corrette, non di un indirizzo della procedura guidata dall'aspetto giusto
AdGuard Home e Pi-hole sono più sensibili al networking rispetto a una normale applicazione web, perché i client devono raggiungere il DNS sulla porta 53, solitamente sia tramite UDP sia tramite TCP. L'interfaccia di gestione utilizza porte web separate.
Se un'app DNS risulta attiva ma i client della LAN non riescono a utilizzarla, controlla le porte effettivamente pubblicate e verifica se un altro servizio sta già utilizzando la porta 53 prima di modificare l'IP statico dell'host.
Il funzionamento di Jellyfin ha contribuito a escludere un guasto totale di Docker o dello storage
L'utente ha riferito che Jellyfin alla fine funzionava. Questo non dimostrava che il networking di AdGuard fosse corretto, ma indicava che ZimaOS era in grado di eseguire applicazioni Docker e di accedere allo storage multimediale nella stessa installazione. La risoluzione dei problemi poteva quindi concentrarsi sulla configurazione di rete specifica dell'applicazione, invece di considerare inutilizzabile l'intero stack dei container.
Il problema di Time Machine ha seguito il MacBook fino a TrueNAS
La correzione più importante nel thread è arrivata il giorno successivo. L'utente ha cancellato e reinstallato ZimaOS, quindi ha testato nuovamente Time Machine. Il suo vecchio Mac mini con Monterey ha completato il backup correttamente, mentre il MacBook più recente continuava a non riuscirci.
Ha poi provato una condivisione Time Machine su TrueNAS e anche il MacBook ha fallito. Questo test incrociato ha spostato la probabile causa da ZimaOS al MacBook o al comportamento di macOS/SMB.
Perché testare un altro NAS è così utile
Se lo stesso client fallisce con due piattaforme NAS indipendenti mentre un altro Mac funziona con la destinazione ZimaOS, le prove non sostengono più l'ipotesi “Time Machine su ZimaOS è guasto” come spiegazione più semplice.
Questa è una regola generale utile per la risoluzione dei problemi dei NAS: modifica un solo lato della connessione alla volta. Un secondo server o un secondo client può rivelare rapidamente se il problema segue il server, il client o una combinazione specifica.
ZimaOS attuale deve essere valutato con le impostazioni attuali dello storage e delle app
Il thread originale riflette ZimaOS a maggio 2026. Da allora la piattaforma ha continuato a cambiare, inclusi la configurazione delle app, la modifica YAML, la gestione dello storage e il comportamento dei backup. Per una nuova installazione, parti da modello attuale delle funzionalità e dello storage di ZimaOS, invece di presumere che ogni modello dell'App Store del 2026 sia rimasto invariato.
Una sequenza migliore per i test dopo una nuova installazione
- Configura lo storage e la posizione dei dati delle app prima di installare molte applicazioni.
- Verifica un'app semplice, come Jellyfin o un altro servizio web.
- Per le app DNS, verifica la porta 53 separatamente dalla WebUI.
- Non passare al networking dell'host finché non hai compreso il bridge e la mappatura delle porte esistenti.
- Per Time Machine, quando possibile, prova un altro Mac o un'altra destinazione SMB per Time Machine.
- Considera un componente come probabile causa principale solo dopo aver verificato che il problema lo segua.
Domande frequenti sulla risoluzione dei problemi di una nuova installazione di ZimaOS
AdGuard Home alla fine funzionava per l'utente del thread originale?
Sì. L'utente ha riferito che la variante Network dell'app, insieme a una configurazione aggiuntiva delle porte, funzionava.
La procedura guidata di configurazione di AdGuard ha mai mostrato l'indirizzo 192.168.60.x previsto?
No, ma l'applicazione funzionava comunque. La procedura guidata mostrava le interfacce visibili dal container.
È stato dimostrato che ZimaOS fosse la causa del problema di Time Machine?
No. Il MacBook ha fallito anche con una condivisione Time Machine su TrueNAS, mentre un vecchio Mac mini funzionava con ZimaOS.
