Der Reader war vorhanden, aber der Container-Benutzer konnte ihn nicht öffnen
Der ZimaOS-Host erstellte den FTDI-Reader als /dev/ttyUSB0, und das Gerät wurde in den LinuxServer-OSCam-Container durchgereicht. OSCam protokollierte weiterhin errno=13 Permission denied.
Auf dem Host wurde das Zeichengerät als root:dialout mit dem Modus 660 angezeigt. Der Container war mit PUID=1000 und PGID=1000 konfiguriert, sodass sein Anwendungsbenutzer weder dem Eigentümer noch der zum Öffnen des Geräts berechtigten Gruppe dialout entsprach.
Die Änderung der Container-Identität behob den FTDI-Zugriff
Als erster Test wurde vorgeschlagen, den OSCam-Container als Root auszuführen, indem Folgendes gesetzt wird:
PUID=0
PGID=0Das vorhandene Mapping blieb bestehen:
devices:
- /dev/ttyUSB0:/dev/ttyUSB0Der Autor bestätigte, dass diese erste Methode ausreichte und der FTDI-Reader anschließend funktionierte. Das Ausführen eines Containers als Root und das Aktivieren des privilegierten Modus gewährt weitreichenden Zugriff. Dieses Ergebnis sollte daher als funktionierende Community-Lösung mit größeren Sicherheitsauswirkungen betrachtet werden, nicht als Ideal mit geringsten Berechtigungen.
Das Mapping der Gruppen ist die gezieltere Alternative
In der Antwort wurde außerdem beschrieben, den Container-Prozess der Gruppe dialout des Hosts hinzuzufügen. Dieser Ansatz kann eine Anwendung weiterhin ohne Root-Rechte ausführen, aber im Thread wurde weder eine getestete Konfiguration zum Hinzufügen der Gruppe angegeben noch die numerische GID von dialout auf diesem Host bestätigt.
Bevor Berechtigungen geändert werden, sollte bestätigt werden, dass lsusb das FTDI-Gerät erkennt und /dev/ttyUSB0 vorhanden ist. Fehlt der Geräteknoten, liegt das Problem bei der Treibererkennung oder dem Verhalten nach einer erneuten Verbindung und nicht bei den Besitzrechten des Containers.
Ein späterer CCcam-Timeout war ein anderes Problem
Nachdem der USB-Zugriff funktionierte, trat beim Autor ein Timeout bei der CCcam-Verbindung auf. Die Antworten untersuchten Bridge- und Host-Netzwerk, Routing, Subnetze, Firewall-Regeln sowie die Frage, ob der entfernte Dienst an der erwarteten Adresse lauschte. Zu einem bestimmten Zeitpunkt konnte der Client den Server weder anpingen noch dessen TCP-Port erreichen.
Der Autor berichtete später, dass ein Update des LinuxServer-OSCam-Container-Images das verbleibende Problem behoben habe. Da keine genauen fehlerhaften und funktionierenden Image-Tags aufgezeichnet wurden, kann der Thread keine genaue Versionsgrenze nennen.
FAQ
Warum hat der privilegierte Modus ttyUSB0 nicht automatisch repariert?
Die funktionierende Diagnose konzentrierte sich auf die Prozessidentität innerhalb des Containers. Der Prozess lief weiterhin mit UID und GID 1000, während das Gerät den Zugriff für Root und die Gruppe dialout erlaubte.
Welche Änderung bestätigte der Autor für den FTDI-Reader?
Er änderte PUID und PGID auf 0 und bestätigte, dass die zuerst vorgeschlagene Methode funktionierte.
Wurde der spätere Netzwerk-Timeout durch USB-Berechtigungen verursacht?
Nein. Das FTDI-Problem war bereits behoben. Das spätere Problem betraf die Netzwerk-Erreichbarkeit oder das Container-Image und funktionierte nach einem Update wieder.
