Setting up newcamd in Docker: guide 2026

If you are reading this, you already know what you want: to set up a newcamd server or client inside a container, and something went wrong. Maybe the port is not being forwarded. Maybe the reader is stuck in CONNECTED, but the channels are not opening. This material is specifically designed for that — newcamd Docker container: setup from scratch to operational state, without fluff and marketing.

All examples below are on OScam, because it remains the de facto standard for newcamd in both server and client variants.

What is newcamd and why run it in Docker

Newcamd is a TCP protocol for card sharing. It operates over a regular TCP connection, encrypting the session with a 14-byte DES key (which is also recorded as 28 hex characters). By default, there is no hardcoded port — it is configured manually, but traditionally most servers listen on something in the range of 28000–28010.

In OScam, newcamd is implemented on both sides: the section[newcamd] inoscam.conf makes it a server, while the block[reader] withprotocol = newcamd inoscam.server is the client that connects to the remote server.

Newcamd protocol: default port and DES key

The DES key is not a password in the usual sense. It is used to encrypt the entire session at the transport level. The length is strictly fixed: 14 bytes, 28 hex characters. It cannot be shortened or lengthened. If the keys on the server and client do not match, the connection is technically established, but the data is decrypted into garbage — ECM requests go through, but the responses are not parsed.

The port is specified in the formatPORT@CAID:IDENT. For example,28000@0500:000000 means: listen on port 28000, serve CAID 0x0500 (Viaccess), provider identifier 0x000000. You can specify multiple lines for different CAIDs.

Why OScam in a container is a convenient way to run a newcamd server

The main convenience is reproducibility. You fix the image tag, and in six months you can bring up exactly the same version of OScam on new hardware with three commands. No issues with libc dependencies, conflicting packages, or system libraries.

Plus isolation: the OScam process does not see the rest of the system. If something breaks — you delete the container, recreate it. The configs live on the host in a mounted volume and do not go anywhere.

When containerization is justified and when it is unnecessary

Docker is excessive in one scenario: if you have a local DVB card and want to use it as aninternal reader. In bridge mode, the device/dev/dvb/adapter0 is not available without explicit forwarding through--device, and with host mode, isolation is lost. If the entire job is to proxy newcamd lines from remote servers to clients, Docker is a great fit.

Preparing the image and config structure

The first thing to decide before starting the container is where the configuration will reside and under what UID the OScam process will run inside.

Choosing an OScam image with newcamd support

There are several unofficial OScam images on Docker Hub. Check if the binary is built with the flag--enable-protocol-newcamd — without it, the section[newcamd] in the config is simply ignored without any errors, which is very convenient for three-hour debugging of a non-existent problem.

You can check it like this:

docker run --rm your-oscam-image oscam --build-info | grep -i newcamd

If the line exists — everything is fine. If not — another image or a custom build is needed.

The directory for configs: /var/keys or /config

The path depends on the image. Most popular builds mount configs in/var/keys or/config. Check theENTRYPOINT in the Dockerfile or the image documentation. Example of mounting:

-v /opt/oscam/config:/var/keys

The main rule: configs always on the host. Never store them only inside the image layer — you will lose everything whendocker pull a new version.

Check the UID. If OScam runs inside as a user with UID 1000, and the files on the host belong to root, it will not be able to writeoscam.log — you will be debugging blindly. This can be fixed bychown 1000:1000 /opt/oscam/config on the host or by using the--user parameter when starting the container.

Minimum set of files: oscam.conf, oscam.server, oscam.user

To run the newcamd server, three files are needed:

• oscam.conf — global settings and sections[global],[newcamd],[webif]
• oscam.server — readers (if OScam acts as a client to another server)
• oscam.user — client accounts that connect to your server

Fileoscam.dvbapi is needed only if a local card is used.oscam.services — optional, for filtering channels by services.

Configuration of newcamd server in OScam

This is where most guides provide the config but do not explain the syntax. Let's break it down.

Section [newcamd]: key, port, allowed

In the file/var/keys/oscam.conf (path inside the container) you add:

[newcamd]

Parameterkey — this is the very 14-byte DES key, written as 28 hex characters. The example above is for educational purposes; in production, use something less obvious.allowed restricts which subnets are allowed to connect at the protocol level — a good practice.

Binding CAID to port in the port parameter

SyntaxPORT@CAID:IDENT allows you to rigidly bind a port to a specific conditional access system. If you want multiple CAIDs on different ports:

port = 28000@0500:000000|28001@0604:000000|28002@1800:000000

This is one line. Three ports: 28000 for Viaccess (0500), 28001 for Irdeto (0604), 28002 for Nagravision (1800). All three ports need to be forwarded in Docker — we will discuss how below.

If you simply writeport = 28000 without CAID, the server will respond to requests across all available systems. This is more convenient at the beginning but less controllable.

Creating a client account in oscam.user

File/var/keys/oscam.user:

[account]

