Czytnik był obecny, ale użytkownik kontenera nie mógł go otworzyć
Host ZimaOS utworzył czytnik FTDI jako /dev/ttyUSB0, a urządzenie zostało przekazane do kontenera LinuxServer OSCam. OSCam nadal rejestrował błąd errno=13 Permission denied.
Host wyświetlał urządzenie znakowe jako root:dialout z uprawnieniami 660. Kontener był skonfigurowany z wartościami PUID=1000 i PGID=1000, więc jego użytkownik aplikacji nie był właścicielem urządzenia ani członkiem grupy dialout uprawnionej do jego otwarcia.
Zmiana tożsamości kontenera rozwiązała problem z dostępem do FTDI
W ramach pierwszego testu zasugerowano uruchomienie kontenera OSCam jako root przez ustawienie:
PUID=0
PGID=0Istniejące mapowanie pozostało bez zmian:
devices:
- /dev/ttyUSB0:/dev/ttyUSB0Autor potwierdził, że ta pierwsza metoda była wystarczająca i że czytnik FTDI zaczął wtedy działać. Uruchomienie kontenera jako root oraz włączenie trybu uprzywilejowanego zapewnia szeroki dostęp, dlatego należy traktować ten rezultat jako funkcjonalne rozwiązanie społecznościowe o większym zakresie uprawnień, a nie jako rozwiązanie zgodne z zasadą najmniejszych uprawnień.
Mapowanie grup to węższa alternatywa
W odpowiedzi opisano również dodanie procesu kontenera do grupy dialout na hoście. Takie podejście może zachować nieuprzywilejowaną tożsamość aplikacji, ale w wątku nie przedstawiono przetestowanej konfiguracji dodawania grupy ani nie potwierdzono numerycznego GID grupy dialout na tym hoście.
Przed zmianą uprawnień upewnij się, że lsusb wykrywa urządzenie FTDI oraz że istnieje /dev/ttyUSB0. Jeśli węzeł urządzenia nie istnieje, problem dotyczy wykrywania sterownika lub ponownego podłączania, a nie właściciela urządzenia w kontenerze.
Późniejsze przekroczenie limitu czasu połączenia CCcam było innym problemem
Po uzyskaniu dostępu USB autor napotkał przekroczenie limitu czasu połączenia CCcam. W odpowiedziach analizowano sieć typu bridge i sieć hosta, routing, podsieci, reguły zapory oraz to, czy usługa zdalna nasłuchiwała pod oczekiwanym adresem. W pewnym momencie klient nie mógł ani pingować serwera, ani połączyć się z jego portem TCP.
Autor poinformował później, że aktualizacja obrazu kontenera LinuxServer OSCam rozwiązała pozostały problem. Nie zapisano dokładnych tagów obrazu, których dotyczył problem ani które go naprawiły, dlatego wątek nie pozwala wskazać precyzyjnej granicy wersji.
Najczęściej zadawane pytania
Dlaczego tryb uprzywilejowany nie naprawił automatycznie problemu z ttyUSB0?
Diagnoza wskazywała na tożsamość procesu wewnątrz kontenera. Nadal działał on z UID i GID 1000, podczas gdy urządzenie zezwalało na dostęp użytkownikowi root i grupie dialout.
Jaką zmianę autor potwierdził w przypadku czytnika FTDI?
Zmienił wartości PUID i PGID na 0 oraz potwierdził, że pierwsza zaproponowana metoda zadziałała.
Czy późniejsze przekroczenie limitu czasu połączenia sieciowego było spowodowane uprawnieniami USB?
Nie. Problem z FTDI został już rozwiązany. Późniejszy problem dotyczył osiągalności sieciowej lub obrazu kontenera i według zgłoszenia ustąpił po aktualizacji.
