OScam oscam.user File: Setting Up Client Accounts Correctly (2026 Guide)

If you've ever stared at a client's log entry that says "connected" while their receiver shows zero channels, you already know the pain this article is about. Getting the OScam oscam.user file: setting up client accounts correctly is mostly about understanding one rule that almost nobody explains clearly — how authentication and authorization are two separate steps, and how a mismatch between them produces a login that "works" but delivers nothing.

I've rebuilt this file more times than I'd like to admit, on servers migrating off CCcam and on fresh OScam installs from source. The syntax itself is simple. What trips people up is the relationship between oscam.user and oscam.server — and that's exactly where this guide spends most of its time.

What the oscam.user File Actually Does

Think of oscam.user as two jobs stacked on top of each other. Job one is authentication: does this user/pwd combination exist, is it not expired, is it not disabled? Job two is authorization: assuming the login is valid, which groups, CAIDs, idents, channel IDs and services is this account actually allowed to touch? Most support tickets I've seen come from people who solved job one and never checked job two.

The file is plain text. One [account] block per client, comments start with #, and OScam reads the whole thing top to bottom at startup. Changes made over SSH require a restart or a SIGHUP to take effect — edits made through the WebIf Users tab apply immediately because the WebIf writes to the same file and triggers a reload itself.

Default locations vary by build:

• /usr/local/etc/oscam.user — standard for compiled-from-source installs
• /etc/tuxbox/config/oscam.user or /etc/tuxbox/config/oscam/oscam.user — common on Enigma2 images
• Whatever directory you passed with oscam -c /path/to/config — this always wins over any "default" path

Set permissions to 600 on this file. Passwords sit in plaintext, and on a multi-user box there's no reason any other account should be able to read them: chmod 600 /usr/local/etc/oscam.user.

Here's a minimal working block to ground the rest of this article:

[account]user = testclientpwd = Tr0ub4dor2026group = 1au = 1uniq = 1

user and pwd are the login credentials the client's receiver or CCcam.cfg will send. group = 1 means this account can only be routed to readers whose own group line in oscam.server includes group 1. au = 1 lets EMMs be forwarded to update the card automatically. uniq = 1 means only one active connection is allowed at a time — a second login kicks the first. That's the whole skeleton. Everything else in this file is refinement on top of it.

OScam evaluates a request in a fixed order: it checks the login against oscam.user, then intersects the account's group with available readers, then applies CAID/ident/chid/class filters, then picks a reader and asks for the ECM. oscam.server defines the readers and their groups; oscam.services defines named service bundles you can reference from oscam.user. oscam.conf just tells OScam which network protocols to listen on in the first place. None of these files do anything alone — the account block is the hinge between them.

Writing a Correct [account] Block: Every Parameter That Matters

Here's a fuller block with the parameters people actually need in production, annotated:

[account]user = clientnamepwd = SomeStrongPassword2026group = 1,2caid = 0500,1810ident = 0500:007800,1810:000000au = reader_localuniq = 3sleep = 90sleepsend = 255monlevel = 1cccmaxhops = 3cccreshare = 1allowedprotocols = cccam,cs378xexpdate = 2026-12-31disabled = 0

user, pwd — mandatory. No account is valid without both. A block missing pwd isn't "passwordless," it's unusable — OScam simply can't authenticate it.

group — a comma-separated list of numbers from 1 to 64. This is the single most misunderstood parameter in the whole file, and I'll cover it properly in the next section because it deserves its own worked example. Short version: this number means nothing on its own. It only matters relative to the group= line on a reader in oscam.server.

au — controls EMM forwarding. au = 1 lets updates go to any reader the account's group can reach. au = readername pins updates to one specific reader by name, which is the safer choice on a shared card — you don't want three different clients' EMMs racing each other against the same smartcard. Leave au blank to disable EMM forwarding entirely for that user, which is what I'd recommend by default for anyone connecting over the CCcam protocol, since CCcam-side AU has always been flaky in practice.

caid, ident, chid, class — narrowing filters. caid=0500,1810 restricts which CAIDs the account can request at all. ident= goes one level deeper with CAID:provid pairs, e.g. 0500:007800. chid= filters by channel ID, class= filters by ECM class. Leave any of them blank and that filter is simply not applied — the account inherits whatever the matched reader offers.

services — references a named block from oscam.services instead of listing raw CAID/provid pairs. Covered with an example in the next section.

