OSCam docker - blocks FTDI reader (/dev/ttyUSB0)

Insight & Feedback
1

I have a problem with Oscam not recognizing the USB card reader on the FTDI chip. When I had Truenas Scale everything worked.

name: joyful_tsui
services:
  main_app:
    cpu_shares: 10
    command: []
    deploy:
      resources:
        limits:
          memory: 16556617728
        reservations:
          devices: []
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    environment:
      - PGID=1000
      - PUID=1000
      - TZ=Etc/UTC
    image: lscr.io/linuxserver/oscam:latest
    labels:
      icon: https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/oscam-logo.png
    privileged: true
    restart: unless-stopped
    volumes:
      - type: bind
        source: /media/ZimaOS-HD/oscam
        target: /config
    ports: []
    cap_add: []
    network_mode: host
    container_name: ""
x-casaos:
  author: self
  category: self
  hostname: ""
  icon: https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/oscam-logo.png
  index: /
  is_uncontrolled: false
  port_map: "8383"
  scheme: http
  store_app_id: joyful_tsui
  title:
    custom: Oscam

Oscam.server

label                         = CANAL+[N3-1884]
protocol                      = mouse
device                        = /dev/ttyUSB0
caid                          = 1884
mod1                          = xxx
idird                         = 80374C13
mod2                          = xxx
key3588                       = xxx
key3460                       = xxxx
key3310                       =xxx
data50                        = xxx
mod50                         = xxx
nuid                          = xxx
cwpkcaid                      = 18FE
cwekey0                       = xxxx
cwpkota                       = 1
detect                        = cd
mhz                           = 343
group                         = 1
emmcache                      = 1,1,2,0
blockemm-unknown              = 1
blockemm-g                    = 1
disablecrccws                 = 1
audisabled                    = 1

Oscam log

2025/12/06 10:07:14 00000000 s  (signing) Signature      = Valid - Binary's signature was successfully verified using the built-in Public Key
2025/12/06 10:07:14 00000000 s  (signing) Certificate    = Trusted CA Certificate, valid until 05.12.2026 09:19:46
2025/12/06 10:07:14 00000000 s      (net) cccam: initialized (fd=3, port=9798)
2025/12/06 10:07:14 00000000 s   (reader) CANAL+[N3-1884] [mouse] creating thread for device /dev/ttyUSB0
2025/12/06 10:07:14 00000000 s     (main) waiting for local card init
2025/12/06 10:07:14 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:14 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:14 78073154 h    (webif) webif: decompressed 178689 bytes back into 482112 bytes
2025/12/06 10:07:14 78073154 h    (webif) HTTP Server running. ip=0.0.0.0 port=8383 (no SSL)
2025/12/06 10:07:16 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:16 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:18 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:18 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:20 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:20 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:22 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:22 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:24 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:24 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:26 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:26 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:28 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:28 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:30 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:30 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:32 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:32 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:34 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied)
2025/12/06 10:07:34 77AB0B1E r   (reader) CANAL+[N3-1884] [mouse] Cannot open device: /dev/ttyUSB0
2025/12/06 10:07:34 00000000 s     (main) init for all local cards done
2025/12/06 10:07:34 00000000 s (anticasc) anti cascading disabled

ls usb

admin@NAS:~ ➜ $ ls -l /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Dec  5 10:45 /dev/ttyUSB0
admin@NAS:~ ➜ $
3

I’ve seen you turn on privilege mode , and theoretically there shouldn’t be an issue with implementing permissions.

4

It looks like the container can see the reader, but the OS is blocking access because of permission rules on the device.

On ZimaOS the FTDI device appears as
crw-rw---- root dialout
which means only root and the dialout group can open it.

Inside your container you are running as PUID 1000 and PGID 1000. That user does not belong to the dialout group, so even with privileged mode enabled the kernel still applies the host permissions. This is why Oscam shows
errno 13 permission denied.

I suggest trying one of these approaches

  1. Run the container as root inside the container.
    Oscam does not require root, but this is the simplest way to match the device permissions.
  2. Add the container user to the dialout group.
    ZimaOS does not automatically map supplementary groups into containers, so you may need to override the user mapping or switch to a root user. Many LinuxServer images allow
    PUID 0 and PGID 0
    which makes access immediate.
  3. Confirm the host sees the reader correctly.
    If lsusb shows the FTDI chip and ttyUSB0 is created, then the problem is only permission mapping and not hardware.

I think option 1 is the fastest fix on ZimaOS.
Change your compose to run Oscam as root (PUID 0 PGID 0) and keep privileged mode on. That should allow Oscam to open ttyUSB0 without error.

If it still fails, then the issue is not permissions but the driver binding, and we can explore forcing the ftdi_sio driver or checking udev rules.

2 Likes
5

Everything works. The first method was enough. Thank you.

1 Like
6

I still have a problem with a specific external user via the cccam protocol

[cccam]
port                          = 10023
nodeid                        = 4E4D7F0710C12426
version                       = 2.3.2
reshare                       = 1

Client

2025/12/24 08:22:35 10D9FF40 p   (reader) serwer_zimaos [cccam] connecting to 192.168.2.200:10023
2025/12/24 08:22:38 10D9FF40 p   (reader) serwer_zimaos [cccam] connect failed: Connection timed out

