De reader was aanwezig, maar de containergebruiker kon hem niet openen
De ZimaOS-host maakte de FTDI-reader aan als /dev/ttyUSB0 en het apparaat werd doorgegeven aan de LinuxServer OSCam-container. OSCam logde nog steeds errno=13 Permission denied.
Op de host werd het apparaat weergegeven als root:dialout met modus 660. De container was geconfigureerd met PUID=1000 en PGID=1000, waardoor de applicatiegebruiker niet overeenkwam met de eigenaar of de dialout-groep die toegang tot het apparaat mocht openen.
Het wijzigen van de containeridentiteit loste FTDI-toegang op
De eerste voorgestelde test was om de OSCam-container als root uit te voeren door het volgende in te stellen:
PUID=0
PGID=0De bestaande koppeling bleef behouden:
devices:
- /dev/ttyUSB0:/dev/ttyUSB0De auteur bevestigde dat deze eerste methode voldoende was en dat de FTDI-reader daarna werkte. Een container als root uitvoeren en de geprivilegieerde modus inschakelen, geeft brede toegang. Dit resultaat moet daarom worden gezien als een functionele oplossing uit de community met een grotere beveiligingsimpact, niet als de ideale oplossing volgens het principe van minimale rechten.
Groepskoppeling is het beperktere alternatief
In het antwoord werd ook beschreven hoe je het containerproces aan de dialout-groep van de host kunt toevoegen. Daarmee kan een niet-rootapplicatie-identiteit behouden blijven, maar de thread bevatte geen geteste configuratie voor het toevoegen van de groep en bevestigde ook niet welke numerieke dialout-GID op deze host werd gebruikt.
Controleer voordat je machtigingen wijzigt of lsusb het FTDI-apparaat ziet en of /dev/ttyUSB0 bestaat. Als het apparaatknooppunt ontbreekt, ligt het probleem bij stuurprogrammaherkenning of opnieuw verbinden, en niet bij het eigenaarschap binnen de container.
Een latere CCcam-time-out was een ander probleem
Nadat USB-toegang werkte, kreeg de auteur te maken met een time-out bij de CCcam-verbinding. In de antwoorden werd gekeken naar bridge- versus host-netwerken, routering, subnetten, firewallregels en de vraag of de externe service op het verwachte adres luisterde. Op een bepaald moment kon de client de server noch pingen, noch de TCP-poort bereiken.
De auteur meldde later dat een update van de LinuxServer OSCam-containerimage het resterende probleem oploste. Er zijn geen exacte defecte en werkende imagetags vastgelegd, dus de thread kan geen precieze versiedrempel aangeven.
Veelgestelde vragen
Waarom loste de geprivilegieerde modus ttyUSB0 niet automatisch op?
De werkende diagnose richtte zich op de procesidentiteit binnen de container. Het proces draaide nog steeds met UID en GID 1000, terwijl het apparaat toegang toestond aan root en de dialout-groep.
Welke wijziging bevestigde de auteur voor de FTDI-reader?
De auteur wijzigde PUID en PGID naar 0 en bevestigde dat de eerste voorgestelde methode werkte.
Werd de latere netwerktime-out veroorzaakt door USB-machtigingen?
Nee. Het FTDI-probleem was al opgelost. Het latere probleem had te maken met netwerkbereikbaarheid of de containerimage en werd na een update als opgelost gemeld.
