If you've already worked through installing Sonarr, Radarr, Prowlarr, or qBittorrent in an LXC container, you've probably noticed something: every one of those guides assumes you're grabbing torrents. Torrents work, but they're not the only way to automate downloads on Proxmox, and for a lot of homelab users they're not even the best one. The other half of that world runs on Usenet, and the app that ties it all together is SABnzbd.
This guide walks you through installing SABnzbd in its own lightweight LXC container on Proxmox VE, from creating the container to finishing the first-run setup wizard. By the end you'll have a working download client that Sonarr, Radarr, and the rest of the *arr stack can send jobs to directly.
What You Will Learn
- What SABnzbd actually does and how it's different from a torrent client
- How to create a small, dedicated Debian 13 LXC container for it on Proxmox VE
- How to install SABnzbd from Debian's backports repository, since the version in the stable repo is usually years old
- How to run through the first-time setup wizard, including your Usenet server details
- How to fix the errors people run into most — "unable to locate package," failed server connections, and permission problems with the *arr stack
What Is This Feature?
SABnzbd is a free, open-source download manager built around Usenet. Usenet itself is a decades-old distributed discussion network that, these days, is mostly used for one thing: binary file distribution. Providers keep massive archives of posted files going back months or years — that history is called retention — and you pay a provider for access to it, the same way you'd pay for cloud storage.
You don't browse Usenet directly to find files. Instead, you use an indexer (a searchable site that catalogs what's on Usenet) to find what you want, which gives you a small file called an NZB. An NZB isn't the actual content — it's more like a torrent file: a set of instructions pointing SABnzbd at the exact pieces it needs to download from your provider and reassemble.
SABnzbd's job is to take that NZB, pull the pieces down over NNTP (the Usenet protocol), repair anything that arrived damaged using PAR2 files, extract the archives, and drop the finished files in a folder you specify. Sonarr and Radarr can hand it NZBs automatically once it's set up, so from your side the whole thing looks completely hands-off.
Why Would You Use It?
Usenet downloads generally hit close to your full internet connection speed from the first second, because you're pulling from your provider's servers directly rather than waiting on other peers to have what you want. There's no seeding requirement either — once a download finishes, you're done with it, no ratio to maintain and no upload bandwidth tied up afterward.
It isn't free, though. You're paying a monthly fee to a Usenet provider (block accounts or unlimited plans both exist) and often a separate small fee for indexer access, so it's a different trade-off than torrenting. Most people running the full *arr stack end up using SABnzbd and qBittorrent side by side — Usenet as the primary source since it's faster and more consistent, torrents as the fallback when something isn't on Usenet.
If you already have Sonarr, Radarr, or Lidarr running from one of the earlier guides on this site, adding SABnzbd is the natural next piece. It plugs into all of them through a single API key.
Prerequisites
- A working Proxmox VE 8.x or 9.x host with a bit of free CPU, RAM, and disk
- Basic comfort opening an LXC container's console from the Proxmox web UI
- A Usenet provider account (host, port, username, password, and connection limit — you'll get these from your provider's dashboard)
- Optionally, an indexer account if you want NZBs to search automatically instead of downloading them by hand
- About 10–15 minutes
You don't need an indexer to finish this tutorial — SABnzbd will run and accept NZB files you download manually even without one. Wiring up an indexer or connecting Sonarr/Radarr is worth doing afterward, but it's outside the scope of getting SABnzbd itself installed and running.
Step-by-Step Tutorial
Step 1: Grab the Debian 13 container template
SABnzbd's backports package targets Debian 13 (Trixie), so that's what we'll base the container on. From your Proxmox node's shell, make sure the template list is current:
pveam updateThen check what's available and download the standard template:
pveam available | grep debian-13
pveam download local debian-13-standard_13.5-1_amd64.tar.zstThe exact filename shifts as Proxmox refreshes the template index, so copy whatever pveam available shows you rather than typing the version above by hand.
Step 2: Create the container
Click Create CT in the top-right of the Proxmox web UI and work through the tabs:
- General: pick an unused CT ID, a hostname like sabnzbd, and either a root password or an SSH key
- Template: the Debian 13 template you just downloaded
- Disk: 4 GB is enough for the OS and app themselves — your actual downloads should live on a separate, larger mount point, not the container's root disk
- CPU: 1 core. Downloading and unpacking is I/O-bound, not CPU-bound, unless you're regularly pulling large password-protected RAR sets
- Memory: 512 MB is fine for normal use; bump it to 1024 MB if you'll be running several simultaneous downloads with heavy unpacking
- Network: bridge to vmbr0, DHCP or a static IP — a static IP makes life easier later when you point Sonarr/Radarr at this container
Leave "Unprivileged container" checked. SABnzbd has no reason to need root-level access to the Proxmox host, and keeping it unprivileged limits the damage if it ever gets compromised. Finish the wizard and start the container.
If you plan to store finished downloads on a dedicated disk or NFS share rather than inside the container itself, that's a separate step — see the "Add Extra Storage to an LXC Container" and "Mount an NFS Share" guides on this site for how to attach a proper mount point before you go much further.
Step 3: Update the OS and add the backports repository
Open the container's console from the Proxmox UI (click the container, then Console), or SSH in if you set a static IP. Update the base system first:
apt update && apt upgrade -yDebian's own stable repository ships a version of SABnzbd that's usually several years behind — Debian intentionally freezes package versions for stability, which is great for a mail server and terrible for an app that talks to third-party APIs. The SABnzbd project's own installation docs point Debian users at backports instead, so that's what we'll use.
Edit the sources file:
nano /etc/apt/sources.listAdd this line at the bottom, then save and exit:
deb http://deb.debian.org/debian trixie-backports main contrib non-freeRefresh the package index so apt sees the new repository:
apt updateStep 4: Install SABnzbd
Install the package specifically from backports:
apt install -t trixie-backports sabnzbdplusThe -t trixie-backports flag tells apt to pull this one package from backports even though your other sources still point at regular stable — everything else on the system stays on the tested, stable version.
Step 5: Set the service user
The Debian package won't start until you tell it which system user should run it. Open the default config file:
nano /etc/default/sabnzbdplusFind the USER= line and set it to root for the simplest setup inside a dedicated, unprivileged container:
USER=rootRunning as root inside this container is a reasonable trade-off here specifically because the container itself is unprivileged and isolated — it isn't the same as running SABnzbd as root on a real machine. If you'd rather run it as an unprivileged Linux user instead, create one with adduser first and reference that username here, just make sure it has read/write access to whatever download folders you set up later.
Step 6: Enable and start the service
systemctl enable --now sabnzbdplusCheck that it actually came up:
systemctl status sabnzbdplusYou're looking for active (running) in green. If you see failed instead, jump ahead to the Troubleshooting section — nine times out of ten it's the USER= line from Step 5.
Step 7: Run the first-time setup wizard
From a browser on your LAN, go to http://<container-ip>:8080. SABnzbd will drop you straight into its setup wizard the first time it runs. Work through it:
- Pick your interface language
- Enter your Usenet provider details — server hostname, port (usually 563 for SSL, 119 without), your username and password, and the connection count your plan allows
- Set your Temporary Download Folder and Complete Download Folder. If you attached extra storage in Step 2, point these at that mount, not the container's small root disk
- Skip the indexer step for now if you don't have one yet — you can always add it later from Config > Servers
- Finish the wizard
You'll land on the main SABnzbd queue screen, which will be empty until you feed it an NZB. To confirm everything works end-to-end, download any small NZB file from your indexer (or drag-and-drop one manually) onto the queue page and watch it move from downloading to repairing to extracting to done.
Step 8: Connect it to Sonarr, Radarr, or Lidarr (optional)
If you've already got the *arr stack running from earlier guides, open SABnzbd's Config > General page and copy the API key. Paste that key, plus SABnzbd's IP and port 8080, into the Download Client section of Sonarr or Radarr's settings. Test the connection from that side — if it comes back green, you're done, and those apps will now push NZBs to SABnzbd automatically whenever they find a match.
Commands Explained
| Command | What it does |
|---|---|
pveam update | Refreshes Proxmox's local list of available container templates |
pveam download local <template> | Downloads a specific container template to local storage |
apt update && apt upgrade -y | Refreshes the package index, then installs any pending updates without prompting |
apt install -t trixie-backports sabnzbdplus | Installs SABnzbd specifically from the backports repo instead of the older stable one |
systemctl enable --now sabnzbdplus | Sets the service to start on boot and starts it immediately in one command |
systemctl status sabnzbdplus | Shows whether the service is running, and prints its most recent log lines |
journalctl -u sabnzbdplus -n 50 | Shows the last 50 log lines for the service — the first place to look when something's wrong |
Common Errors
| Error | Likely cause | Fix |
|---|---|---|
| E: Unable to locate package sabnzbdplus | The backports line wasn't added correctly, or apt update wasn't rerun after adding it | Double-check the line in /etc/apt/sources.list for typos, then run apt update again before installing |
| Job failed with 535 Authentication failed | Wrong username, password, or the account isn't active yet with your provider | Re-check the credentials in Config > Servers, and confirm the account is active by logging into your provider's own site |
| Service shows "failed" right after systemctl start | The USER= line in /etc/default/sabnzbdplus was left blank | Set USER=root (or a real username) in that file, then run systemctl restart sabnzbdplus |
| Web UI won't load at all | Container has no network, or the service didn't actually start | Run ip a inside the container to confirm it has an address, then check systemctl status sabnzbdplus |
| Downloads finish but Sonarr/Radarr never import them | File permission mismatch between the SABnzbd user and the *arr app's user | Make sure both apps share the same UID/GID, or run both as root inside their own isolated containers |
Troubleshooting
Start with the logs, always. journalctl -u sabnzbdplus -n 50 tells you far more than guessing. If the service refuses to start, the error message almost always names the exact problem — a missing user, a bad permission on the download folder, or a config file it can't parse.
If downloads sit at 0% and never move, that's usually the connection to your Usenet provider, not SABnzbd itself. Go to Config > Servers and click "Test Server." A failed test there rules out everything else — no point troubleshooting extraction settings if SABnzbd can't reach your provider in the first place.
If files download fine but never finish extracting, check that unrar and par2 are actually installed — the backports package should pull them in as dependencies, but it's worth confirming with which unrar par2 if extraction jobs stall.
And if Sonarr or Radarr show the download as complete while the file itself is nowhere to be found, it's almost always a path mismatch. SABnzbd and the *arr apps need to agree on where the Complete Download Folder actually is — if SABnzbd writes to a mount only it can see, Sonarr will happily report success while looking at an empty folder.
Best Practices
- Keep the "Temporary" and "Complete" download folders on the same underlying storage. Moving finished files across storage boundaries makes the last step of every download slower than it needs to be
- Set a connection limit that matches your provider plan exactly — going over it usually gets your extra connections silently dropped rather than sped up
- Turn on SSL for your Usenet server connection if your provider supports it. It's a checkbox in Config > Servers, and there's no real downside to leaving it on
- Take a Proxmox snapshot of the container before any major SABnzbd version upgrade, so a bad update is a one-click rollback instead of a rebuild
- Treat your SABnzbd API key the same as a password — anyone with it can queue downloads through your provider account
- Don't run SABnzbd inside the same container as Sonarr or Radarr just to save resources. Keeping each app in its own LXC container makes troubleshooting and backups far simpler
Frequently Asked Questions
Do I need a Usenet provider and an indexer, or just one of them?
Both, for full automation. The provider gives you access to download the actual files; the indexer is what you (or Sonarr/Radarr) search to find NZBs in the first place. You can use SABnzbd with just a provider and manually-downloaded NZBs, but you'll be doing the searching yourself.
Is trixie-backports safe to add to a Debian 13 system?
Yes. Backports are the same packages built against the current stable release, just newer versions that haven't gone through Debian's full stability testing cycle. Using -t trixie-backports for a single package, as this guide does, keeps the rest of your system on regular stable.
Can I run SABnzbd and qBittorrent in the same container?
You can, but I wouldn't. Each app in its own container makes it much easier to back up, restart, or rebuild one piece without touching the other — and LXC containers are cheap enough on resources that there's little reason to combine them.
How much RAM does SABnzbd actually need?
512 MB handles normal use without issue. The heavier resource cost usually comes from unpacking large archives, not from SABnzbd itself sitting idle.
Why is the package called "sabnzbdplus" instead of "sabnzbd"?
That's just the historical package name in Debian's repositories, left over from an earlier fork. It's the current, correct SABnzbd application either way.
Conclusion
You've now got SABnzbd running in its own container, pulling files over Usenet at whatever speed your provider gives you. The setup itself takes ten minutes; getting your provider and indexer credentials right is usually the part that takes longer. From here, the natural next step is wiring it into Sonarr, Radarr, or Lidarr if you haven't already, so the whole pipeline — search, download, import — runs without you touching anything after the initial request.