Sonarr / Radarr "Root Folder Not Writable" (or "Missing Root Folder") — How to Fix It

You go to add a root folder in Sonarr or Radarr and it throws "Folder is not writable by user abc" — or it accepts the folder but later every download fails to import with "Missing root folder: /data/TV." Both come down to the same two things: permissions and paths. Here's exactly what's happening and the four fixes in the order to try them. This applies to any Docker-based setup — we run the *arr stack ourselves, so the examples are real.

Don't want to hand-tune permissions across four containers? SparkBox installs the *arr stack pre-wired — one shared media root, one matched user, and it re-heals these permissions on every start, so this error never reaches you. See the media-server walkthrough →

First, which error are you getting?

They look similar but point at different problems:

• "Folder is not writable by user abc" (when you add the root folder) → a permissions problem. The folder is there; the container user can't write to it. Go to Fix 1 and 2.
• "Missing root folder: /data/TV" (later, on import, often silent) → a path problem. Sonarr's saved root folder doesn't resolve to a real mounted directory. Go to Fix 3.

Fix 1 — Match PUID/PGID to whoever owns your media

The linuxserver.io images that most people run Sonarr/Radarr from drop privileges to a user defined by two environment variables, PUID and PGID. If those don't match the owner of your media folders, the container can't write — and you get "not writable."

On the host, find the uid/gid that owns your media:

id youruser
# uid=1000(youruser) gid=1000(youruser) ...

ls -ln /path/to/media
# the numbers in columns 3 and 4 are the owning uid:gid

Then set PUID to that uid and PGID to that gid in your Sonarr and Radarr containers (and your download client — they all need to agree), and recreate the containers. The rule that saves the most pain: every app that touches the media — Sonarr, Radarr, your download client — should run as the same PUID/PGID. Mismatched ids between the downloader and the *arr app is the single most common cause of "it downloads but won't import."

Fix 2 — Make the folder actually owned by that user

Setting PUID/PGID only helps if the folder is owned by (or group-writable to) that id. Fix the ownership on the host:

sudo chown -R 1000:1000 /path/to/media
sudo chmod -R 775 /path/to/media

Replace 1000:1000 with your real uid:gid. The 775 gives the owner and group write access. Re-add the root folder in Sonarr; the "not writable" error should be gone.

Fix 3 — Make the in-container path resolve to a real folder ("Missing root folder")

Sonarr only ever sees the path inside the container. If your bind mount is /host/media:/data, then Sonarr's root folder /data/TV is really /host/media/TV on the host. "Missing root folder: /data/TV" means that host folder doesn't exist (often because you moved or renamed your media root and the mount now points somewhere empty).

1. Confirm the mount in your compose file (volumes:) — note the host path on the left of the colon.
2. Make sure the subfolder Sonarr expects actually exists on the host: mkdir -p /host/media/TV (and /Movies for Radarr).
3. Critically — use the same mount layout for the download client and the *arr apps. If qBittorrent saves to /downloads but Sonarr expects /data/downloads, imports can't hardlink and either fail or do a slow copy. The fix is one shared mount (e.g. everything under a single /data) so completed downloads and the library live under the same root.

Fix 4 — Check the mount isn't read-only

If a volume is mapped with a trailing :ro (read-only) in your compose file, Sonarr can see it but never write to it — "not writable," no matter what the permissions say. Remove the :ro from the media volume for any app that needs to move files into it, and recreate.

Why this is so fiddly (and the lazy way out)

None of the four fixes is hard on its own. The reason this error eats whole evenings is that all four have to be right at once, across three or four containers that each have their own PUID/PGID and volume mounts, and a single mismatch anywhere reproduces the exact same error message. Get the downloader's uid right but not Radarr's, and you're back to square one.

This is exactly the kind of plumbing a turnkey setup does for you. SparkBox binds one shared media root into every app, runs the whole stack under a single matched PUID/PGID, and re-heals the ownership of the media and *arr config folders on every start — so the "not writable / missing root folder" class of error is handled before you ever see it. If you'd rather not hand-tune permissions across four containers, that's the shortcut; if you're learning the stack, the four fixes above are the real education.

Frequently asked

I fixed the permissions but it still won't import — why?

Almost always a path mismatch between your download client and the *arr app (Fix 3), or different PUID/PGID between them (Fix 1). The download completes, but the *arr app can't see it at the path it expects, or can't write the imported file. Make the mounts and the ids identical across the downloader, Sonarr and Radarr.

Should I just run everything as root (PUID=0)?

It'll "work," but it's a bad habit — root-owned media files cause permission problems for every other app that touches them later, and it's an unnecessary security exposure. Match a normal user's uid/gid instead.

Does this apply to Lidarr, Prowlarr and Bazarr too?

Yes — same images, same PUID/PGID and path rules. Anything in the *arr family follows the identical pattern, as does the Jellyseerr request layer that sits on top.