Este hilo de mayo de 2026 comenzó como una primera impresión frustrante después de una larga noche con ZimaOS. AdGuard Home y Pi-hole parecían ejecutarse en redes Docker aisladas en lugar de la LAN del usuario, 192.168.60.0/24; Jellyfin solo funcionó después de varios intentos, y las copias de seguridad de Time Machine desde un MacBook Pro fallaban. Sin embargo, después de realizar más pruebas, dos de las conclusiones originales cambiaron: AdGuard Home comenzó a funcionar y el problema de Time Machine también se reprodujo en un recurso compartido de TrueNAS, lo que apuntaba en otra dirección y alejaba la responsabilidad de ZimaOS.
Por tanto, el hilo resulta más útil como caso práctico de resolución de problemas que como veredicto sobre el sistema operativo. Muestra por qué es necesario aislar las redes de Docker, las plantillas de aplicaciones y el comportamiento de las copias de seguridad en el cliente antes de culpar a la plataforma NAS.
El asistente de configuración de AdGuard mostraba direcciones de Docker en lugar de la IP de la LAN
Tras una instalación estándar, la pantalla de configuración de AdGuard Home del usuario mostraba direcciones como 127.0.0.1 y 172.17.0.2. El usuario esperaba ver la dirección LAN estática del host de ZimaOS, 192.168.60.241.
Cambiar a la red del host no fue una solución limpia
El usuario encontró una solución alternativa, al estilo de las de la comunidad, que cambiaba el modo de red de Compose a host. Después de modificar también la configuración de la aplicación, la instalación dejó de ser accesible. Este resultado negativo es importante porque la red del host cambia tanto la asignación de puertos como las suposiciones de una plantilla de la tienda de aplicaciones.
No consideres network_mode: host una solución universal para los contenedores DNS. Puede ser útil cuando la aplicación realmente necesita visibilidad de la red a nivel del host, pero también puede crear conflictos de puertos con el panel de ZimaOS, otro resolvedor DNS u otro contenedor.
Con el tiempo, el usuario consiguió que AdGuard funcionara con una variante de aplicación diferente
Más tarde, el autor original actualizó el hilo después de encontrar unas instrucciones que utilizaban la versión Network de la aplicación de AdGuard en lugar del paquete predeterminado y añadían las asignaciones de puertos necesarias para la interfaz web. Indicó que el asistente de configuración seguía sin mostrar la dirección 192.168.60.x esperada, pero AdGuard funcionaba.
Esto confirma un principio de diagnóstico importante: el contenedor no necesita mostrar la dirección LAN del host en su asistente de configuración para responder a las solicitudes DNS de los clientes de la LAN. Lo importante es que los puertos DNS y web publicados sean accesibles desde la red.
El propio host de ZimaOS tenía una configuración de red estática válida
Los contenedores DNS necesitan los puertos correctos más que una dirección de asistente que parezca correcta
AdGuard Home y Pi-hole son más sensibles a la red que una aplicación web normal porque los clientes deben poder acceder al DNS en el puerto 53, normalmente tanto mediante UDP como mediante TCP. La interfaz de administración utiliza puertos web independientes.
Si una aplicación DNS aparece como saludable, pero los clientes de la LAN no pueden utilizarla, comprueba los puertos publicados reales y si otro servicio ya está ocupando el puerto 53 antes de cambiar la IP estática del host.
Que Jellyfin funcionara ayudó a descartar un fallo total de Docker o del almacenamiento
El usuario indicó que Jellyfin terminó funcionando. Esto no demostraba que la red de AdGuard fuera correcta, pero sí mostraba que ZimaOS podía ejecutar aplicaciones Docker y acceder al almacenamiento multimedia en la misma instalación. Por tanto, la resolución del problema podía centrarse en la configuración de red específica de la aplicación en lugar de considerar inutilizable toda la pila de contenedores.
El fallo de Time Machine siguió al MacBook hasta TrueNAS
La corrección más importante del hilo llegó al día siguiente. El usuario borró y reinstaló ZimaOS y volvió a probar Time Machine. Su Mac mini antiguo con Monterey realizó la copia correctamente, mientras que el MacBook más nuevo seguía fallando.
Después probó un recurso compartido de Time Machine en TrueNAS y el MacBook también falló allí. Esta prueba cruzada desplazó la causa probable de ZimaOS al MacBook o al comportamiento de macOS/SMB.
Por qué es tan valioso probar otro NAS
Si el mismo cliente falla con dos plataformas NAS independientes mientras otro Mac funciona con el destino de ZimaOS, las pruebas ya no respaldan la idea de que «Time Machine de ZimaOS está averiado» sea la explicación más sencilla.
Esta es una regla general útil para resolver problemas de NAS: cambia un solo lado de la conexión cada vez. Un segundo servidor o un segundo cliente puede revelar rápidamente si el fallo sigue al servidor, al cliente o a una combinación específica.
ZimaOS actual debe evaluarse con la configuración actual de almacenamiento y aplicaciones
El hilo original refleja el estado de ZimaOS en mayo de 2026. Desde entonces, la plataforma ha seguido cambiando, incluida la configuración de aplicaciones, la edición de YAML, la gestión del almacenamiento y el comportamiento de las copias de seguridad. En una instalación nueva, empieza por el modelo actual de funciones y almacenamiento de ZimaOS en lugar de asumir que todas las plantillas de la tienda de aplicaciones de 2026 siguen sin cambios.
Una mejor secuencia de pruebas para una instalación nueva
- Configura el almacenamiento y la ubicación de los datos de las aplicaciones antes de instalar muchas aplicaciones.
- Verifica una aplicación sencilla, como Jellyfin u otro servicio web.
- En las aplicaciones DNS, verifica el puerto 53 por separado de la interfaz web.
- No cambies a la red del host hasta comprender la asignación de puertos y la red puente existentes.
- Para Time Machine, prueba otro Mac u otro destino SMB de Time Machine cuando sea posible.
- Solo cuando el fallo siga a un componente concreto debes considerarlo la causa raíz probable.
Preguntas frecuentes sobre la resolución de problemas en una instalación nueva de ZimaOS
¿AdGuard Home terminó funcionando para el usuario original?
Sí. El usuario indicó que la variante de la aplicación Network, junto con una configuración adicional de puertos, funcionó.
¿El asistente de configuración de AdGuard llegó a mostrar la dirección 192.168.60.x esperada?
No, pero la aplicación siguió funcionando. El asistente mostraba las interfaces visibles para el contenedor.
¿Se demostró que ZimaOS era la causa del fallo de Time Machine?
No. El MacBook también falló con un recurso compartido de Time Machine en TrueNAS, mientras que un Mac mini antiguo funcionó con ZimaOS.
