Last updated Oct 15, 2026
Lessons Learned#
Real issues that came up during setup and what solved them.
Path consistency is the most common failure point#
The single most frequent problem during initial setup: Sonarr, Radarr, and SABnzbd all need to see the same paths inside their containers. Even if the physical files are in the right place, a path mismatch causes imports to fail silently with no useful error.
The fix is to use the same volume mounts across all containers and test with a manual download before trusting the automation.
Permissions break everything, quietly#
When the config directories on the host are owned by root instead of 1000:1000, services start and appear healthy but fail when they try to write anything. Setting PUID=1000 PGID=1000 in the Docker environment is not enough if the host directory is wrong.
Always create config directories explicitly and set ownership before first run:
mkdir -p /srv/media-stack/config/{sonarr,radarr,prowlarr,sabnzbd,seerr}
chown -R 1000:1000 /srv/media-stack/config/Keep downloads and media on the same filesystem#
Putting downloads and media on separate disks (or separate filesystems, e.g. ext4 for downloads and ZFS for media) means Sonarr and Radarr fall back to copy+delete during import — doubling disk I/O and taking much longer.
For Usenet, the arr apps use a move (rename), not hard links. Hard links are torrent-only. But even a move becomes a copy+delete when crossing filesystem boundaries. Keeping everything on the same filesystem keeps imports fast.
Plex LXC vs Docker#
An early version of this setup ran Plex inside Docker alongside the other services. This worked but caused GPU passthrough to be complicated and tied Plex's availability to Docker restarts.
Moving Plex to a dedicated LXC solved both problems. The LXC has direct access to storage via bind mounts, and GPU passthrough is handled at the Proxmox level with a few config lines.
A silent auto-update is the worst kind of broken#
My Plex container had a daily cron job that upgraded the package, and the log said "plexmediaserver is already the newest version" every night. For three weeks that was wrong. Plex had published a newer version to its repository on September 10, 2026, and the container stayed on the old one until I fixed it on October 2.
The job only ran apt-get install --only-upgrade, which never refreshes the package lists. I had assumed the system's daily apt timer did that. In this minimal Debian LXC container the timer ran and reported success, but it did nothing, because no periodic apt settings were configured and every interval defaulted to zero. The tell was in the filesystem: the package list files for the Plex repository still had a modification time from weeks earlier.
The fix was to run apt-get update inside the same cron job, so it no longer depends on anything else. The takeaway is general: a job that logs "nothing to do" is only trustworthy if you know it looked at fresh data. See Updates for the working job.
Client updates can break a working setup#
The server side of this stack was stable for months, but a client app update on Apple TV and Android TV in autumn 2026 removed settings and broke playback features I relied on. Nothing on the server had changed.
The fix is to treat client apps like any other dependency: turn off automatic updates on devices the household depends on, update one device first, and know how to roll back before you need to. The steps are in Updates.
Have something to add? This page is a living document.