qBittorrent permission errors and downloads that never import

Published 12 September 2026 · Updated 18 September 2026 · SparkBox team

Downloads finish inside qBittorrent or SABnzbd, but Sonarr and Radarr never pick them up — or you get a flat-out "Cannot create final folder /downloads/tv/<x>" error. It looks like a broken permission, but in most setups the folders and users are fine. The real cause is usually a wiring gap between your download client and your arr apps, or a missing folder mount that only affects one of the two clients.

Rather not chase wiring scripts and mount paths by hand? SparkBox wires every download client into Sonarr and Radarr automatically, on first setup and when you add one later. See the walkthrough →

Cause 1: Sonarr and Radarr were never told SABnzbd exists

On first setup, a bootstrap script registers your download client with Sonarr and Radarr so they know where to look for finished downloads. That script's client-registration step only ever adds qBittorrent — it does not add SABnzbd, even if SABnzbd is running and healthy. If you turned SABnzbd on after the initial setup, or added it as a second client later, that wiring step doesn't run again on its own. The result: SABnzbd downloads complete perfectly, sit in its output folder, and Sonarr/Radarr never import them because as far as they know, SABnzbd doesn't exist.

1. Open Sonarr, go to Settings > Download Clients, and check whether SABnzbd is listed. Do the same in Radarr.
2. If it's missing, click Add, choose SABnzbd, and fill in its host, port, and API key (found in SABnzbd's own Settings > General).
3. Save, then use the "Test" button in the download client form before closing it — a passing test confirms Sonarr/Radarr can actually reach SABnzbd, not just that the form is filled in.
4. Repeat for the other app if you use both Sonarr and Radarr with SABnzbd.

Cause 2: SABnzbd has no /downloads folder to write to

Look at how the media stack's compose file mounts storage for SABnzbd: it binds a single path (your media root, defaulting to /data) to /data inside the container. There is no separate /downloads mount. If SABnzbd's categories or folder settings are still pointing at the default /downloads/... path — which is common with LSIO-style SABnzbd images — that path simply doesn't exist as a real mounted folder inside the container. It resolves to an unbound, root-owned in-container path, and any attempt to create a final folder there throws a permission error (Errno 13), because the container process isn't root and can't write there.

This is also why the same-looking error rarely shows up in qBittorrent: qBittorrent has a save-path self-heal that runs on startup and automatically rewrites any /downloads path to /data/downloads, matching the real mount. SABnzbd has no equivalent self-heal, so its misconfigured category just fails instead of quietly correcting itself.

1. In SABnzbd, go to Config > Folders and check the "Complete Download Folder" and "Temporary Download Folder" — if either starts with /downloads, change it to the matching path under /data (for example /data/downloads/complete).
2. Go to Config > Categories and check every category's folder field the same way. Any category still using /downloads/... needs updating to /data/downloads/....
3. Save, then trigger a small test download to confirm SABnzbd can create the final folder without an Errno 13.
4. Confirm the corrected path matches whatever path you gave Sonarr/Radarr for that download client's remote path mapping, if you use one, so imports resolve to the same location on both sides.

Cause 3: A doubled media folder and a wall of permission denied

If the finishing step of your media setup was run without elevated privileges (no sudo), two things happen at once: it dies partway through in a long list of "Permission denied" errors, and it can leave behind a doubled folder structure like media/media instead of the single folder layout you expect.

1. Check your media root for a nested duplicate — a media folder sitting inside another media folder is the tell.
2. If you find one, move any real content up out of the doubled folder and remove the empty duplicate.
3. Re-run the media-finish step with the correct privileges this time, rather than as a regular user, so it can actually set ownership and create folders where needed.
4. Re-check your download client folder settings from Cause 2 afterward — a doubled folder structure is a common reason paths that looked correct suddenly aren't.

Cause 4: Seerr requests failing with "quality profile does not exist" after fixing this

If Seerr (a request front-end for Sonarr/Radarr) was seeded before or during the same setup that had this wiring gap, it can be holding onto a quality profile ID that Sonarr or Radarr no longer has. Every request then fails with a "quality profile does not exist" error, unrelated to downloads or permissions directly, but often noticed at the same time.

1. Re-run the scripts/seerr-seed.sh seeding step so Seerr picks up the quality profile IDs that currently exist in Sonarr/Radarr.
2. If that's not available to you, open Seerr's settings for each service (Sonarr/Radarr) and manually re-select the correct quality profile from the dropdown, then save.
3. Submit a small test request afterward to confirm it's accepted before assuming the fix worked.

A quick note on DNS (qbit DNS mismatches)

Some setups also run a network-wide DNS filter or ad-blocker, like Pi-hole, alongside the media stack. That's a separate concern from the permission and wiring issues above, but it's worth ruling out if Sonarr/Radarr can't reach qBittorrent or SABnzbd by hostname at all — as opposed to reaching them fine but failing to import. If a "Test" button in the download client settings can't connect at all, check that the hostname you're using actually resolves on your network before digging further into permissions.

Frequently asked

Why does qBittorrent (or SABnzbd) say permission denied creating a downloads folder?

It's usually not a broken file permission at all. If the client's container doesn't have the folder you're pointing it at actually mounted, the container falls back to an unbound, root-owned path inside itself, and any regular process gets a permission error. Point the client at a path that's actually mounted instead of adjusting file permissions.

Do I need to fix qBittorrent's file permissions manually?

Usually no. qBittorrent has a built-in save-path self-heal that rewrites /downloads to /data/downloads automatically on startup, so it rarely hits this on its own. SABnzbd has no equivalent, which is why the same-looking error tends to show up there instead.

Why didn't SABnzbd show up as a download client in Sonarr and Radarr automatically?

The setup script that wires a download client into Sonarr and Radarr only registers qBittorrent, and only runs once, at first setup. If SABnzbd was enabled afterward, it has to be added by hand in Settings > Download Clients on both apps.

Can a DNS setup like Pi-hole cause qBittorrent connection problems?

It can look similar from the outside, but it's a separate issue from the wiring and folder-mount problems covered here. If Sonarr/Radarr can't reach the download client at all, check hostname resolution before assuming it's the same root cause.