El lector estaba presente, pero el usuario del contenedor no podía abrirlo
El host de ZimaOS creó el lector FTDI como /dev/ttyUSB0, y el dispositivo se pasó al contenedor OSCam de LinuxServer. Aun así, OSCam registró errno=13 Permission denied.
El host mostró el dispositivo de caracteres como root:dialout con permisos 660. El contenedor estaba configurado con PUID=1000 y PGID=1000, por lo que el usuario de la aplicación no coincidía con el propietario ni pertenecía al grupo dialout autorizado para abrir el dispositivo.
Cambiar la identidad del contenedor resolvió el acceso al FTDI
La primera prueba sugerida fue ejecutar el contenedor OSCam como root estableciendo:
PUID=0
PGID=0El mapeo existente se mantuvo:
devices:
- /dev/ttyUSB0:/dev/ttyUSB0El autor confirmó que este primer método fue suficiente y que el lector FTDI comenzó a funcionar. Ejecutar un contenedor como root y habilitar el modo privilegiado concede un acceso amplio, por lo que este resultado debe considerarse una solución funcional de la comunidad con una superficie de seguridad mayor, no la opción ideal de mínimo privilegio.
El mapeo de grupos es la alternativa más limitada
La respuesta también describió cómo añadir el proceso del contenedor al grupo dialout del host. Este enfoque puede conservar una identidad de aplicación no root, pero el hilo no proporcionó una configuración probada para añadir el grupo ni confirmó el GID numérico de dialout en este host.
Antes de cambiar los permisos, confirma que lsusb detecta el dispositivo FTDI y que existe /dev/ttyUSB0. Si el nodo del dispositivo no está presente, el problema está relacionado con la detección del controlador o con el comportamiento tras la reconexión, no con la propiedad del contenedor.
Un tiempo de espera posterior de CCcam era otro problema distinto
Después de que el acceso USB funcionara, el autor se encontró con un tiempo de espera de conexión de CCcam. Las respuestas investigaron la red en modo bridge frente a la red del host, el enrutamiento, las subredes, las reglas del firewall y si el servicio remoto estaba escuchando en la dirección esperada. En un momento dado, el cliente no podía hacer ping al servidor ni alcanzar su puerto TCP.
Más tarde, el autor informó de que una actualización de la imagen del contenedor OSCam de LinuxServer resolvió el comportamiento restante. No se registraron las etiquetas exactas de la imagen que presentaba el problema y la que lo solucionó, por lo que el hilo no puede identificar un límite preciso de versión.
Preguntas frecuentes
¿Por qué el modo privilegiado no solucionó automáticamente ttyUSB0?
El diagnóstico adoptado se centró en la identidad del proceso dentro del contenedor. Este seguía ejecutándose con UID y GID 1000, mientras que el dispositivo permitía el acceso a root y al grupo dialout.
¿Qué cambio confirmó el autor para el lector FTDI?
Cambió PUID y PGID a 0 y confirmó que el primer método propuesto funcionaba.
¿El tiempo de espera de red posterior se debía a los permisos USB?
No. El problema del FTDI ya se había resuelto. El problema posterior estaba relacionado con la conectividad de red o con la imagen del contenedor, y se informó de que funcionaba después de una actualización.
