Läsaren fanns, men containeranvändaren kunde inte öppna den
ZimaOS-värden skapade FTDI-läsaren som /dev/ttyUSB0, och enheten skickades vidare till LinuxServer OSCam-containern. OSCam loggade ändå errno=13 Permission denied.
Värden visade teckenenheten som root:dialout med behörigheten 660. Containern var konfigurerad med PUID=1000 och PGID=1000, vilket innebar att dess programanvändare inte motsvarade ägaren eller gruppen dialout som hade behörighet att öppna enheten.
Åtgärden av containeridentiteten löste FTDI-åtkomsten
Det föreslagna första testet var att köra OSCam-containern som root genom att ange:
PUID=0
PGID=0Den befintliga mappningen förblev:
devices:
- /dev/ttyUSB0:/dev/ttyUSB0Författaren bekräftade att denna första metod var tillräcklig och att FTDI-läsaren därefter fungerade. Att köra en container som root och aktivera privilegierat läge ger bred åtkomst. Resultatet bör därför betraktas som en fungerande lösning från communityn med större säkerhetskonsekvenser, inte som den mest begränsade behörighetslösningen.
Gruppmappning är det mer begränsade alternativet
Svaret beskrev också hur containerprocessen kan läggas till i värdens dialout-grupp. Det tillvägagångssättet kan bevara en icke-root-baserad programidentitet, men tråden innehöll ingen testad konfiguration för att lägga till gruppen och bekräftade inte det numeriska GID-värdet för dialout på denna värd.
Innan du ändrar behörigheter bör du bekräfta att lsusb ser FTDI-enheten och att /dev/ttyUSB0 finns. Om enhetsnoden saknas gäller problemet drivrutinsidentifiering eller återanslutning, inte containerägarskap.
En senare CCcam-timeout var ett annat problem
Efter att USB-åtkomsten fungerade stötte författaren på en timeout vid CCcam-anslutningen. Svaren undersökte bryggat nätverk jämfört med värdnätverk, routning, subnät, brandväggsregler och om fjärrtjänsten lyssnade på den förväntade adressen. Vid ett tillfälle kunde klienten varken pinga servern eller nå dess TCP-port.
Författaren rapporterade senare att en uppdatering av LinuxServer OSCam-containeravbildningen löste det återstående problemet. Inga exakta taggar för den trasiga respektive fungerande avbildningen dokumenterades, så tråden kan inte fastställa en exakt versionsgräns.
Vanliga frågor
Varför löste inte privilegierat läge automatiskt problemet med ttyUSB0?
Den fungerande diagnosen fokuserade på processidentiteten inuti containern. Den kördes fortfarande med UID och GID 1000, medan enheten tillät åtkomst för root och dialout.
Vilken ändring bekräftade författaren för FTDI-läsaren?
De ändrade PUID och PGID till 0 och bekräftade att den första föreslagna metoden fungerade.
Orsakades den senare nätverkstimeouten av USB-behörigheter?
Nej. FTDI-problemet hade redan lösts. Det senare problemet gällde nätverksåtkomst eller containeravbildningen och rapporterades fungera efter en uppdatering.