The client connects with this login and password. The parametergroup must match the group of the reader that provides the card — otherwise, there will be no decoding, although the connection will appear normal. This is one of the most common reasons for "CONNECTED without decode."

Port forwarding and Docker network modes

This is where most problems with newcamd Docker container arise: configuration in real conditions. Docker networking is not an obvious topic.

Bridge mode with -p 28000:28000

By default, the container operates in bridge mode. Ports are not visible from the outside until they are explicitly published:

docker run -d \

If newcamd listens on multiple ports — forward each one separately:

-p 28000:28000 -p 28001:28001 -p 28002:28002

Or by range, if the ports are consecutive:

-p 28000-28002:28000-28002

Important: make sure these ports are not occupied by another process on the host. Check:ss -tlnp | grep 280. If the port is occupied, Docker will silently not report an error whendocker run — only when the client tries to connect will they receive a refusal.

When network_mode: host is needed

Withnetwork_mode: host the container uses the host's network stack directly. No NAT, no port forwarding — OScam listens on 28000, and this is visible directly from the outside.

Convenient in two cases: many ports (10+ newcamd lines for different CAIDs) or when working with local DVB devices and multicast. The downside — you lose network isolation and the risk of port conflicts increases.

Several newcamd ports for different CAIDs

Equivalent indocker-compose.yml:

version: "3.8"

Or with host network:

version: "3.8"

Withnetwork_mode: host the sectionports is completely removed — it is ignored in this mode.

Connecting a newcamd client (reader)

If your container acts as a client — connecting to a remote newcamd server — the reader config goes to/var/keys/oscam.server.

Block [reader] with protocol = newcamd

[reader]

Parameterdevice — is the server address and port separated by a comma. You can use a hostname, but DNS resolution inside the container must work — check that/etc/resolv.conf in the container points to a working resolver.

Parameters device, key, user, password

key must be exactly the same 28-character hex as specified in the[newcamd] section on the server. Neither more nor less.user andpassword match the block[account] inoscam.user of the server.

The parametercaid in the reader is a hint for OScam on which systems to try this reader. If the server returns multiple CAIDs, they can be listed separated by commas:caid = 0500,0604.

Checking the status of the reader in the OScam web interface

Enable webif inoscam.conf:

[webif]

Forward port 8888 when starting the container and openhttp://host:8888. In the Readers section, check the status:CONNECTED — TCP connection exists,CARD — card is recognized and returns ECM responses,UNAVAILABLE — no connection at all.

StatusCONNECTED withoutCARD — this is a logical problem, not a network issue. The connection exists, but something prevents getting a response to ECM requests. Check inoscam.log.

Diagnosis and troubleshooting of typical errors

Most problems with the newcamd Docker container: configuration is divided into two classes: network (the client cannot reach the port at all) and logical (the connection exists, but there is no decoding). Their diagnosis is fundamentally different.

Reader CONNECTED, but no decoding

This is a logical problem. Checklist:

• Checkgroup inoscam.user andoscam.server — they must match
• Make sure that the CAID/ident in the request matches what is specified on the server
• Check that the account inoscam.user has no service restrictions (services /ident)
• Increase the debug level and read the log:loghistorysize = 4000 anddebug = 64 in the section[global]

In the logs, look for lines withECM — it will show whether the server receives the request and what it responds.

DES key mismatch error

When the key does not match, OScam usually shows an error likeinvalid DES key length or the connection is established but immediately drops. The log file will have a line withdecrypt error orhandshake failed.

Common reason: somewhere the key was copied with a space at the beginning or end, or 26 characters were inserted instead of 28. Always check the length before saving.

The container is not listening on the port: check via ss/netstat

First, make sure that OScam inside the container is actually listening on the required port:

docker exec oscam ss -tlnp

Or via netstat if ss is unavailable:

docker exec oscam netstat -tlnp 2>/dev/null | grep 28000

If the port is not being listened to from the inside — the problem is in the OScam config, not in Docker. If it is listening but not accessible from the outside — the problem is in port forwarding or the host's firewall.

Checking the firewall:

iptables -L DOCKER -n -v | grep 28000

Docker usually adds rules to the chain itselfDOCKER, but some distributions with aggressive default policies may block traffic before it reaches there. Also check the chainINPUT.

OScam logs: debug levels and filters

In the section[global] of the fileoscam.conf:

[global]

The valuedebug = 64 includes detailed logging of the newcamd protocol. The value255 is the maximum, but that’s a lot of text. For diagnosing a specific reader, it’s more convenient to use the web interface: the Logs section with a filter by the reader's name.

And one more thing that is often overlooked: the time zone inside the container. If the container lives in UTC and the host in Europe/Moscow, the timestamps inoscam.log will be 3 hours behind the system time. This is not critical, but it can be confusing when correlating events with other logs. It can be fixed with an environment variable:-e TZ=Europe/Moscow when starting.

In summary: the complete scheme of the newcamd Docker container: the setup boils down to a properly chosen image, configs on the host via a volume, explicit forwarding of all newcamd ports, and understanding the difference between a network and a logical error.