Why I Ditched TrueNAS for Plain Linux and Got 2.5GB of RAM Back

When I built my home server, everyone told me a NAS needs a NAS operating system. For years, I believed them. TrueNAS 25.10 ran my box, and I understand why so many people stick with it. But then I looked at my dashboard and saw 3.2GB of my 8GB of RAM gone before a single file moved.

With memory prices still painfully high, buying new hardware felt like the wrong fix. So I installed plain Debian 13, added Cockpit as my browser dashboard, and never looked back. Three weeks in, my server does more with less, and the trade-off was worth every minute of setup.

TrueNAS Wants 8GB Just to Run Itself

TrueNAS isn't heavy by accident. Its own hardware guide asks for 8GB of RAM as the baseline, because the middleware, the web UI, the apps system, and ZFS all share one memory pool. On my repurposed desktop with two 4TB WD Red Plus drives in a mirror, that left ZFS almost no room for its read cache, which is what makes a NAS feel fast. Every time I opened the dashboard, that memory bar made me a little grumpy.

I'm not the only one who noticed. A colleague who tested TrueNAS against Unraid and ZimaOS called that 8GB floor a pretty high number in the middle of the RAM apocalypse, and I felt that in my wallet.

The other wall was apt. TrueNAS is built on Debian, but try to install a package from the shell, and you get a flat refusal: Package management tools are disabled on TrueNAS appliances. I get why, since it's an appliance and iXsystems doesn't want people breaking it and then filing bug reports. Still, I just wanted restic for off-site backups, and the answer was always to wrap it in an app.

How to Move a TrueNAS ZFS Pool to Debian with Cockpit

The scary part was one command. I saved the TrueNAS config file, exported the pool, and installed Debian 13 with no desktop, just SSH and the standard system utilities. ZFS lives in Debian's contrib repo, and trixie-backports currently carries OpenZFS 2.4.3, which is newer than the 2.3.4 that shipped with TrueNAS 25.10. One zpool import tank later, my 3.6TB of photos, work files, and Linux ISOs I swear I'll use someday showed up exactly where I'd left them. I may have exhaled aloud.

Export the pool from TrueNAS before you wipe anything, and keep a copy of the config file off the server. If the move goes sideways, you can reinstall TrueNAS and import everything back.

Install Cockpit from Debian's backports to get the newest release: sudo apt install -t trixie-backports cockpit cockpit-podman cockpit-machines. The dashboard then lives at port 9090 on your server.

Cockpit itself is a one-line install, and the plugins do the NAS part. 45Drives' cockpit-file-sharing manages Samba and NFS shares (it handles iSCSI and S3, too), cockpit-podman runs containers, and cockpit-machines handles virtual machines. Rebuilding my four SMB shares and one NFS export took about 15 minutes, mostly because I renamed one share halfway through and then forgot which name I'd picked.

If you're turning an old PC into a NAS from scratch, this is the same flow minus the import. You pick the drives, build the pool, and share it from the browser.

Cockpit vs. TrueNAS Memory Use on the Same Hardware

The trick is that Cockpit barely runs. It starts on demand through socket activation, so when nobody's logged in to the dashboard, it isn't running at all. Everything it shows is the real system, meaning the same services, logs, disks, and containers I'd touch from the terminal. Close the tab, and the server goes back to being a quiet Debian box.

The first time I opened Cockpit's Overview page after the switch, the memory graph sat so low that I assumed it was broken. I refreshed it three times, then checked free -h in the terminal just to be sure. It wasn't broken. That's just what an idle Debian server looks like.

That freed memory went straight to work. Jellyfin, Syncthing, and Uptime Kuma now run as Podman containers, and a 2GB Home Assistant VM lives in cockpit-machines. On TrueNAS, running that VM alongside two apps pushed the box into swap. Here, ZFS still gets about 3.4GB for its cache with everything running.

Even the boring jobs moved into the browser. Since Cockpit 356, the Services page can create systemd timers that run shell commands, so my nightly snapshot and the restic backup to a friend's server are two timers I can edit without opening a terminal.

My Mac's Backups Were the One Thing That Broke

Two days in, my MacBook Air M2 stopped seeing its Time Machine share. TrueNAS had quietly been setting up Apple's extras for me, and plain Samba doesn't. The share needed vfs objects = fruit streams_xattr and fruit:time machine = yes, and the server needed avahi-daemon so the Mac could find it on the network. cockpit-file-sharing has an advanced settings box for exactly this, so the fix took five minutes once I knew. Figuring that out turned into a whole evening's side quest.

That's the real catch. TrueNAS has polish I didn't notice until it was gone, like snapshot tasks, replication, and alerts that email you before a drive dies. Debian does ship a monthly ZFS scrub out of the box, but alerts are on you. I set up smartd and the ZFS event daemon to email me, and it works, but nobody's holding my hand anymore. If the box breaks at 2 a.m., the support team is me.

So if you want an appliance, TrueNAS is still the right call, and even a home lab built around VMs has better options like Proxmox. Plain Linux suits a small box that does a bit of everything, and for my box, the trade paid off in the first week.

Plain Linux Was the NAS OS I Needed

I expected to miss TrueNAS more than I do. That 3.2GB idle number that started all this is now 640MB, and the box I almost replaced runs more than it ever has. Scrolling the photo library from my phone feels snappier, too, since ZFS finally has room to cache.

If you're comfortable in a terminal and your NAS lives on modest hardware, plain Debian with Cockpit is worth a weekend. Just set up Time Machine before your Mac notices.