Solución de la comunidad

La carcasa NVMe de ORICO se desconecta de Plex en ZimaOS: suspensión frente a exFAT

A user reported that an ORICO TXM2M NVMe enclosure mounted and worked with Plex but disappeared after roughly ten idle minutes. They attributed the behavior to the enclosure's built-in sleep mode and found ext4 more stable than exFAT, though not a complete fix.

Este consejo de la comunidad describe un fallo muy específico del almacenamiento externo: la unidad NVMe se montaba con normalidad, Plex podía reproducir contenido y, después de aproximadamente diez minutos de inactividad, el montaje desaparecía. Volver a conectar la unidad o montarla manualmente restauraba el acceso.

La lección útil no es simplemente «no uses exFAT». El hilo señala tres capas distintas que pueden producir un síntoma similar en Plex: la suspensión del firmware de la carcasa, la suspensión automática de USB en Linux y el comportamiento de recuperación del sistema de archivos y del montaje.

El error «Archivo no encontrado» de Plex puede originarse fuera de Plex

Plex solo conoce la carpeta de biblioteca que se le indicó. El proceso oficial de creación de bibliotecas de Plex requiere que la carpeta multimedia permanezca accesible para el servidor. Si el puente USB se desconecta y el punto de montaje desaparece, Plex informa de que faltan archivos porque la ruta de almacenamiento subyacente ya no existe.

La guía del centro multimedia NAS resulta útil para la arquitectura normal de Plex en ZimaOS, mientras que los requisitos de hardware de Plex distinguen los requisitos de carga de trabajo del servidor multimedia de los problemas de una carcasa de almacenamiento que se desconecta.

La suspensión de la carcasa y la suspensión automática de Linux son diferentes

El autor original informó de que la propia carcasa ORICO entraba en un estado de «suspensión inteligente» tras un periodo de inactividad. Linux también cuenta con su propia capa independiente de gestión de energía USB. La gestión de energía USB de Linux explica que power/control=auto permite la suspensión automática de USB, mientras que on impide que el kernel inicie la suspensión automática de ese dispositivo.

Por tanto, desactivar la suspensión automática de Linux no garantiza una solución si el firmware de la carcasa aplica su propia política de suspensión total. Úsalo como prueba de aislamiento, no como prueba de que el puente USB funciona correctamente.

Por qué ext4 puede parecer más estable que exFAT

El hilo informó de un mejor comportamiento de recuperación con ext4 que con exFAT, pero no aportó pruebas controladas que demuestren que exFAT provocara la desconexión. Considera el sistema de archivos como una variable más después de comprender el comportamiento del puente USB físico y de la suspensión.

Si la unidad también debe utilizarse con contenedores, el flujo de trabajo para montar unidades externas explica por qué debe existir un punto de montaje estable en el host antes de que una aplicación pueda depender de esa ruta.

Un orden de diagnóstico más seguro

  1. Confirma si desaparece todo el dispositivo USB o si solo Plex pierde la biblioteca.
  2. Comprueba si el punto de montaje sigue existiendo después del periodo de inactividad.
  3. Prueba por separado la suspensión automática de USB de Linux y la suspensión de la carcasa.
  4. Compara ext4 con exFAT solo después de comprender el comportamiento de reactivación del hardware.
  5. Para una biblioteca multimedia siempre activa, prioriza una carcasa que se reactive de forma fiable en Linux.

En resumen

El caso de la comunidad se entiende mejor como un problema de reactivación o reanudación de la carcasa que se manifestó como un fallo de la biblioteca de Plex. Es posible que exFAT hiciera menos fiable la recuperación, pero cambiar de sistema de archivos no puede desactivar la suspensión gestionada por el firmware. Para un servidor multimedia ZimaOS siempre activo, prioriza un puente USB/NVMe que permanezca estable tras periodos de inactividad.