Solución de la comunidad

Las aplicaciones Docker de ZimaOS pierden un NAS SMB después de reiniciar: cómo solucionarlo

Plex and Radarr lost access to a Synology SMB share after each reboot until the same ZimaOS folder mapping was manually reselected.

Si Plex, Radarr, Sonarr u otra aplicación de Docker pierde el acceso a un NAS SMB remoto después de cada reinicio de ZimaOS, comprueba el montaje del host antes de modificar la aplicación. El contenedor solo puede ver un recurso compartido de red si ZimaOS lo ha montado correctamente y la ruta de enlace de Docker sigue apuntando a esa ubicación montada.

Un caso de la comunidad relacionado con un recurso compartido de Synology se recuperaba cada vez que el usuario volvía a seleccionar la misma carpeta en el selector de rutas de Docker Compose. Esto sugiere claramente un problema de persistencia del montaje o la ruta, pero la explicación del foro de que ZimaOS siempre generaba un nuevo ID de montaje interno era una deducción de la comunidad, no una causa raíz confirmada por IceWhale. Por lo tanto, una buena guía debe solucionar por separado el montaje, la ruta y el orden de inicio.

Primero confirma si el recurso compartido SMB está montado después de reiniciar

Antes de abrir Plex o Radarr, abre Archivos de ZimaOS y explora el recurso compartido del NAS remoto. Si el propio recurso compartido no está disponible, la aplicación de Docker no es el primer problema.

Si falta el recurso compartido

Comprueba que el NAS remoto esté en línea, que su IP o nombre de host siga resolviéndose, que SMB esté habilitado y que las credenciales guardadas sigan siendo válidas. Vuelve a conectar el recurso compartido mediante el flujo de trabajo de almacenamiento en red de ZimaOS si es necesario.

Si el recurso compartido es visible en Archivos

Después, pasa a la asignación de Docker. El montaje del host existe, pero es posible que la aplicación todavía haga referencia a una ruta obsoleta o no disponible.

Usa el almacenamiento en red de ZimaOS en lugar de una entrada de fstab escrita manualmente

El usuario consideró editar /etc/fstab. Esa no es la mejor solución inicial en un sistema operativo tipo dispositivo que ya gestiona el almacenamiento en red desde su interfaz.

La documentación actual de ZimaOS muestra el acceso basado en SMB a otro NAS como parte de sus flujos de trabajo de migración y almacenamiento en red. Usa primero esa ruta gestionada para que ZimaOS pueda administrar las credenciales y el estado del montaje de forma coherente.

La guía de migración de NAS de ZimaOS proporciona la referencia actual.

Comprueba la ruta del host de Docker, no solo la ruta del contenedor

Las asignaciones de volúmenes de Docker tienen dos lados:

  • ruta del host: dónde ve ZimaOS la carpeta montada de Synology;
  • ruta del contenedor: la ruta estable que Plex, Radarr o Sonarr ve dentro del contenedor.

Si el lado del host no es válido después de reiniciar, la ruta del contenedor puede seguir pareciendo correcta en la interfaz de la aplicación, aunque no apunte a nada útil.

La guía de rutas de Docker de ZimaOS actual explica esta distinción.

Vuelve a seleccionar la carpeta una vez como prueba de diagnóstico

Si el recurso compartido remoto está visible en Archivos, pero la aplicación no puede acceder a él, abre la aplicación o la configuración de Compose y vuelve a seleccionar la carpeta del host mediante el selector de rutas de ZimaOS.

Si el acceso vuelve inmediatamente sin cambiar las credenciales ni las rutas del contenedor, tienes pruebas sólidas de que el fallo está entre el montaje administrado y la asignación de enlace de Docker.

Comprueba el orden de inicio después de cada reinicio

El almacenamiento SMB remoto depende de la red, la accesibilidad mediante DNS/IP, la autenticación y de que el NAS esté listo. Los contenedores de Docker pueden iniciarse más rápido de lo que tarda en estar disponible el montaje remoto.

Prueba sencilla

  1. reinicia ZimaOS;
  2. espera hasta que el recurso compartido remoto se pueda explorar en Archivos;
  3. reinicia solo la aplicación de Docker afectada;
  4. comprueba si vuelven a aparecer los archivos multimedia o las descargas.

Si funciona de forma fiable, es posible que la ruta sea estable y que el problema real sea el momento de inicio, no el cambio de identificadores de montaje.

Comprueba los permisos en ambos sistemas

La cuenta de Synology utilizada para el montaje SMB debe tener acceso a las carpetas multimedia. Después, el montaje de ZimaOS debe ser accesible para el proceso de Docker. Por último, la aplicación debe utilizar la ruta correcta del contenedor.

Los problemas de permisos pueden parecerse a un punto de montaje faltante, así que comprueba por separado «permiso denegado» y «ruta no encontrada» o «el archivo no existe».

Por qué los cambios manuales en fstab pueden dificultar la recuperación

Un montaje personalizado puede introducir archivos de credenciales, dependencias de arranque, opciones de temporización y comportamientos ante fallos que ZimaOS no administra en su interfaz. Si ese montaje personalizado falla durante el arranque, las aplicaciones aún pueden iniciarse utilizando un directorio vacío.

Usa fstab solo cuando el flujo de trabajo de almacenamiento de red administrado no pueda satisfacer un requisito y estés preparado para mantener el montaje durante las actualizaciones.

Cómo hacer que las aplicaciones multimedia sean más resistentes

  • Usa una IP estable del NAS o un nombre DNS local fiable.
  • Mantén el recurso compartido remoto configurado mediante Almacenamiento de red.
  • Asigna una carpeta de host estable al contenedor.
  • Usa la misma ruta de contenedor de forma coherente en Radarr, Sonarr, los clientes de descarga y los servidores multimedia.
  • Después de actualizar o cambiar el almacenamiento, verifica el montaje antes de cambiar las bibliotecas de las aplicaciones.

La guía de solución de problemas de LAN ayuda a determinar si el fallo comienza en la capa de red, mientras que los fundamentos de las rutas de Docker proporcionan el contexto de Docker.

Preguntas frecuentes

¿Por qué mis aplicaciones Docker pierden un recurso compartido de Synology después de que ZimaOS se reinicia?

Las capas más probables son que el recurso compartido SMB no se vuelva a montar, que la aplicación utilice una ruta de host obsoleta o que el contenedor se inicie antes de que el recurso compartido remoto esté listo. Prueba cada una por separado.

¿Debo editar /etc/fstab?

No como primera solución. Prefiere Almacenamiento de red de ZimaOS para que el sistema administre el recurso compartido. Los montajes manuales añaden mantenimiento y complejidad en el orden de arranque.

¿Por qué volver a seleccionar la misma carpeta soluciona el problema de la aplicación?

Actualiza la asignación de enlaces del lado del host. Esto demuestra que existe un problema de montaje o de rutas, incluso cuando el nombre visible de la carpeta no ha cambiado.

¿Puedo usar un recurso compartido SMB remoto para Plex y las aplicaciones de Arr?

Sí, siempre que ZimaOS lo monte de forma fiable, los permisos sean correctos y todos los contenedores utilicen rutas de host y de contenedor coherentes.