Fair warning: This post is approximately 10 minutes long. longer than my usual. I’m experimenting with documenting my learning process in real-time, including mistakes. Most tutorials show you the clean path. I’m showing you the messy one because that’s what actually happened, and it might help someone else avoid the same pitfalls.
By 2023, the old Subsonic/Plex box was long gone. But the desire to self-host, to own my infrastructure, had only grown stronger.
I’d had hard drives fail and lost data to corrupted backups. Worse still, I was becoming increasingly dependent on big tech clouds. Paying more each month as my Google Drive grew, chafing at both the cost and the uncertainty of what corporations might do with my family photos and files.
I also wanted a space where I could build and test things. As I explored building projects online, I kept coming across posts that said, “Just run it in Docker.” I had no idea what that meant, but I knew I needed a dedicated environment for experimentation.
I wanted to build something more robust, redundant, and repairable. Something I understood from the ground up.
So I started scavenging again.
The Hunt for Hardware
This time, I wasn’t buying shiny new components. I wanted to learn by rebuilding. To understand modern virtualization, storage pools, and data resilience the same way I’d once learned about port forwarding and metadata management with the old Vaio.
The Metal Box
In December 2023, I found my anchor: a custom-built desktop on ShopGoodwill**,** featuring an Intel Core i7-3770, 32 GB of RAM, and a 250 GB SSD, all running Linux, for $73.50.
Yep. Bargain basement. My thinking was that I had some parts from old machines lying around. I could buy a case, motherboard, CPU, and other parts separately. But if I bought something that worked or just needed repairs, it would give me a solid starting point to cobble together a machine.
The listing photos showed a bulky, army green case covered in vented panels and scuffs. It looked like something salvaged from a decommissioned military lab or pulled from a server room in a forgotten basement. Unlike the beige Sony Vaio that had quietly hummed in my home for years, this machine had an industrial look. Heavy. Purposeful.
I started calling it The Metal Box.
The i7-3770 (Ivy Bridge, circa 2012) was already several generations old, but for a homelab running VMs, storage services, and automation, it was more than capable. I didn’t need cutting-edge performance. I needed something:
- Stable enough to run 24/7
- Cheap enough that I could experiment without fear
- Flexible enough to grow with my needs
That $73.50 Goodwill desktop became the foundation of everything that followed.
Scavenging Storage
To expand capacity, I turned to the internet’s secondhand markets.
eBay Drives (With Reddit’s Blessing)
I found a seller on eBay who was frequently recommended in r/homelab and r/datahoarder threads. They specialized in refurbished**, enterprise-grade hard drives** , sourcing them from decommissioned data centers that still had years of life left.
I ordered a set of 12 TB HDDs from them. Because other homelab builders vouched for the seller’s testing process and low failure rates, I felt confident in the risk/return tradeoff. These became the backbone of my storage pool.
Local Finds on Facebook Marketplace
I also grabbed a few drives locally, meeting folks who were clearing out old server builds or downsizing their home setups. Some were pulled from retired NAS boxes; others were consumer-grade drives that had been sitting unused in closets.
Every drive got the same treatment before integration:
- Full SMART diagnostics
- Extended sector scans for bad blocks
- Burn-in testing under load
By mid-2024, I had four 12 TB drives in usable condition. A respectable array for a homelab built on scraps and patience.
With the Metal Box populated and drives tested, it was time to transform this pile of parts into actual infrastructure.
Building the Foundation: Proxmox + TrueNAS
With the hardware assembled, I started the real work: learning how to build a modern, virtualized storage system.
1. Installing Proxmox VE
Why Proxmox? (The Magic Apartment Building)
I installed Proxmox Virtual Environment on the 250 GB SSD. Proxmox Virtual Environment is a virtualization platform designed for the provisioning of hyper-converged infrastructure.
In simpler terms, Proxmox is like a magic apartment building for computers.
You know how one large apartment building can have numerous families living in separate apartments? Proxmox does that, but with computers.
Instead of buying 10 different physical computers to do 10 different jobs, you can:
- Buy ONE powerful computer (the Metal Box)
- Install Proxmox on it
- Use Proxmox to create pretend “mini-computers” inside it (we call these “virtual machines” or VMs)
Each mini-computer thinks it’s a real, separate computer. One might run your media server (Plex), another might handle your cloud storage (Nextcloud), and another might manage your home automation (Home Assistant).
Why is this useful?
Instead of having 10 boxes plugged in, using electricity, taking up space, and making noise, you have ONE box doing the work of many. It’s like fitting an entire neighborhood into one building.
Proxmox is the “building manager” that makes sure:
- Each apartment (VM) has its own space
- They don’t mess with each other
- You can easily create new ones or delete old ones
- Everything runs smoothly
In my homelab: The Metal Box is the building, Proxmox is the manager, and things like TrueNAS, Plex, and Home Assistant are the tenants living in their own apartments.
Keeping the hypervisor separate from data storage was critical. I wanted to be able to experiment, break things, and rebuild without jeopardizing my files.
I spent weeks learning the interface, spinning up test containers, and figuring out how networking, storage, and resource allocation worked. Every configuration file I broke taught me something new about how Linux systems talk to each other.
2. Virtualizing TrueNAS
The big question was: how do I manage my storage pool?
After reading through forums, Reddit threads, and Proxmox documentation, I settled on running TrueNAS Scale as a VM inside Proxmox , with the four 12 TB drives passed through directly to TrueNAS using PCI passthrough or disk ID mapping.
TrueNAS is like a super-smart librarian for all your digital stuff.
Imagine you have thousands of family photos, movies, and important documents. You could just throw them all in a big pile on the floor, but that would be messy, and if something happened (like a flood), you’d lose everything.
TrueNAS is like hiring a really careful librarian who:
1. Organizes everything neatly
- Keeps your photos in one section, movies in another, documents in another
- Makes it easy to find what you need
2. Makes backup copies automatically
- Remember how I lost music when the hard drives in my old Vaio failed?
- TrueNAS uses a special file management system called ZFS, which is like making photocopies of every important page
- If one hard drive breaks, TrueNAS says, “No problem, I have another copy!”
3. Lets everyone in the family access files
- Mom can see the family photos on her laptop
- Dad can stream movies to the TV
- Kids can grab their homework files from their tablets
- All from the same “library”
In my homelab, I installed TrueNAS on four large hard drives (each with 12 TB of storage, enough space for approximately 3,000 movies). TrueNAS is designed so that even if two drives fail simultaneously, I won’t lose any data. It’s like having multiple backup librarians who all have copies of the important books.
The cool part? TrueNAS runs inside one of Proxmox’s “apartments” (a VM), so it’s a librarian living in the apartment building!
This approach gave me:
- ZFS management by TrueNAS (the experts)
- SMART monitoring and health checks are handled automatically
- ACL and permissions managed through TrueNAS’s web interface
- Snapshots and replication are built into ZFS
I experimented with different pool configurations:
- ZFS mirror (two mirrored pairs) for faster rebuilds and better random IOPS
- RAIDZ2 (double parity) for better protection against drive failures
Eventually, I opted for RAIDZ2 for the safety margin. I didn’t want to lose irreplaceable family photos and media due to a double drive failure. The usable capacity was lower than a simple stripe, but the peace of mind was worth it.
Let ‘s Pause for a Progress Check
At this point, I had:
- The Metal Box running Proxmox
- TrueNAS VM managing four 12 TB drives in RAIDZ2
- A solid foundation, but zero services are running yet
- Permission to break things and learn
Okay, let’s keep going.
3. Mistakes I Made (And Learned From)
I ran headlong into permission problems trying to share files between TrueNAS and other services.
Here’s the issue: imagine you have a filing cabinet with three different locks on it. Each lock has its own key, and all three locks have to agree before you can open a drawer:
- Linux permissions (lock #1) — basic rules about who can access files
- POSIX ACLs (lock #2) — more detailed permission rules
- ZFS ACLs (lock #3) — even more detailed filesystem-level rules
When I tried to share files from TrueNAS to my Plex server, all three “locks” had to agree. But they were speaking slightly different languages and kept disagreeing with each other.
I’d get cryptic error messages like:
_Error: Named POSIX ACL entries require a mask entry
”`
Translation: “I need more information before I can let anyone in."
"`
Default ACL entries are required in order to apply ACL recursively_
Translation: “You haven’t told me what to do with files in subfolders.”
I spent hours rebuilding datasets and permission structures until all three systems were in agreement. It felt like trying to get three different bureaucrats to stamp the same form. Each one insists on slightly different paperwork.
The lesson? Permissions in Linux aren’t just about “can this user access this file?” When you add network shares and ZFS into the mix, you’re juggling three different permission systems that all need to be in sync.
Bind Mounts vs Symlinks
I needed my containers to access files stored on TrueNAS. Think of it this way: I had a storage closet (TrueNAS) and needed my different rooms (containers) to access the items inside.
I tried using symlinks (shortcuts)—like putting a sign on the wall that says “the real files are over there →”
Bad idea.
Some containers could view the files but were unable to write to them. Others couldn’t see them at all. It was like some rooms could see the sign but couldn’t actually reach the closet.
I eventually learned to use bind mounts instead, which is like cutting a door directly from each room into the storage closet. Suddenly, everything could access the files reliably.
The lesson? In Linux, there’s usually a “right way” to do things. Shortcuts and workarounds may seem clever, but they can cause problems later.
Pool Recreation (Or: How I Accidentally Deleted Everything)
I wanted to add a fifth hard drive to my storage pool. Simple, right?
Wrong.
I thought I was clicking “add drive to existing pool.” Instead, I accidentally clicked something that meant “create a brand new pool and erase the old one.”
Picture this: You have four drawers, each containing its own unique contents. You want to add a fifth drawer. But instead of adding it to the same dresser, you accidentally throw out the old dresser and start over with a completely new one.
That’s what I did.
Fortunately, this was still during the testing phase. No family photos or critical files were lost. Just my pride.
The second time around, I wrote down every single step in my Obsidian notes and took ZFS snapshots (automatic backup copies) before making any changes. That careful documentation saved me multiple times when later experiments went wrong.
The lesson? Documentation isn’t optional. Your future self, the one troubleshooting at midnight six months from now, will thank you for writing down what you did and why you did it.
Organizing the Homelab
Over time, the Metal Box evolved from a single-purpose storage server into a small ecosystem of services.
Core Services
- Plex — reborn again, now with proper hardware transcoding and organized library management
- Jellyfin — a more open-source media library management tool that I’m using more than Plex
- Nextcloud — personal cloud storage replacing Dropbox and Google Drive
- Home Assistant — automation experiments and smart home integration
Supporting Services
- Scrypted and Frigate — for home security cameras (more on this in a future post)
- HD Homerun — a DVR for the antenna I installed to grab local over-the-air TV
- Ollama — running AI models locally instead of relying on cloud services
Each service taught me a new layer of systems thinking: networking, security, resource allocation, backup strategies, and how to balance convenience with control.
Lessons Learned (So Far)
Looking back at two years of building, breaking, and rebuilding, a few principles have crystallized:
1. Slow Building = Deep Learning
Each configuration mistake was a hands-on lesson in Linux, ZFS, and virtualization. The frustration was the pedagogy. Reading documentation is valuable, but nothing teaches like fixing something you accidentally broke at 11 PM on a Tuesday.
2. Used Hardware is Perfect for Learning
The low stakes removed the pressure to “get it right the first time.” I could experiment freely because I hadn’t invested thousands of dollars. A $73 Goodwill box and refurbished drives gave me permission to fail.
When you’re learning, cheap hardware is an asset, not a limitation.
3. Storage Planning is Everything
Organizing drives early and naming directories and datasets logically prevented endless confusion later. Good naming conventions are a kindness to your future self.
I learned to use descriptive names like /mnt/tank/media/movies instead of /mnt/disk1/stuff because six months later, “stuff” means nothing.
4. Expect to Rebuild
You will break things. That’s not failure. It’s how you learn to truly understand the system. Every rebuild makes you more confident and faster at diagnosing problems.
The advantage of using Proxmox and virtual machines, having backups, and documenting your work is that you can quickly spin up a new machine and get back to work.
The key is building in ways that make rebuilding safe: maintaining good backups, clear documentation, and separating your OS from your data.
5. Documentation is a Gift
I started keeping detailed notes in Obsidian about every major configuration change, every problem I solved, and every mistake I made. I documented everything and utilized AI tools (ChatGPT and Claude) to troubleshoot, building a personal knowledge base that enabled me to identify when AI agents suggested the same mistakes I’d already made. (I’ll dive deeper into this workflow in my “Director’s Cut” meta-series.)
When something broke six months later, those notes were worth their weight in gold.
Your future self will thank you for writing down not just what you did, but why you made that choice.
What’s Running Now
The Metal Box still hums quietly in the corner of my office, its drives spinning like a living archive of my digital life.
Current Setup
- Proxmox host: 250 GB boot SSD, managing VMs and containers
- TrueNAS VM: Four 12 TB drives in RAIDZ2 (~22 TB usable)
- Media services: Plex, Jellyfin
- Automation & monitoring: Home Assistant, Scrypted, Frigate
- Personal cloud: Nextcloud
- Local AI: Ollama for running language models locally
- TV recording: HD Homerun for over-the-air DVR
- Backups: ZFS snapshots + external drive rotation + cloud backup for critical files
What I’m Exploring Next
But it’s not finished. The homelab is never really finished. That’s part of the joy.
I’m currently exploring:
- Offsite backup strategies using rclone and Tailscale
- Container orchestration beyond simple Docker Compose
- Advanced monitoring with Grafana and Prometheus for energy tracking and system health
- Expanded camera integration with Frigate for home security
- Local AI experiments with more powerful models
Every experiment teaches me something new, not just about technology, but about agency, autonomy, and what it means to own your digital infrastructure in an age of rented clouds and black-box services.
Final Thought
Homelabs aren’t just about efficiency or cost savings.
They’re about reclaiming agency. Building something physical, persistent, and yours in a world where everything is ephemeral and rented.
Whether it’s a metal box from Goodwill or an old Vaio from college, the tools matter less than the process of making them work for you.
That process, learning by building, failing forward, documenting as you go, is what transforms hardware into infrastructure, and infrastructure into understanding.
The Metal Box taught me that you don’t need permission to build your own systems. You just need curiosity, patience, and the willingness to experiment and figure out how to fix things.
That lesson is worth far more than $73.50.
What’s Next
In Part 3: Base System & Hypervisor Setup, I’ll guide you through the specific Proxmox configurations that took me from a basic installation to a production-ready hypervisor, including network bridging, storage pools, decisions on container vs. VM, and the backup strategies that saved me when things went wrong.
We’ll also explore the Docker question that sparked this entire journey: what it means, why it matters, and how containers have changed the way I think about deploying services.