I’ve had a home NAS for a while now, a little UGREEN box running the usual media stack in Docker. It has handed me a handful of memorable problems, and when I lined them up they had a common thread: the NAS itself was rarely what had broken. The cause was almost always something I’d done to it.
Every real problem traces back to something I added, changed, or chose, usually for a reason that felt sensible at the time. The box mostly sat there doing its job while I made work for myself. Three stories, mostly because they turned out to be the same lessons I write about for actual work, showing up at home.
Putting the Transcode Folder in RAM
At some point I decided Jellyfin’s transcode folder should live in RAM. A tmpfs mount, four gigabytes, nice and fast, very clever of me. Then films started cutting out partway through, or just kicking me back to the details screen.
The transcode directory was sitting at a suspiciously round 4.0 of 4.0 gigabytes. I’d capped it at 4GB of RAM and, separately, left Jellyfin’s segment cleanup switched off, so every transcoded film simply accumulated in that little RAM disk until it hit the ceiling and ffmpeg could no longer write the next chunk. Right in the middle of a movie, the stream would die.
The fix was deleting the tmpfs line. Take out the clever thing, let transcodes live on the array the way they would have by default, and the problem evaporated. The whole episode was me adding a moving part the setup never needed. The deeper cause was even more self-inflicted: it was transcoding so eagerly in the first place because I’d left tone mapping turned on for a TV that handles HDR perfectly well on its own. More configuration I’d added, quietly doing damage. It’s the same thing I keep getting at in A Case Against Abstraction: the urge to add structure so you feel in control, when the structure is the thing causing the trouble.
Debugging My Way Into a Crash Loop
I added a small container to the stack one evening. Harmless little thing. Right afterward, qBittorrent’s web interface went dark.
So I started digging, and this is the part I’m not proud of: the digging is what actually broke it. I changed a volume path based on something I half-remembered, added a user setting that turned out to cause permission errors, and force-killed containers a few times along the way. By the time I found the real cause, it was a stale lock file and socket that my own messy restarts had orphaned. qBittorrent saw them on startup, concluded another copy of itself was already running, and shut itself down one second after every launch. A tight little crash loop that I had personally been feeding.
The actual fix was deleting two files. The lesson was older than the NAS: when something breaks, changing five things at once to find the cause just leaves you with five new things to debug. The slow, one-change-at-a-time discipline I happily preach for large refactors is exactly what a panicked Saturday-night fix needs, and exactly what I threw out the moment it was my own media server on the line.
Almost Buying the Wrong Drive
I wanted to put a WD_BLACK SN850X in it. A gaming drive, 7,300 MB/s, the sort of part that’s genuinely satisfying to own.
It was the wrong choice on every axis that mattered. The NAS talks to the network over 2.5 gigabit, which caps real throughput around 312 MB/s, so seven thousand megabytes a second is meaningless the instant a file leaves the box. The drive’s chunky gaming heatsink wouldn’t even fit the NAS’s toolless M.2 slots, which have their own thermal pads. And it isn’t built for the sustained 24/7 write pattern a NAS actually puts a drive through. The boring, correct answer was a WD Red SN700: slower on paper, right form factor, right endurance, considerably less exciting.
I caught myself reaching for the interesting part instead of the fitting one, which is the same trap I described with state libraries: interesting is a real reason people pick technology and a poor one to pick it on. Same instinct, different shelf.
The Pattern
Lined up next to each other, the three are the same failure modes I try to catch at work. Adding complexity because it felt smart. Debugging without discipline. Choosing the exciting option over the correct one. At work, those hide behind process and reviews and enough scale that the cause is rarely just one person. At home it’s me and a small box that was running fine until I got involved, which makes the source easy enough to identify.
I’ll be fair to the other side, though, because a homelab is also the one place where adding complexity is the whole point. You run things you don’t strictly need precisely so you can learn how they break, and “just buy a prebuilt and never touch it” would be safer while missing the entire reason I own the thing. So the takeaway isn’t run less or want less. It’s knowing which mode you’re in: a sandbox you’re poking at to learn, or a server the household expects to just work. The mistake, all three times, was treating the second like the first, on the one machine that holds movie night.
The NAS keeps teaching me the thing my own code does, just with cheaper consequences. Most of the trouble I get into is trouble I built, and more often than not the fix is to take something out rather than pile something else on top. So the next time your setup breaks right after it had been working fine, the most useful question probably isn’t what’s wrong with it. It’s what did you change.