[reader]
label                         = serwer_zimaos
protocol                      = cccam
device                        = 192.168.2.200,10023
user                          = test
password                      = test
inactivitytimeout             = 30
group                         = 1
cccversion                    = 2.3.2
ccckeepalive                  = 1

name: joyful_tsui
services:
  main_app:
    cpu_shares: 10
    command: []
    container_name: oscam
    deploy:
      resources:
        limits:
          memory: 16556617728
        reservations:
          devices: []
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    environment:
      - PGID=0
      - PUID=0
      - TZ=Europe/Warsaw
    image: lscr.io/linuxserver/oscam:latest
    labels:
      icon: https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/oscam-logo.png
    ports:
      - target: 10023
        published: "10023"
        protocol: tcp
      - target: 8383
        published: "8383"
        protocol: tcp
    privileged: true
    restart: unless-stopped
    volumes:
      - type: bind
        source: /media/ZimaOS-HD/oscam
        target: /config
    cap_add: []
    network_mode: bridge
x-casaos:
  author: self
  category: self
  hostname: ""
  icon: https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/oscam-logo.png
  index: /
  is_uncontrolled: false
  port_map: "8383"
  scheme: http
  store_app_id: joyful_tsui
  title:
    custom: Oscam
7

At this point the FTDI / USB issue is resolved.
What you’re seeing now is a pure network connectivity problem, not permissions.

The key line is
connect failed: Connection timed out

That means Oscam never reaches the remote CCcam server at all.

A few important points I believe apply here:

  1. Bridge mode + CCcam can be problematic
    You are running the container in network_mode: bridge.
    CCcam is very sensitive to NAT and port translation.

I strongly suggest switching Oscam to
network_mode: host
and removing the explicit port mappings. This avoids Docker NAT entirely and mirrors how it worked on TrueNAS.

  1. Confirm the remote side is actually reachable
    From the ZimaOS host (not the container), test:
  • ping 192.168.2.200
  • telnet 192.168.2.200 10023

If this times out, the issue is upstream (firewall, routing, or the CCcam server itself).

  1. Check CCcam is listening on the server
    On the remote Oscam server, confirm port 10023 is bound to the correct interface (0.0.0.0, not localhost only).
  2. No permission issue anymore
    Running with PUID 0 PGID 0 and privileged mode rules out local access problems. The timeout confirms this is not an Oscam or USB issue.

In short, I think the fix is:

  • switch to host networking
  • verify basic TCP reachability to 192.168.2.200:10023

If it still times out after that, the problem is definitely on the CCcam server side or the network between them, not ZimaOS or Docker.

1 Like
8

NET–> HOST.
There seems to be something wrong with the network. It seems like something is blocking it on the zimaos side.

*****************************
*                           *
*   The Gemini Project 4.2  *
*                           *
*****************************

dm920 login: root
Password:
root@dm920:~# telnet 192.168.2.200 10023
telnet: can't connect to remote host (192.168.2.200): No route to host
root@dm920:~# ping 192.168.2.200
PING 192.168.2.200 (192.168.2.200): 56 data bytes
--- 192.168.2.200 ping statistics ---
198 packets transmitted, 0 packets received, 100% packet loss
root@dm920:~#
9

This confirms it is not an Oscam or Docker issue.

From the dm920 you cannot:

  • ping 192.168.2.200
  • telnet 192.168.2.200:10023

The error “No route to host” means there is no network path to that IP at all.

That points to one of these, in order of likelihood:

  1. Different subnets with no routing
    The dm920 (and likely ZimaOS) is not on the 192.168.2.0/24 network, and there is no router or gateway allowing traffic between subnets.
  2. Wrong IP or interface on the server
    The CCcam server may no longer be on 192.168.2.200, or it is bound to a different interface or VLAN.
  3. Firewall blocking ICMP and TCP
    A firewall on the server or router is blocking both ping and port 10023. Blocking ping alone is common, but blocking both usually indicates routing or firewall rules.
  4. Network isolation / VLAN
    If the server is on a VLAN or isolated LAN, devices outside that segment will not reach it without explicit routing.

Important takeaway:
If ping fails, CCcam will never work, regardless of Oscam config, Docker mode, or ZimaOS.

I suggest:

  • Verify the actual IP of the CCcam server
  • Confirm both devices are on the same subnet, or that routing exists between them
  • Temporarily disable firewall rules on the server to test connectivity

Once basic ping works, CCcam will connect immediately.

1 Like
10

I’m back after a while, after struggling with everything. The latest Docker update helped. So the culprit wasn’t ZimaOS or Dreambox, but the OSCAM binary itself or Docker (linuxserver/oscam - Docker Image). Now everything works as it should, and I’m happy.

11

Awesome update, thanks for circling back.

That’s actually really valuable info for others:
it confirms the issue wasn’t ZimaOS or the Dreambox network at all, but something inside the linuxserver/oscam container (OSCAM binary and or Docker layer), and the newer Docker update resolved it.

Really glad it’s now working properly and stable
If you notice anything repeatable (specific version that broke vs version that fixed), sharing that would help the community a lot.

1 Like