¿Qué hace que un contenedor LXC pierda el acceso a los dispositivos después de reiniciar el host?
Un contenedor LXC suele perder el acceso a un dispositivo después de reiniciar el host porque este vuelve a crear el dispositivo con una ruta, un estado de permisos o un momento de inicio diferentes.
Trata el reinicio como un evento del ciclo de vida del dispositivo en el host. Confirma que el hardware se detecte antes de que se inicie LXC, compara los identificadores estables con los nombres de dispositivo volátiles, verifica los permisos persistentes de udev y las reglas de acceso del contenedor, y después repite un arranque en frío. Que reiniciar el contenedor solucione temporalmente el problema es una señal de un problema de sincronización, no una reparación duradera.
Confirma que el host vuelve a crear el dispositivo después de reiniciar
Antes de iniciar el contenedor, verifica que el host detecte el dispositivo USB, serie, GPU u otro dispositivo, y registra su ID de proveedor, ID de producto, número de serie, números mayor-menor y ruta actual.
Las recomendaciones para el passthrough en laboratorios domésticos sugieren usar passthrough USB estable en lugar de asumir que un nombre de dispositivo volátil siempre hará referencia al mismo hardware después de la enumeración.
Si el propio host no ve el dispositivo, detente en la capa del host. Debes solucionar los problemas de reconexión, firmware, controlador, alimentación o detección del kernel antes de que cualquier configuración de LXC pueda funcionar.
Sustituye los nombres de dispositivo volátiles por una identidad estable
Compara las rutas anteriores y posteriores al reinicio. Los adaptadores serie USB pueden intercambiar los números ttyUSB y los dispositivos similares pueden enumerarse en un orden diferente después del inicio del host.
Una guía específica sobre el passthrough USB en LXC muestra por qué pasar un dispositivo a LXC solo funciona cuando el objeto del host al que hace referencia el contenedor sigue identificando el hardware previsto.
Usa una ruta estable by-id o un enlace simbólico creado deliberadamente mediante udev cuando la clase del dispositivo lo permita. No amplíes el acceso del contenedor a todos los dispositivos USB solo para ocultar los cambios de enumeración.
Haz que los permisos del dispositivo sobrevivan a su recreación
Comprueba el propietario, el grupo, el modo, los permisos de cgroup y la asignación del contenedor después de reiniciar. Un chmod manual en un nodo de dispositivo no es persistente porque udev puede volver a crear ese nodo.
Un ejemplo de passthrough de Z-Wave utiliza una asignación persistente del dispositivo para mantener accesible un dispositivo serie después de cambios en el host, en lugar de depender de una modificación de permisos realizada una sola vez.
Define la regla de propietario o grupo necesaria en la configuración persistente de administración de dispositivos del host y concede al contenedor únicamente la clase de dispositivo que necesita.
Comprueba si el contenedor se inicia demasiado pronto
Reinicia el host y compara las marcas de tiempo de creación del dispositivo y de inicio de LXC. Un contenedor puede iniciarse correctamente mientras el hardware que espera aún no ha terminado de enumerarse.
Las recomendaciones más amplias sobre la asignación de dispositivos USB en Proxmox destacan que el passthrough USB depende de que el host exponga primero el dispositivo; ese orden se vuelve crucial durante los arranques desatendidos de servidores domésticos.
Añade una dependencia limitada o una comprobación de disponibilidad en lugar de una espera arbitrariamente larga. El contenedor debe fallar claramente o esperar brevemente cuando el dispositivo necesario no esté presente.
Realiza una verificación completa del reinicio
Después de corregir la identidad, los permisos o el orden de inicio, reinicia el host en frío dos veces y prueba el funcionamiento real de la aplicación que utiliza el dispositivo, no solo si existe un nodo dentro de LXC.
La guía relacionada de configuración de servidor doméstico Proxmox de ZimaSpace mantiene la reparación vinculada a una configuración reproducible de Proxmox para servidores domésticos, en lugar de a una solución temporal válida solo durante la sesión.
El problema solo está resuelto cuando el mismo dispositivo físico aparece con el acceso previsto después de varios arranques. Si la identidad es estable pero el acceso sigue fallando, conserva los registros de denegación del host y del contenedor para analizar la siguiente capa.
Preguntas frecuentes
¿Por qué reiniciar el contenedor a veces restablece el dispositivo?
Es posible que el dispositivo haya aparecido después de que se iniciara el contenedor. Un reinicio posterior detecta el nodo de dispositivo del host ya creado, pero eso solo oculta la dependencia del orden de inicio.
¿Debo asignar un dispositivo USB mediante /dev/ttyUSB0?
Prefiere una identidad estable cuando la clase del dispositivo proporcione una. Los nombres numéricos de dispositivo pueden cambiar a medida que el hardware se enumera después de reiniciar.
¿Pueden restablecerse los permisos aunque la ruta del dispositivo siga siendo la misma?
Sí. udev puede volver a crear el nodo con el propietario, grupo y modo configurados, por lo que los cambios manuales realizados con chmod pueden desaparecer en la siguiente reconexión o reinicio.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
