Setting up newcamd in Docker: complete guide 2026

If you are working with a newcamd Docker container: setup — this material is written specifically for you. Not for beginners who have just opened the terminal for the first time, but for those who already have OScam orCCcam running on bare metal and who want to move to a container without losing their config and sanity. I have gone through this path myself — I will tell you where people really stumble and what is poorly written in the documentation.

What is newcamd and why run it in Docker

Newcamd is a TCP protocol for transmitting control words between card servers and clients. DES encryption with a 14-byte key that must match on both ends. The default port is 15000, although this is just a convention, not a standard.

An important point that many overlook: newcamd itself is not a separate daemon. In OScam, it is a server protocol that is enabled in the section[newcamd] inoscam.conf. There is no separate binary. Therefore, the container includes OScam with the newcamd server activated.

The newcamd protocol in a nutshell: TCP, DES encryption, port 15000

The client (OScam,CCcam, MGcamd in client mode) connects to the TCP port, goes through a DES handshake with key exchange, and after that can send ECM requests. The server responds with CW. All of this travels over a single TCP connection until either the client or server breaks it.

Each CAID lives on its own port. For example, 15000 for 0500, 15001 for 0604. This is not an option — it is an architectural limitation of the newcamd protocol. Keep this in mind when setting up the Docker network.

Advantages of containerization: isolation, rollback, reproducible builds

Docker is really convenient when you have multiple OScam instances — for example, one for testing new readers, another in production. Rolling back to a previous image version is one command. Reproducing the same configuration on another host is too.

Another plus: updating OScam without rebuilding the config. Configs are stored in a volume on the host, the image is rebuilt or downloaded again — and that's it. No manual file copying.

When Docker is excessive and when it is justified

Honestly: if you have one server, one card, and ten clients — Docker adds an unnecessary network layer that only complicates debugging. When there are connection issues, you will have to deal not only with oscam but also with the container network, iptables, and NAT.

But if you manage multiple instances, want CI/CD for configs, or simply value reproducibility — the container is fully justified. Especially if the host is already running something else and you want to avoid dependency conflicts.

Preparing the image and directory structure

The main rule: configs should not be included inside the image via COPY. Mount through volume — then you can changeoscam.conf and restart the container without rebuilding the image.

Choosing a base image: building OScam from source vs ready-made image

There are ready-made images on Docker Hub, but I recommend building it yourself — if only because you know exactly which modules are included. OScam without support for the newcamd server simply will not create the necessary listener. Make sure that the build includesMODULE_NEWCAMD.

For the build, you needgcc,make,libssl-dev,libpcsclite-dev (if you are using a smart card via PC/SC), optionallibusb-dev. The final image can be made on alpine or debian-slim — they are lighter.

Volume structure: /config, oscam.conf, oscam.server, oscam.user

Standard scheme: host folder./oscam-config is mounted in/usr/local/etc inside the container (this is the default path for OScam). This folder should contain:

• oscam.conf — main configuration, including section[newcamd]
• oscam.server — readers and smart cards
• oscam.user — users for clients
• oscam.services — service filtering (optional)
• oscam.ac — access control (if you are using it)

Example Dockerfile with OScam compilation and enabled webif

# Stage 1: build&& apt-get install -y \&& rm -rf /var/lib/apt/lists/*&& apt-get install -y \&& rm -rf /var/lib/apt/lists/*

File permissions for configuration files and process owner

Files with DES keys and user passwords — set chmod 600 and owner to the same UID under which oscam runs. In the example above, this is useroscam. Running as root is bad practice even in a container.