uniq — values 0 to 4, controlling simultaneous logins. uniq = 0 disables the check. uniq = 1 is strict single-connection: a new login drops the old one. uniq = 3 allows multiple concurrent connections but only from the same source IP — correct for a household running two or three receivers behind one router.

sleep / sleepsend — sleep = 90 disconnects an idle client after 90 minutes of no ECM requests. sleepsend = 255 is the polite version — it tells CCcam-protocol clients to actually stop hammering the server once the sleep timer fires, instead of continuing to request and getting silently ignored.

cccmaxhops, cccreshare — topology controls for card-sharing chains. cccmaxhops caps how many hops a share can travel before this account's card is excluded from someone else's reshare; cccreshare controls whether this account's own share can be re-forwarded further down the chain.

monlevel — access level for the monitor/WebIf, unrelated to card access. disabled = 1 is the safer way to suspend an account temporarily — deleting a block loses the config, disabling it keeps everything intact and reversible. expdate = YYYY-MM-DD auto-expires the account on that date, useful for time-limited access without a manual follow-up.

allowedprotocols — pins the account to specific listening protocols (e.g. cccam,cs378x), so even if the credentials leak, they can't be used to connect via newcamd or any other enabled listener.

Group Mapping: Connecting oscam.user to oscam.server

This is the part that separates a working setup from a "connected but empty" one, and it's the part most tutorials skip entirely. The rule is simple to state and easy to get wrong: a client's group in oscam.user must share at least one number with a reader's group in oscam.server. No shared number, no ECM, no matter how correct the password is.

Say you're running two readers. Reader A is a local smartcard. Reader B is a remote proxy/CCcam reader pulling from elsewhere. In oscam.server:

[reader]label = reader_localgroup = 1protocol = internal[reader]label = reader_proxygroup = 2protocol = cccam

Now define three tiers of client in oscam.user:

[account]user = basicpwd = pass1group = 1[account]user = fullpwd = pass2group = 1,2[account]user = proxy_onlypwd = pass3group = 2

basic can only ever be routed to reader_local. full can reach either reader depending on what's needed. proxy_only is locked to reader_proxy and will never touch the local smartcard, even if it's sitting right there and idle.

Here's the failure mode I see constantly: someone creates group = 3 on a new account and forgets that no reader anywhere has group = 3 in oscam.server. The login succeeds — OScam has no problem authenticating a valid user/pwd — but the moment a channel is tuned, the log shows something like not found (no matching reader). The client assumes the card died. The card is fine. There's just no reader mapped to that group number.

Once you understand this, it becomes obvious why setting group = 1,2,3,4,5 on every account "to be safe" defeats the entire point of having groups. If every client can reach every reader, you've built an access control list that controls nothing — you might as well not have groups at all, and you've lost the ability to isolate your local card from a remote proxy reader when you actually need to.

For channel-level control below the group/CAID layer, use oscam.services. Define a named block:

[sports]caid = 0500provid = 023800srvid = 1101,1102,1103

Then reference it from an account instead of repeating raw CAID/provid pairs:

[account]user = clientnamepwd = pass4group = 1,2services = sports

Prefix with ! to blacklist instead of whitelist — services = !sports allows everything except that block. Leave services= empty and there's no service-level restriction at all; the account falls back to whatever the group/CAID/ident filters already allow.

Protocol-Specific Account Setup: CCcam, camd35, cs378x, newcamd, MGcamd

Here's the thing that surprises a lot of people migrating from CCcam: the same [account] block serves every protocol at once. oscam.user itself doesn't know or care whether the client connects via CCcam, newcamd, or cs378x — that's decided entirely by which listener in oscam.conf the client points at.

oscam.conf enables the listeners:

[cccam]port = 12000[camd35]port = 34000[cs378x]port = 34000[newcamd]port = 34001@0500:007800key = 0102030405060708091011121314

On the client side, each protocol needs its own line pointing at your server. For CCcam.cfg on a receiver:

C: your.server.tld 12000 clientname SomeStrongPassword2026 { 0:0:0 }

For MGcamd's newcamd.list:

CWS = your.server.tld 34001 clientname SomeStrongPassword2026 0102030405060708091011121314

For cs378x on a Wicardd or Enigma2-based client, it's the same host/port/user/pass structure as camd35 but over TCP instead of UDP — camd35 is UDP on port 34000, cs378x is TCP on the same port number by convention (they're not required to match, but most configs do it that way to keep it memorable).

