O leitor estava presente, mas o utilizador do contentor não o conseguia abrir
O anfitrião ZimaOS criou o leitor FTDI como /dev/ttyUSB0, e o dispositivo foi disponibilizado ao contentor OSCam da LinuxServer. Ainda assim, o OSCam registou errno=13 Permission denied.
O anfitrião apresentava o dispositivo de caracteres como root:dialout, com o modo 660. O contentor estava configurado com PUID=1000 e PGID=1000, pelo que o utilizador da aplicação não correspondia ao proprietário nem ao grupo dialout autorizado a abrir o dispositivo.
A alteração da identidade do contentor resolveu o acesso ao FTDI
O primeiro teste sugerido consistia em executar o contentor OSCam como root, definindo:
PUID=0
PGID=0O mapeamento existente manteve-se:
devices:
- /dev/ttyUSB0:/dev/ttyUSB0O autor confirmou que este primeiro método foi suficiente e que o leitor FTDI passou a funcionar. Executar um contentor como root e ativar o modo privilegiado concede um acesso abrangente, pelo que este resultado deve ser considerado uma solução funcional da comunidade, com uma superfície de segurança maior, e não o ideal de menor privilégio.
O mapeamento de grupos é a alternativa mais restrita
A resposta também descreveu a adição do processo do contentor ao grupo dialout do anfitrião. Esta abordagem pode preservar uma identidade de aplicação não root, mas o tópico não forneceu uma configuração testada para adicionar o grupo nem confirmou o GID numérico do grupo dialout neste anfitrião.
Antes de alterar as permissões, confirme que o lsusb deteta o dispositivo FTDI e que /dev/ttyUSB0 existe. Se o nó do dispositivo não estiver presente, o problema está na deteção do controlador ou no comportamento após a reconexão, e não na propriedade do contentor.
Um timeout posterior do CCcam era um problema diferente
Depois de o acesso USB ter funcionado, o autor deparou-se com um timeout de ligação do CCcam. As respostas investigaram a utilização de rede bridge ou do anfitrião, o encaminhamento, as sub-redes, as regras da firewall e se o serviço remoto estava a escutar no endereço esperado. A certa altura, o cliente não conseguia fazer ping ao servidor nem alcançar a respetiva porta TCP.
Mais tarde, o autor informou que uma atualização da imagem do contentor OSCam da LinuxServer resolveu o comportamento restante. Não foram registadas as etiquetas exatas da imagem com problemas e da imagem corrigida, pelo que o tópico não permite identificar um limite preciso entre versões.
FAQ
Porque é que o modo privilegiado não corrigiu automaticamente o ttyUSB0?
O diagnóstico que prevaleceu centrou-se na identidade do processo dentro do contentor. Este continuava a ser executado com UID e GID 1000, enquanto o dispositivo permitia o acesso a root e ao grupo dialout.
Que alteração foi confirmada pelo autor para o leitor FTDI?
Alterou o PUID e o PGID para 0 e confirmou que o primeiro método proposto funcionou.
O timeout de rede posterior foi causado pelas permissões USB?
Não. O problema do FTDI já tinha sido resolvido. O problema posterior estava relacionado com a acessibilidade da rede ou com a imagem do contentor, e foi dado como resolvido após uma atualização.