On the host:chown 999:999 ./oscam-config/* (if the UID of useroscam inside the container is 999) andchmod 600 ./oscam-config/oscam.conf. Otherwise, oscam may complain or ignore the file on startup.

Configuration of the newcamd server in OScam

This is where most guides on the internet provide an incomplete picture. Section[newcamd] inoscam.conf looks simple, but it has nuances that require hours of debugging.

The [newcamd] section in oscam.conf: key, port, allowed

[newcamd]

The format of theport parameter is what confuses people:port@CAID:ident1,ident2. That is,15000@0500:000000 means "listen on port 15000, serve CAID 0x0500, accept all ident". If you have two CAIDs, a new line is neededport with a different port:

port = 15000@0500:000000

The parametermgclient = 0 disables compatibility with MGcamd clients. If your clients are OScam in newcamd525 mode, leave it as 0.

Generation and assignment of a 14-byte DES key

The key is exactly 14 bytes, that is, 28 hexadecimal characters. It is generated simply:

openssl rand -hex 14

A common mistake is a key of 26 or 30 characters. OScam will not crash with an error, but will quietly reject all connections. The client will show "connection refused" or "wrong key", and you will be guessing for a long time. Count the characters twice.

User configuration in oscam.user for access via newcamd

[account]

The parameterau = 1 enables auto-update of rights through this user.group must match the groups of readers inoscam.server. Without this match, the reader simply will not be available to the user — a classic "no matching reader" error.

Binding readers and CAID/provider profiles

Inoscam.server the reader must specify the same groups:

[reader]

If the reader is a USB smart card, do not forget to pass the device into the container (more on this below). And make sure that the CAID in the reader matches the CAID in theport line of the section[newcamd].

Docker Network: port forwarding and modes

The network part is the most painful aspect when configuring newcamd Docker container: especially when there are multiple CAIDs and each requires its own port.

Port publication: -p 15000:15000 and several CAID ports

When starting withdocker run each port is a separate flag:

docker run -d \

Or a range:-p 15000-15005:15000-15005. This is easier, but Docker reserves the entire range even if only three ports are actually used.

Bridge vs host network for newcamd

Bridge network is the default for Docker. The container gets its own IP (usually 172.17.x.x), and ports are published via NAT. This works for newcamd, but you must explicitly forward each used port. The advantage is real isolation: the container does not see all host traffic.

network_mode: host — the container uses the host's network stack directly. OScam listens on 15000 as if it were running without Docker. No flags-p are needed. This is convenient when there are many CAID ports, but there is no network isolation at all — the container sees the entire host's network interface. For production, I prefer bridge with explicit forwarding.

docker-compose.yml with ports, volumes, and restart: unless-stopped

version: "3.9"

The variableTZ is critical. If the container's timezone does not match the client's timezone, strange issues with keepalive and ECM timeouts may arise. OScam uses system time for logs and internal timers.

Firewall, NAT, and external client access

After starting the container, check that the port is open on the host:

# Check from outside

With double NAT (container → host → router → internet), you need to forward the port on the router as well. If the client still cannot connect, check each layer one by one, not all at once.

Checking, logs, and common errors

When the newcamd Docker container setup is complete and the container is running, you need to ensure that everything is actually working, not just that the "process has started."

Reading docker logs and oscam webif (port 8888)

# Monitor logs in real time

Inoscam.conf add to the section[global]:

[global]

Webif is available on port 8888. In the Status → Clients section, each connected newcamd client is visible: its IP, the time of the last ECM request, CAID, and the decoding time in milliseconds. If the client is connected but ECMs are not being decoded, the problem lies with the reader, not the network.

Diagnosing connection refused and wrong DES key

Connection refused — the port is not forwarded or OScam did not start the listener at all. Check:docker exec oscam-newcamd netstat -tlnp | grep 15000. If the port is not there — check the OScam startup log, most likely there is a config parsing error.

Client disconnected immediately after connection — almost always a mismatch of the DES key. Check the key length (28 characters), make sure the client reader inoscam.server containskey = 0102030405060708091011121314 and the protocolnewcamd525.

No matching reader — the user inoscam.user does not have a common group with the reader. Checkgroup = inoscam.user andgroup = inoscam.server.

Checking ECM responses and decoding time

Normal ECM time for a local card is 50–300 ms. If you see 2000+ ms or a timeout at all — the reader is not responding. For a USB card, check that the device is forwarded correctly:

docker exec oscam-newcamd ls -la /dev/ttyUSB0

To forward a USB smart card, the flag is needed--device /dev/ttyUSB0:/dev/ttyUSB0 or the corresponding sectiondevices: in compose. Without this, oscam will not physically see the card, although the process will start without errors. Also, make sure that udev rules for the device are set up on the host, otherwise there will be no access rights in the container.

Network debugging between containers via docker network

If the client is another container (for example, another OScam in client mode), connecting via127.0.0.1 will not work. Use the service name from compose or the explicit IP of the container:

# Get the container IP

Containers from the samedocker-compose.yml automatically fall into a common bridge network and see each other by service name. Containers from different compose files do not — they need to be explicitly combined viaexternal: true network.

This is not an obvious point in the newcamd Docker container: configuration, but it often causes "container is running, config is correct, but the client does not see the server."