newcamd deserves a specific warning: that 28-character hex string is a 14-byte DES key, and it must match byte-for-byte between the key = line in oscam.conf and the key entry on the client. Get one character wrong and the handshake fails silently — at default loglevel you won't see a useful error, just a client that never completes login. Also note that newcamd binds a port to a specific CAID:provid pair, so a client that needs several different CAIDs may need several newcamd ports defined, one per pair, unless you're using a build that supports multi-CAID binding on one port.

Once the account is in service, lock it down with allowedprotocols = cccam,cs378x if you know that's the only protocol this particular client uses. It's a small step that stops leaked credentials from being reused over a different protocol you didn't expect.

Verifying and Debugging: Logs, WebIf and the Errors You Will Actually See

Before touching a receiver, turn logging up. In oscam.conf:

[global]loglevel = 4logfile = /var/log/oscam/oscam.logdisablelog = 0

Bump loglevel to 255 temporarily if you need maximum verbosity while debugging a specific account, then dial it back down — at 255 the log fills up fast. Tail it live with tail -f /var/log/oscam/oscam.log while the client attempts to connect.

Here's what the common strings actually mean:

• wrong username/password — check for a stray space or, more often than people expect, a Windows CRLF line ending in a file that was edited on a Windows machine and uploaded via FTP. OScam can choke on the trailing \r and fail to parse the line correctly.
• account expired — expdate has passed. Check server time too — a clock that's drifted forward can expire an account early.
• user disabled — disabled = 1 is set on that block.
• not found (no matching reader) — group mismatch between oscam.user and oscam.server, exactly as covered above.
• client rejected (invalid ip) — an IP allowlist restriction on the account or listener is blocking the client's source address.
• CW not found — the reader was reached, but the card genuinely has no entitlement for that provid. This is a card/subscription issue, not an oscam.user issue.
• ECM time consistently over 1000ms — that's upstream or proxy latency, not something you fix in oscam.user.

Confirm the binary is even reading the config directory you think it is: oscam -b -c /usr/local/etc. The WebIf lives at http://your-server-ip:8888 by default (set via httpport in oscam.conf), and it will silently refuse to load if httpallowed doesn't include the subnet you're browsing from — no error page, just a connection that never completes.

After any manual edit, confirm the reload actually happened rather than assuming it did. SIGHUP behavior and the WebIf's Restart button don't behave identically across every build — check the log timestamp at the top after restart and confirm the new or changed account shows up under the WebIf Users tab before you call it done.

Hardening Client Accounts and Common Mistakes

A few operational habits save a lot of debugging later. One account per person or per subscription — don't hand the same credentials to three different households and rely on uniq to sort it out. Set uniq = 3 for one household running several boxes behind a single NAT connection, and uniq = 1 for a strict single-device account. Note that a client on CGNAT whose public IP changes mid-session can trip uniq = 1 and cause repeated disconnect/reconnect loops that look like a card fault but are actually a uniq/IP problem.

Back up oscam.user before every edit. A single syntax error in one block can stop the whole file from parsing, which takes down every account, not just the one you were editing. Keep permissions at 600 — plaintext passwords sitting in a world-readable file is an unnecessary risk on any shared server.

A duplicate user = name across two blocks doesn't throw an error — the later block in the file silently wins and the earlier one just stops working, with nothing in the log to tell you why. Similarly, watch for spaces around commas in older builds' group/caid lists — some versions parse group = 1, 2 differently from group = 1,2.Getting the OScam oscam.user file: setting up client accounts correctly the first time saves you from chasing these ghosts later, because most of them look like hardware problems and aren't.

Watch for edge cases that are easy to miss: an account that needs both a local smartcard and a remote proxy reader needs multi-group membership (group = 1,2) plus separate CAID/ident filters if the two sources carry different CAIDs. A reissued smartcard with a new provid can silently break an ident= filter that used to work, so if a previously-fine account suddenly gets CW not found, check whether the card behind it was swapped. And if you're running multiple OScam instances on one host with different -c config directories, double-check which oscam.user you're actually editing before you conclude a fix "didn't work" — it may have gone into the wrong instance's file entirely.

Before handing an account to anyone, run through this checklist:

• Block syntax is valid — no stray CRLF, no duplicated user=
• group intersects at least one reader's group in oscam.server
• caid/ident filters actually match what that reader carries
• au is set intentionally, not left on au=1 by default
• uniq and sleep match the client's real usage pattern
• Tested with a real ECM request and confirmed success in the log, not just a successful login

Get the OScam oscam.user file: setting up client accounts correctly right at this checklist stage and you'll spend a lot less time later fielding "my card stopped working" messages that are really just a group number that never matched a reader.