Le lecteur était présent, mais l’utilisateur du conteneur ne pouvait pas l’ouvrir
L’hôte ZimaOS a créé le lecteur FTDI sous la forme /dev/ttyUSB0, et le périphérique a été transmis au conteneur OSCam de LinuxServer. OSCam consignait toutefois toujours errno=13 Permission denied.
L’hôte affichait le périphérique caractère comme appartenant à root:dialout, avec le mode 660. Le conteneur était configuré avec PUID=1000 et PGID=1000 : son utilisateur applicatif ne correspondait donc ni au propriétaire ni au groupe dialout autorisé à ouvrir le périphérique.
La modification de l’identité du conteneur a résolu l’accès au FTDI
Le premier test suggéré consistait à exécuter le conteneur OSCam en tant que root en définissant :
PUID=0
PGID=0Le mappage existant est resté le même :
devices:
- /dev/ttyUSB0:/dev/ttyUSB0L’auteur a confirmé que cette première méthode suffisait et que le lecteur FTDI fonctionnait ensuite. Exécuter un conteneur en tant que root et activer le mode privilégié accorde un accès étendu. Ce résultat doit donc être considéré comme une solution communautaire fonctionnelle, mais avec une surface d’exposition plus importante, et non comme la solution idéale fondée sur le principe du moindre privilège.
Le mappage du groupe constitue une alternative plus restrictive
La réponse décrivait également l’ajout du processus du conteneur au groupe dialout de l’hôte. Cette approche permet de conserver une identité applicative non root, mais la discussion ne fournissait pas de configuration testée pour l’ajout au groupe et ne confirmait pas le GID numérique de dialout sur cet hôte.
Avant de modifier les permissions, vérifiez que lsusb détecte le périphérique FTDI et que /dev/ttyUSB0 existe. Si le nœud de périphérique est absent, le problème vient de la détection du pilote ou du comportement lors de la reconnexion, et non des droits du conteneur.
Un délai d’expiration CCcam ultérieur correspondait à un autre problème
Une fois l’accès USB fonctionnel, l’auteur a rencontré un délai d’expiration lors de la connexion CCcam. Les réponses ont examiné le réseau en mode bridge ou hôte, le routage, les sous-réseaux, les règles du pare-feu et la question de savoir si le service distant écoutait à l’adresse attendue. À un moment donné, le client ne pouvait ni envoyer de requête ping au serveur ni atteindre son port TCP.
L’auteur a ensuite indiqué qu’une mise à jour de l’image du conteneur OSCam de LinuxServer avait résolu le problème restant. Aucun tag d’image défaillant ou corrigé précis n’a été indiqué ; la discussion ne permet donc pas d’identifier une limite exacte entre les versions.
FAQ
Pourquoi le mode privilégié n’a-t-il pas automatiquement résolu le problème de ttyUSB0 ?
Le diagnostic retenu portait sur l’identité du processus à l’intérieur du conteneur. Celui-ci s’exécutait toujours avec l’UID et le GID 1000, tandis que le périphérique autorisait l’accès à root et au groupe dialout.
Quelle modification l’auteur a-t-il confirmée pour le lecteur FTDI ?
Il a défini PUID et PGID sur 0 et confirmé que la première méthode proposée fonctionnait.
Le délai d’expiration réseau ultérieur était-il dû aux permissions USB ?
Non. Le problème lié au FTDI avait déjà été résolu. Le problème ultérieur concernait l’accessibilité réseau ou l’image du conteneur, et son bon fonctionnement a été signalé après une mise à jour.
