Il lettore era presente, ma l’utente del container non poteva aprirlo
L’host ZimaOS ha creato il lettore FTDI come /dev/ttyUSB0 e il dispositivo è stato assegnato al container OSCam di LinuxServer. OSCam continuava comunque a registrare errno=13 Permission denied.
L’host mostrava il dispositivo a caratteri come root:dialout con modalità 660. Il container era configurato con PUID=1000 e PGID=1000, quindi il suo utente applicativo non corrispondeva al proprietario né al gruppo dialout autorizzato ad aprire il dispositivo.
La modifica dell’identità del container ha risolto l’accesso a FTDI
Il primo test suggerito consisteva nell’eseguire il container OSCam come root impostando:
PUID=0
PGID=0La mappatura esistente è rimasta invariata:
devices:
- /dev/ttyUSB0:/dev/ttyUSB0L’autore ha confermato che questo primo metodo era sufficiente e che il lettore FTDI ha quindi funzionato. Eseguire un container come root e abilitare la modalità privilegiata garantisce un accesso esteso, quindi questo risultato va considerato una soluzione funzionale della community con un impatto maggiore sulla sicurezza, non l’opzione ideale in termini di minimo privilegio.
La mappatura dei gruppi è l’alternativa più circoscritta
La risposta descriveva anche l’aggiunta del processo del container al gruppo dialout dell’host. Questo approccio può mantenere un’identità applicativa non root, ma la discussione non forniva una configurazione verificata per l’aggiunta del gruppo né confermava il GID numerico di dialout su questo host.
Prima di modificare i permessi, verifica che lsusb rilevi il dispositivo FTDI e che /dev/ttyUSB0 esista. Se il nodo del dispositivo è assente, il problema riguarda il rilevamento del driver o il comportamento durante la riconnessione, non la proprietà del container.
Un timeout CCcam successivo era un problema diverso
Dopo aver risolto l’accesso USB, l’autore ha riscontrato un timeout di connessione CCcam. Le risposte hanno analizzato la rete bridge rispetto alla rete host, il routing, le sottoreti, le regole del firewall e l’eventualità che il servizio remoto fosse in ascolto sull’indirizzo previsto. A un certo punto il client non riusciva né a eseguire il ping del server né a raggiungere la relativa porta TCP.
In seguito l’autore ha riferito che un aggiornamento dell’immagine del container OSCam di LinuxServer ha risolto il comportamento rimanente. Non sono stati registrati i tag esatti dell’immagine difettosa e di quella corretta, quindi la discussione non consente di identificare un preciso limite di versione.
Domande frequenti
Perché la modalità privilegiata non ha risolto automaticamente il problema di ttyUSB0?
La diagnosi funzionante si concentrava sull’identità del processo all’interno del container. Il processo veniva ancora eseguito con UID e GID 1000, mentre il dispositivo consentiva l’accesso a root e al gruppo dialout.
Quale modifica ha confermato l’autore per il lettore FTDI?
Ha modificato PUID e PGID impostandoli su 0 e ha confermato che il primo metodo proposto funzionava.
Il timeout di rete successivo era causato dai permessi USB?
No. Il problema con FTDI era già stato risolto. Il problema successivo riguardava la raggiungibilità di rete o l’immagine del container, e l’autore ha riferito che funzionava dopo un aggiornamento.
