# Lessons Learned

> Things that went wrong during the setup and what fixed them.

# 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:

```bash
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](/docs/home-server/media-automation/operations/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](/docs/home-server/media-automation/operations/updates).

---

*Have something to add? This page is a living document.*