The Reader Was Present but the Container User Could Not Open It
The ZimaOS host created the FTDI reader as /dev/ttyUSB0, and the device was passed into the LinuxServer OSCam container. OSCam still logged errno=13 Permission denied.
The host showed the character device as root:dialout with mode 660. The container was configured with PUID=1000 and PGID=1000, so its application user did not match the owner or dialout group allowed to open the device.
Changing the Container Identity Resolved FTDI Access
The suggested first test was to run the OSCam container as root by setting:
PUID=0
PGID=0The existing mapping remained:
devices:
- /dev/ttyUSB0:/dev/ttyUSB0The author confirmed that this first method was sufficient and that the FTDI reader then worked. Running a container as root and enabling privileged mode grants broad access, so this result should be treated as a functional community fix with a larger security footprint, not the least-privilege ideal.
Group Mapping Is the Narrower Alternative
The reply also described adding the container process to the host's dialout group. That approach can preserve a non-root application identity, but the thread did not provide a tested group-add configuration or confirm the numeric dialout GID on this host.
Before changing permissions, confirm that lsusb sees the FTDI device and that /dev/ttyUSB0 exists. If the device node is absent, the problem is driver detection or reconnect behavior rather than container ownership.
A Later CCcam Timeout Was a Different Problem
After USB access worked, the author encountered a CCcam connection timeout. Replies investigated bridge versus host networking, routing, subnets, firewall rules, and whether the remote service listened on the expected address. At one point the client could neither ping the server nor reach its TCP port.
The author later reported that an update to the LinuxServer OSCam container image resolved the remaining behavior. No exact broken and fixed image tags were recorded, so the thread cannot identify a precise version boundary.
FAQ
Why did privileged mode not automatically fix ttyUSB0?
The working diagnosis focused on the process identity inside the container. It was still running with UID and GID 1000 while the device allowed root and dialout access.
What change did the author confirm for the FTDI reader?
They changed PUID and PGID to 0 and confirmed that the first proposed method worked.
Was the later network timeout caused by USB permissions?
No. The FTDI issue had already been resolved. The later problem involved network reachability or the container image and was reported working after an update.
