"My NAS Is Out of RAM and My Download Is Stuck" — Two Homelab Myths, Debunked

- 5 minutes read - 1018 words

Two things happened on the same day that looked like problems and weren’t — at least not the problems they appeared to be. My NAS was reporting almost all its RAM in use, which sounds like a leak or an imminent crash. And a TV show I’d grabbed through LunaSea on my phone had downloaded fine but then “wouldn’t import” into the library, which sounds like a broken automation pipeline.

Both are among the most common false alarms in a self-hosted media stack. Neither was what it looked like. Here’s what was actually going on, and the real fixes.

Myth 1: “The NAS is using all its RAM — something’s wrong” #

The box is an HP ProLiant MicroServer Gen8 running ZFS (myzpool, a 3-way mirror), serving media over SMB. free -h showed almost all 8 GB consumed, and the instinct is to hunt for a memory leak.

There’s no leak. That’s ZFS’s ARC (Adaptive Replacement Cache) doing exactly its job. ZFS uses free RAM as a filesystem cache — by default up to ~50% of system memory — to keep hot metadata and data in memory instead of hitting spinning disks. “Used” RAM here is working RAM, not leaked RAM. The proof is in the numbers that actually matter:

No OOM kills. No swapping (si/so = 0). load ~0.15. ARC capped at 3.85 GiB (50% of 8 GB).

No out-of-memory kills, zero swap activity, trivial load. The box is healthy. ZFS filled the cache because empty cache is wasted cache. A NAS that reports lots of RAM “used” by ARC is working correctly, not failing.

Where more RAM does help (and where it doesn’t) #

Since the RAM was a talking point, I mapped what upgrading would actually buy — because the honest answer is nuanced:

  • It does NOT speed up single large file transfers. Copying a 12 GB movie is wire-limited (~118 MB/s on 1 GbE) and the 3-way mirror already reads faster than the wire. The movie won’t fit in ARC and is read once, sequentially — cache can’t help. More RAM changes nothing here.
  • It DOES speed up directory listing and library scans. Browsing a folder makes the server read filesystem metadata (ZFS dnodes). With a bigger ARC, more of that metadata stays cached. After going 8 → 16 GB, ARC grew from ~3.85 GB to ~7.78 GB, and directory browsing / Sonarr-Radarr-Immich scans got noticeably snappier.

So the upgrade was worth it — for the right reason (metadata caching / responsiveness), not the wrong one (single-transfer throughput). And an SSD as L2ARC would have been actively harmful at 8 GB, because its index consumes ARC RAM; only worth considering after you’re at 16 GB and only for random/repeat reads, not read-once media.

The bonus catch: SMB “search” is a client-side crawl #

A related complaint was that searching the share from a macOS file browser was painfully slow. That’s not the NAS’s fault either: SMB has no server-side search. A client “search” recursively walks every folder, one network round-trip per directory — over a 16 TB tree that’s thousands of latency-bound round-trips. The fixes are all client-side: use a native-SMB tool (Finder, or Mountain Duck which caches directory listings), or run locate/mlocate on the server for instant search. More RAM helps the listing via metadata caching, but no amount of server RAM adds a search feature SMB doesn’t have.

Myth 2: “The download finished but won’t import — the pipeline is broken” #

The show was Stephen King’s Golden Years (a 1991 miniseries). I’d grabbed episodes manually through LunaSea; SABnzbd downloaded them fine; then they sat there, unimported, and the library stayed empty. Looks like a broken *arr pipeline.

The pipeline was fine. The problem was name matching. Here’s the mechanism:

  • The release names parsed to something like “Stephen Kings Golden Years”.
  • My Sonarr series was titled “Golden Years (1991)”.
  • Because I’d grabbed them manually via LunaSea, the download was associated by series ID, so Sonarr knew which show it belonged to — but its automatic import matcher couldn’t reconcile the release title against the series title, so it wouldn’t auto-file them.

That’s the whole bug: an ID-linked grab whose name doesn’t match the series, so auto-import stalls. The fix was a manual import (Sonarr correctly filed all 7 episodes into Golden Years/Season 1/ E01–E07 once told to), and clearing the equivalent stuck item from the Radarr queue.

The systemic prevention #

The general rule: *any series whose scene/release name differs from your arr title — an author/franchise prefix, an abbreviation, a year mismatch — will hit this. The durable fix is to add alternate titles in Sonarr/Radarr for shows with quirky naming, so the matcher recognizes the release-name form. Manual grabs through a phone app are the most common trigger, because they bypass the indexer-side matching that a normal automatic grab would have done.

I verified the fix the same way I diagnosed it — straight against the APIs rather than clicking around:

# confirm the episodes actually landed
curl -s -H "X-Api-Key: $SONARR" \
  "http://localhost:8989/api/v3/episodefile?seriesId=60" \
  | python3 -c "import sys,json; print(len(json.load(sys.stdin)), 'files')"
# → 7 files; queue now empty

Takeaways #

  • A ZFS NAS reporting lots of “used” RAM is healthy — that’s ARC caching. Look at OOM kills and swap (si/so), not the used column, to judge memory pressure.
  • More NAS RAM speeds up directory listing and scans, not single-file transfers (those are wire-limited). Upgrade for the right reason.
  • SMB has no server-side search — a slow “search” is a client-side directory crawl; fix it with a caching client or server-side locate.
  • “Downloaded but won’t import” is usually name-matching, not a broken pipeline — especially for manual phone-app grabs where the release name ≠ your *arr series title.
  • Add alternate titles for oddly-named shows to prevent the stall recurring.
  • *Diagnose arr issues via the API — episodefile, queue, and command endpoints tell you the truth faster than the web UI.

Both “problems” were the system behaving correctly and me misreading it. In a homelab, that’s the majority of them — the skill is knowing which numbers actually indicate trouble.