DiyMediaServer

VPS + WireGuard: Why Your Homelab Needs a Public Edge

Wed, 04 Mar 2026 07:42:23 +0000

You finally got your homelab dialed in. Jellyfin streams flawlessly. Your dashboards are organized. Maybe you’re even self-hosting Gitea, Nextcloud, or a personal blog.

Then comes the big question: how do you safely share those services with the outside world?

If your answer is port forwarding on your router, you’re not alone. I did the same thing. I slapped a reverse proxy and Cloudflare in front and called it a day. It worked. It felt secure. It was not as secure as I thought.

When I moved to a Virtual Private Server (VPS) running a second reverse proxy with a WireGuard tunnel back to my homelab, everything changed. My home IP disappeared from the public internet. My router stopped getting hammered. I stopped lying awake wondering what was poking at my network.

If you’re serious about running public-facing services from home, a VPS in front of your homelab is the smarter move. Not because port forwarding is automatically a problem, but because a VPS shrinks your attack surface and limits the blast radius when something goes wrong. And something always goes wrong eventually.

💭

TL;DR:
Direct port forwarding exposes your home IP to constant scanning and increases your attack surface. A VPS acting as a reverse proxy with a WireGuard tunnel hides your home network, reduces blast radius, and gives you more control than relying only on Cloudflare or other zero trust tunnel solutions.

The Real Problem With Port Forwarding at Home

Your Attack Surface Is Bigger Than You Think

When you forward ports on your router, you’re publishing your home IP address to the world. That’s not automatically a death sentence. ISPs rotate IPs, CGNAT exists, and plenty of people run services this way for years without incident. But every open port is another door you’re daring the internet to try.

That means:

Bots can scan and fingerprint your services
DDoS attempts can target your home connection directly
Persistent probing never stops, even on non-standard ports
A single misconfigured service becomes a direct entry point to your home network

Automated scanners are relentless. Within minutes of opening ports 80 or 443, you’ll see probes in your logs. Open 8096 for Jellyfin. Same story. The entire public IPv4 space gets scanned constantly, and your little corner of it is not special enough to be ignored.

Here’s why that matters more for homelabs than enterprise. You likely don’t have:

An IDS/IPS appliance doing deep packet inspection
Upstream DDoS mitigation from your ISP
A SOC team monitoring logs at 3 AM
Redundant uplinks or failover

Your home internet connection is a single point of failure. If someone floods it, your family loses internet too. That’s not a hypothetical. That’s a Tuesday for anyone running public services on a residential line.

The Myth of “Safe Port Forwarding”

Some argue that best practices, diligent patching, and network isolation make you 99% safe. In theory, maybe.

In practice:

Zero-days happen
Misconfigurations happen
Humans make mistakes
Bots don’t sleep

The issue isn’t only application security. It’s about reducing how much of your lab is reachable from the internet and limiting the damage when something inevitably slips through. Defense in depth isn’t paranoia. It’s plumbing.

Protectli FW6C/FW6D
A fanless, six-port Intel-based firewall appliance built for pfSense/OPNsense, with Intel NICs and hardware AES-NI for fast, secure routing. Silent and compact yet expandable (RAM and SSD), it’s a favorite for gigabit-plus WANs, VLAN-heavy homelabs, and always-on IDS/IPS.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

What a VPS Changes for Your Homelab

A VPS Becomes Your Public Edge

A Virtual Private Server acts as your public-facing gateway. Instead of traffic going straight to your house, it hits the VPS first.

Instead of:

Internet → Your Home Router → Homelab

You get:

Internet → VPS → WireGuard Tunnel → Homelab

The world only sees the VPS IP address. Your home IP is never published. That one change shifts your entire risk profile.

Your Home IP Stays Private

All traffic terminates at the VPS first. The VPS forwards it over an encrypted WireGuard tunnel to your homelab.

From the outside:

DNS resolves to the VPS IP
Nmap scans hit the VPS
Attack traffic hits the VPS

If someone decides to DDoS your public endpoint, they’re punching the VPS, not your home router. Your family’s Netflix and your kid’s Minecraft session keep working.

No More Port Forwarding at Home

With the VPS plus WireGuard model, your home router stays locked down:

No forwarding ports 80 or 443
No exposing random service ports
No inbound NAT rules on your residential gateway

Only the VPS exposes ports publicly. On the home side, the WireGuard tunnel is outbound-initiated. Your homelab reaches out to the VPS, not the other way around. No inbound firewall rules needed on your router. That alone is a massive reduction in exposure.

Why Cloudflare Alternatives Matter

I used Cloudflare. Many homelabbers do.

Cloudflare Tunnel and Zero Trust solutions avoid open ports at home. That’s a real improvement over raw port forwarding. But there are trade-offs worth understanding before you go all-in.

Pros

No ports open at home
Easy setup
Automatic HTTPS
Built-in DDoS mitigation

TLS Termination and Trust

Cloudflare terminates TLS. That means Cloudflare decrypts your traffic and re-encrypts it to your origin. For hobby projects, that’s usually fine.

But here’s the trade-off: any reverse proxy you don’t control can see your decrypted traffic. That includes Cloudflare. It also includes a VPS provider if they wanted to snapshot RAM on the host, though that’s a different threat model. Both approaches involve trusting a third-party infrastructure provider. With a VPS you control, you at least decide where TLS terminates and you manage the certificates yourself.

You own the edge.

Vendor Lock-In

Cloudflare is excellent. It’s still a vendor. If you hit bandwidth limits, violate ToS unintentionally, need advanced routing, or want to proxy non-HTTP services, you can run into walls fast.

High-bandwidth media streaming is especially risky. Depending on your plan and usage, Cloudflare may throttle or flag you. Streaming terabytes of Jellyfin through their free tier is not what they had in mind.

With a VPS, you’re not tied to one company’s proxy layer. You can move providers without redesigning your entire network.

Non-HTTP Services

Cloudflare excels at HTTP and HTTPS. It is not built for everything else.

What about custom TCP services, game servers, experimental protocols, or self-hosted APIs over raw TCP? A VPS gives you full Layer 4 and Layer 7 control. You can proxy HTTP, HTTPS, TCP, UDP, and anything else WireGuard can tunnel.

That flexibility matters the moment you move beyond basic web apps.

The VPS + WireGuard Architecture Overview

No install steps here (the next post covers that). This is just the lay of the land.

The Components

VPS in the cloud
- Static public IP
- Reverse proxy such as Caddy or Nginx
- Strict firewall rules (only ports 80, 443, and your WireGuard UDP port)
- WireGuard server
Homelab server
- WireGuard client (initiates the tunnel outbound)
- Services bound to private interfaces only
Secure tunnel
- Encrypted point-to-point VPN between VPS and homelab
- VPS routes inbound requests over the tunnel to your services

How Traffic Flows

User visits app.yourdomain.com
DNS points to the VPS public IP
VPS reverse proxy receives the request
VPS forwards the request over WireGuard to the homelab
Homelab responds through the tunnel
VPS returns the response to the user

At no point is your home IP exposed publicly.

If someone runs:

nmap yourdomain.com

They only see:

VPS ports
VPS fingerprint
VPS OS signature

Not your home network. Not your ISP. Nothing useful.

Security Layers You Gain

On the VPS you can stack additional defenses:

Rate limiting (via Caddy’s rate_limit directive or Nginx’s limit_req)
Fail2ban watching your proxy logs
Basic WAF rules
Geo-blocking at the firewall level
Strict ufw or nftables rules allowing only ports 80, 443, and your WireGuard UDP port

In most cases, you only need ports 80 and 443 open publicly. Restrict WireGuard’s UDP port to known peer IPs where possible with something like ufw allow from <home-ip> to any port 51820.

Your homelab becomes private infrastructure behind a single hardened edge node.

MINISFORUM MS-01 Mini Workstation
The MS-01 i5 is a tiny mini PC with plenty of cores, multiple NVMe slots, and real homelab networking (dual 10G SFP+ plus 2.5 GbE), which makes it perfect for a Proxmox compute node. It has more than enough power for Jellyfin, the *arr stack, downloads, and a few VMs or LXCs, without turning your closet into a jet engine or space heater.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Trade-Offs You Should Understand

A VPS is not magic. It adds responsibility. Go in with your eyes open.

Cost

Expect around $5 per month at minimum for a basic VPS with reasonable bandwidth.

You need:

Enough bandwidth for your traffic (1-2 TB/month covers most homelabs)
Stable networking
Latency to your home under 100 ms if possible

For most homelabs, this is the cost of a fancy coffee once a month.

Added Latency

Traffic now takes a detour:

User → VPS → Home → VPS → User

That adds latency. How much depends on the distance between you and your VPS.

For dashboards, usually negligible. For media streaming, typically acceptable because buffering absorbs the delay. For real-time gaming, possibly noticeable. If latency climbs above 200 ms, choose a VPS region closer to you. You can also tune WireGuard MTU (try 1280) if you suspect packet fragmentation is making things worse.

You Must Secure the VPS

The VPS becomes your edge. Treat it like one. If you leave it misconfigured, you’ve just moved the problem from your house to a server you’re also responsible for.

You should:

Use SSH keys only (disable password auth in /etc/ssh/sshd_config)
Configure a host firewall (ufw or nftables)
Keep the system updated (unattended-upgrades on Debian/Ubuntu is your friend)
Monitor logs (even a simple logwatch cron job beats nothing)
Run nothing else on this box if you can help it

A VPS introduces its own management and patching burden. But it’s far easier to defend a minimal single-purpose VPS than an entire lab network with dozens of services hanging off your residential IP.

Realistic DDoS Expectations

A $5 VPS is not a bulletproof DDoS shield. Budget providers may null-route your IP if you attract significant attack traffic. That means your services go offline until the attack subsides.

But here’s why it’s still better than direct exposure: the attack hits the VPS, not your home. Your family’s internet keeps working. You redeploy the VPS with a new IP, update DNS, and move on. Compare that to someone DDoSing your home connection directly, where your only option is to call your ISP and wait on hold.

The VPS shifts where the attack lands. It doesn’t eliminate DDoS risk entirely. Don’t kid yourself on that.

MINISFORUM MS-A2
A compact mini-workstation built around up to a 16-core Ryzen 9 9955HX, with dual 10GbE SFP+ plus dual 2.5GbE, flexible storage (U.2 + M.2 including 22110), and triple 8K display outputs. Great as a homelab node or small server with serious I/O.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Alternatives Compared

Approach	Home IP Hidden	Protocol Support	Management	Cost	Best For
Direct Port Forwarding	No	All	Low	Free	Temporary testing only
Cloudflare Tunnel / Zero Trust	Yes	HTTP/HTTPS mainly	Low	Free tier available	Low-traffic web apps
Tailscale / WireGuard Only	No (if publishing)	All	Low	Free tier available	Private remote access
VPS + WireGuard	Yes	All	Medium	~$5/month	Public-facing homelab services
Full Cloud Migration	Yes	All	High	$$$	Business-critical workloads

Direct Port Forwarding

Pros: Free, simple.
Cons: Exposes home IP, constant scanning, no DDoS buffer, high risk if misconfigured.
Best for: Temporary testing only. If you’re still using this in production, you’re living on borrowed time.

Cloudflare Tunnel / Homelab Warp or Zero Trust

Pros: No open ports, easy setup, DDoS mitigation, good for web apps.
Cons: TLS termination by a third party, vendor lock-in, bandwidth constraints for streaming, limited protocol flexibility.
Best for: Low-traffic HTTP apps, quick deployments.

Tailscale or Direct WireGuard Only

Using WireGuard or Tailscale without a VPS works well for internal access. It’s great for reaching your lab from your phone or laptop on the road.

Pros: Secure, no public exposure, excellent for private access.
Cons: Not designed for anonymous public users. If you publish services directly, your home IP is still exposed.
Best for: Personal remote access, admin connections.

VPS Reverse Proxy + WireGuard

Pros: Hides home IP, full control over TLS, works for HTTP and non-HTTP, flexible routing, reduced residential exposure.
Cons: Monthly cost, added latency, extra management layer.
Best for: Serious homelabbers running public-facing services, media servers, or custom apps.

Full Cloud Migration

Pros: Enterprise-grade infrastructure, no home exposure.
Cons: Higher recurring costs, less homelab control, less fun.
Best for: Business-critical services, high-risk workloads, or when compliance requirements enter the picture.

Troubleshooting and Operational Realities

Even good solutions need maintenance. Here’s where things actually break.

WireGuard Tunnel Drops

Symptoms:

Services intermittently unavailable
Reverse proxy returns 502
wg show shows no recent handshake (or a handshake timestamp from hours ago)

Common causes:

Home IP changed (dynamic IP from your ISP)
NAT timeout on your home router killed the session
MTU mismatch causing packet fragmentation

Mitigations:

Set PersistentKeepalive = 25 on the home peer’s WireGuard config. This sends a keepalive packet every 25 seconds, preventing NAT tables from expiring your session.
Lower MTU to 1280 in your WireGuard interface config if fragmentation is suspected
Monitor handshake timestamps with a cron job. Something like wg show wg0 latest-handshakes piped into a simple alerting script works.
Use a dynamic DNS updater (ddclient or a provider’s API script) if your home IP changes frequently

Reverse Proxy Errors

If the VPS returns 502 or 504:

Confirm the homelab service is actually running (systemctl status <service>)
Verify routing over the tunnel subnet (can the VPS ping your homelab’s WireGuard IP?)
Check SNI and TLS configuration in your reverse proxy
Ensure firewall rules on both ends allow tunnel traffic

Unexpected Public Exposure

Run:

nmap yourdomain.com

You should only see the VPS ports.

If you see your ISP IP in DNS records, HTTP headers, or service responses, investigate immediately. Check for DNS leaks (stale A records pointing home), misconfigured X-Forwarded-For headers, or services that embed your local IP in responses (some apps are chatty about this in their default configs).

RaspberryPi 4GB
A palm-sized single-board computer with a quad-core ARM CPU and 4GB RAM that runs full Linux, with Gigabit Ethernet, dual-band Wi-Fi, USB 3.0, and dual micro-HDMI. Ideal for lightweight homelab duties or for running a WireGuard endpoint while sipping a few watts.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Frequently Asked Questions

➤ How does a VPS hide my homelab IP from attacks?

All public DNS records point to the VPS IP. Attackers hit the VPS, not your home connection. Your home IP is never published in DNS or exposed through HTTP headers. The WireGuard tunnel is outbound-initiated from your home, so no inbound firewall rules are needed on your router.

➤ What happens if my VPS provider null-routes me during an attack?

Your public services go offline temporarily, but your home internet stays unaffected. You can redeploy the VPS with a new IP, update DNS, and be back online. This is far better than having your entire home connection taken down.

➤ Can I use WireGuard port forwarding without a VPS for public services?

WireGuard alone is excellent for private access between your devices. For public-facing services without a VPS, you still need to forward ports on your home router, which exposes your residential IP. The VPS is what removes that exposure.

➤ What about CGNAT? Does that change the equation?

If your ISP uses CGNAT, you can’t port forward at all without their cooperation. A VPS with WireGuard actually solves this problem entirely. Your homelab connects outbound to the VPS, and the VPS handles all public traffic. CGNAT doesn’t matter because you’re never accepting inbound connections at home.

➤ How do I handle a dynamic home IP with this setup?

Set up a dynamic DNS client (like ddclient or your DNS provider’s update API) on your homelab that updates a hostname whenever your IP changes. Configure the WireGuard peer on the VPS side to use that hostname instead of a hardcoded IP. Combined with PersistentKeepalive, the tunnel re-establishes automatically after an IP change.

➤ What's the cheapest VPS that works for homelab proxying?

Look for:

Around $5 per month
1 GB RAM
1 vCPU
Generous bandwidth (1-2 TB minimum)
Static IPv4
KVM virtualization (avoid OpenVZ for WireGuard kernel module support)

Latency to your home should ideally be under 100 ms.

➤ When should I stop self-hosting and move to the cloud?

If you:

Handle sensitive client data
Require guaranteed uptime with SLAs
Face compliance requirements (HIPAA, SOC 2, etc.)
Attract sustained, large-scale attack traffic

It may be time to move critical services fully to the cloud. A VPS plus homelab combo works great for personal projects and media, but it’s not a substitute for managed infrastructure when the stakes are high.

Lessons Learned From Doing It Wrong First

I ran my homelab with a reverse proxy at home, Cloudflare in front, and strong passwords. I figured that was enough.

It wasn’t.

My IP was still exposed in certain scenarios. My logs showed constant probing. I was handing TLS termination to a third party without fully considering what that meant. And my home network was still in the blast radius if anything went sideways.

After moving to a VPS running Caddy as a reverse proxy with a WireGuard tunnel back home, I got IP privacy, cleaner architecture, zero exposed ports on my router, and a lot more confidence that a bad day on the internet wouldn’t become a bad day for my household.

The setup isn’t complicated. It just requires you to accept that “good enough” wasn’t actually good enough.

The Right Architecture for Serious Homelabs

If you’re casually experimenting, port forwarding might feel fine for now. Just know what you’re accepting.

If you’re serious about running public-facing services, a VPS in front is the better way to keep your home network out of the blast radius. It hides your home IP, eliminates router port forwarding, gives you full TLS control, works beyond HTTP, and scales with you.

Cloudflare and zero trust tools are useful. Tailscale is fantastic for private access. But if you want full control, privacy, and protocol flexibility, the VPS plus WireGuard model is the sweet spot for anyone looking to self-host their own edge.

Your homelab should be a playground, not a liability. If you’re going to open it to the internet, do it the right way.

This is Part 1 of a 3-part series on building a VPS-fronted homelab.

Part 1: Why Your Homelab Needs a VPS to Share Services Publicly (this post)
Part 2: How to Install WireGuard on a VPS and Connect It to Your Homelab (Not published yet)
Part 3: WireGuard Client on OPNsense and pfSense: LAN Routing for Your VPS Tunnel (Not published yet)

How to Fix Stale File Handles NFS Errors with MergerFS

Sat, 14 Feb 2026 05:26:30 -0700

If you’re running a homelab NAS with a MergerFS and SnapRAID setup and sharing that pool over NFS, there’s a good chance you’ve run into one of the most frustrating errors in the self-hosted world: stale file handles. Files that were accessible five minutes ago suddenly aren’t. Containers break. Plex stops mid-stream. You restart everything, it works for a while, and then it happens again.

I spent way too long troubleshooting stale file handles on NFS before landing on the actual cause, and it turned out to be a fundamental mismatch between how MergerFS works as a FUSE filesystem and what NFS expects from its exports. This post walks through the problem, why it happens, and the fix that finally made it go away for good.

💭

TL;DR:
Sharing a MergerFS pool directly over NFS causes stale file handles because NFS can't reliably track file handles across a FUSE filesystem. The fix is to export each underlying disk individually over NFS, then install MergerFS on the client machine and pool them there. Your SnapRAID config on the NAS doesn't need to change at all since it already points at the individual drives. The stale handle errors go away permanently because NFS is finally working with real filesystems instead of a FUSE layer.

Why MergerFS and NFS Cause Stale File Handles

MergerFS is a FUSE-based union filesystem. It takes multiple individual drives and presents them as a single merged mount point. If you’re running a typical MergerFS and SnapRAID homelab stack, you probably have several data disks pooled together with MergerFS for day-to-day use and SnapRAID providing parity protection on top. That architecture is great for local use - your applications see one big pool and MergerFS handles file placement across the underlying disks based on your chosen policy.

The trouble starts when you export that merged FUSE mount point directly over NFS. NFS relies on file handles to track files across the network. These handles are tied to the underlying filesystem’s inode and device information. Because MergerFS runs as a FUSE filesystem in userspace rather than as a native kernel filesystem, it generates its own virtual file handles. When MergerFS resolves paths across drives, or when SnapRAID maintenance operations like syncs and scrubs touch the underlying files, those FUSE-generated handles can become invalid from NFS’s perspective. The NFS client asks for a file using a handle that no longer points to anything valid, and you get the dreaded Stale file handle error.

This isn’t a bug or a misconfiguration you can tune away.

MergerFS official Documentation
Explicitly calls this out. Exporting a FUSE-based MergerFS pool directly over NFS is not a supported workflow.

Read

The Fix: Export Individual Drives Over NFS, Run MergerFS on the Client

The solution is to flip the architecture. Instead of pooling on the server and exporting the MergerFS mount, you export each underlying drive individually over NFS and then run MergerFS on the client side to combine them back into a single merged view.

It sounds like more work, but the setup is straightforward and the result is rock solid. NFS gets stable, predictable file handles because each export is a real ext4 or XFS filesystem on a real disk - not a virtual FUSE layer. MergerFS still gives you a single unified pool, it just runs on the machine that actually consumes the data. And your SnapRAID parity setup on the NAS stays completely untouched since SnapRAID operates on the individual drives, not the merged pool.

Step 1: Export Each Drive Individually from the NAS

On your NAS (the NFS server), edit /etc/exports to export each disk in your MergerFS pool as its own NFS share. The critical detail here is that each export needs a unique fsid value. NFS uses fsid to distinguish between exports, and if you skip this or duplicate values, you’ll get weird cross-mount issues that look a lot like the stale file handle problem you’re trying to fix.

/mnt/Pool/Disk1/ 172.27.0.0/24(all_squash,anongid=1001,anonuid=1000,insecure,rw,subtree_check,fsid=1)
/mnt/Pool/Disk2/ 172.27.0.0/24(all_squash,anongid=1001,anonuid=1000,insecure,rw,subtree_check,fsid=2)
/mnt/Pool/Disk3/ 172.27.0.0/24(all_squash,anongid=1001,anonuid=1000,insecure,rw,subtree_check,fsid=3)

Repeat this pattern for every data disk in your pool. If you’re running a SnapRAID configuration, these are your data disks - you do not need to export the SnapRAID parity disk. A few things to double-check on the export options:

anonuid and anongid should match the user and group IDs that own your media files (or whatever you’re serving). Run id <username> on the NAS if you’re not sure what these should be. Getting this wrong leads to permission denied errors that are easy to confuse with stale NFS file handles.
all_squash maps all client requests to the anonymous user, which keeps permissions simple in a homelab. If you need per-user access control, you’ll want a different approach, but for most media server and homelab setups this is the right call.
insecure allows connections from ports above 1024. Some NFS clients (especially on non-Linux systems or inside containers) need this.
The subnet (172.27.0.0/24 in this example) should match your actual network. Restrict this to the range that needs access.

After editing, apply the changes:

sudo exportfs -ra

Step 2: Mount the Individual NFS Shares on the Client

On each client machine that needs access to the pool, start by creating the local mount points:

sudo mkdir -p /mnt/pool/disk1 /mnt/pool/disk2 /mnt/pool/disk3

Then add the NFS mounts to /etc/fstab:

172.27.0.5:/mnt/Pool/Disk1  /mnt/pool/disk1  nfs  rw,nofail,hard,intr  0 0
172.27.0.5:/mnt/Pool/Disk2  /mnt/pool/disk2  nfs  rw,nofail,hard,intr  0 0
172.27.0.5:/mnt/Pool/Disk3  /mnt/pool/disk3  nfs  rw,nofail,hard,intr  0 0

Replace 172.27.0.5 with the actual IP of your NAS. The mount options here are worth understanding:

hard means the client will keep retrying if the NFS server becomes unreachable, rather than returning an error. For a homelab where reboots happen, this is usually what you want. The alternative, soft, gives up after a timeout, which can lead to data corruption if a write was in progress.
intr allows you to interrupt a hung NFS operation with a signal. Without this, a stuck NFS mount can lock up processes in a way that’s hard to recover from without a reboot.
nofail prevents the client from hanging at boot if the NAS isn’t available yet. Especially important if your NAS and clients boot at the same time after a power outage.

Mount everything:

sudo mount -a

Verify each disk is accessible:

ls /mnt/pool/disk1
ls /mnt/pool/disk2
ls /mnt/pool/disk3

TP-Link 2.5GB PCIe Network Card (TX201)
Mounting three or four NFS shares on the client and pooling them through a MergerFS FUSE mount means your network link matters more than ever. This 2.5GbE PCIe card is cheap, works out of the box on most Linux distros, and makes sure the NIC isn’t the bottleneck when you’re streaming from a client-side merged pool.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Step 3: Create the MergerFS FUSE Pool on the Client

Install MergerFS on the client if you haven’t already. On Debian/Ubuntu:

Grab the latest .deb from the MergerFS releases page:
https://github.com/trapexit/mergerfs/releases

sudo dpkg -i mergerfs_<version>.deb

Create the directory where the merged FUSE pool will appear:

sudo mkdir -p /media/storage

Then add the MergerFS FUSE mount to /etc/fstab:

/mnt/pool/disk*  /media/storage  fuse.mergerfs  direct_io,defaults,allow_other,dropcacheonclose=true,inodecalc=path-hash,category.create=mfs,minfreespace=50G,fsname=storage  0 0

Here’s what the key MergerFS options are doing:

direct_io - Bypasses the kernel page cache. This is important when the underlying filesystems are NFS mounts, since the NFS client has its own caching layer. Double-caching through both NFS and FUSE leads to stale reads and wasted memory.
dropcacheonclose=true - Drops cached data when a file is closed. Another safeguard against stale data when MergerFS operates over NFS-mounted filesystems.
inodecalc=path-hash - Generates inode numbers based on the file path rather than the underlying device. This keeps inode numbers stable even if files exist on different disks, which matters for applications that track files by inode.
category.create=mfs - The “most free space” policy. New files get written to whichever disk has the most available space. Good default for media storage. If you’re using SnapRAID, keep in mind that new files written through this policy won’t be protected until the next snapraid sync runs.
minfreespace=50G - Disks with less than 50GB free won’t receive new files. Adjust this based on your disk sizes - you don’t want a drive filling up to 100%.
allow_other - Lets users other than the one who mounted the FUSE filesystem access it. Required if you’re running services like Plex, Jellyfin, or containerized apps under different user accounts.

Mount it:

sudo mount -a

Check that the merged pool looks right:

df -h /media/storage
ls /media/storage

You should see a single view of all your files across all disks, just like before - but now without the stale file handle errors.

Seagate Barracuda 24TB Internal Hard Drive
When each disk in your MergerFS pool gets its own NFS export, bigger drives mean fewer exports to manage and fewer fstab entries on each client. 24TB per disk also means your SnapRAID parity drive covers a lot of storage per slot. Fewer disks, less complexity, same merged pool on the other end.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Why This Fixes Stale NFS File Handles

The root cause was always about how FUSE filesystems interact with NFS file handles. When NFS exports a real, single-disk filesystem like ext4 or XFS, the file handles are based on stable inode and device IDs that don’t change. The NFS server and client stay in agreement about what each handle points to.

MergerFS, as a FUSE-based filesystem running in userspace, generates its own virtual file handles that can shift when the underlying layout changes. NFS has no mechanism to track those shifts across a FUSE layer, so the handles go stale. This is a fundamental limitation of exporting any FUSE filesystem over NFS, not just MergerFS.

By moving the MergerFS FUSE mount to the client side, NFS only ever deals with real on-disk filesystems. Each NFS export is a direct, one-to-one mapping to a physical disk partition. The file handles stay valid indefinitely. MergerFS then operates entirely in local userspace on the client, where FUSE handle behavior doesn’t need to survive a network round-trip.

What Happens to SnapRAID in This Setup

If you’re running SnapRAID alongside MergerFS (which is one of the most common storage configurations in homelabs), nothing changes on the server side. SnapRAID always operates on the individual data disks, not on the MergerFS pool. Your SnapRAID configuration file still points to the same /mnt/Pool/Disk1, /mnt/Pool/Disk2, etc. paths. Your parity disk stays local to the NAS. Your snapraid sync and snapraid scrub cron jobs keep running exactly as before.

The only thing that changed is how those disks get to the client machines. Instead of NFS exporting a single FUSE-merged path, you’re exporting the same underlying directories that SnapRAID already knows about. If anything, this architecture is cleaner because there’s no ambiguity about which layer owns what - SnapRAID and NFS both work directly with the real filesystems, and MergerFS handles the convenience of a unified view on whatever machine needs it.

Things to Watch Out For

Boot order matters.
The NFS mounts need to be up before the MergerFS FUSE mount tries to pool them. In most cases, systemd handles this correctly because the fstab entries are processed in order and fuse.mergerfs depends on the mount points being available. If you’re seeing empty pools after a reboot, look into adding x-systemd.requires or x-systemd.after options to the MergerFS fstab line, or use an automount approach.

Adding new disks.
When you add a new drive to the NAS, you need to add a new NFS export on the server, a new NFS mount entry on each client, and update the MergerFS glob pattern if the new disk doesn’t match /mnt/pool/disk*. If you’re running SnapRAID, you’ll also need to add the new disk to your SnapRAID config and run a sync - but you’d have to do that regardless of how you export over NFS.

SnapRAID sync timing.
Since new files written through the client-side MergerFS pool end up on individual disks on the NAS, they won’t have parity protection until the next snapraid sync. This is the same as any MergerFS and SnapRAID setup - it’s not introduced by this architecture change. If you’re not already running SnapRAID syncs on a schedule, set up a cron job or use a helper script like snapraid-runner to automate it.

Performance.
Running a FUSE filesystem on the client over NFS mounts adds a small layer of overhead compared to a direct NFS export. In practice, for media streaming, file serving, and typical homelab workloads, this is negligible. The FUSE overhead is mostly in metadata operations, and the NFS network latency dominates actual file transfer times anyway. If you’re doing heavy random I/O or database-style workloads over this setup, you might want to benchmark, but that’s probably not what you’re using MergerFS for.

Multiple clients.
Each client that needs the merged view needs its own MergerFS install and FUSE mount configuration. This is the main tradeoff - it’s per-client setup instead of a single pool on the NAS. For most homelabs with one or two client machines, it’s not a big deal. If you have many clients, you might want to script the deployment or use configuration management.

Wrapping Up

Stale file handles on NFS with a MergerFS FUSE pool is one of those problems where the symptoms point you in every direction except the actual cause. You’ll check NFS timeouts, restart services, fiddle with cache settings, and none of it sticks. The real fix is architectural: stop exporting the MergerFS FUSE mount over NFS. Export the individual drives directly and pool them with MergerFS on whatever client needs the merged view.

Your SnapRAID parity stays exactly where it is. Your NFS file handles stay stable because they’re backed by real filesystems instead of a FUSE layer. And you stop re-troubleshooting the same stale file handle errors every few weeks, which honestly is the best part.

UGREEN NASync DXP4800 Plus 4-Bay Desktop NAS
Four bays, an Intel N100, and a 2.5GbE port. Four bays is the sweet spot for a MergerFS and SnapRAID setup - three data disks pooled with MergerFS and one dedicated SnapRAID parity drive. Plenty of CPU headroom to serve multiple NFS exports without the FUSE overhead since pooling happens on the client side.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

How to Fix Proxmox Status 30 Errors with Unprivileged LXCs

Sat, 07 Feb 2026 07:18:30 -0700

You upgraded to Proxmox 9.1.5 and now your Jellyfin, Plex, or Arr containers refuse to start. They worked for months, maybe years, and now all you get is a cryptic “Status 30” error. Proxmox 9.1.5 enforces idmapped mounts for unprivileged LXC containers, and FUSE-based filesystems like MergerFS want nothing to do with them. My best guess is that these changes were made to better support the new OCI-compliant images, which let Proxmox run Docker images without needing Docker installed.

The fix: ditch mpX mounts entirely, replace them with lxc.mount.entry lines, and configure explicit unprivileged ID mapping.

This guide is for Proxmox users running unprivileged LXC containers with bind mounts on MergerFS or NFS storage. If all your storage is native Proxmox (ZFS, ext4, local directories), your mpX mounts will probably still work. You can stop reading and go enjoy your day.

I hit this after updating to Proxmox 9.1.5. Every container with MergerFS bind mounts failed after a reboot. No useful error message. No graceful fallback. Just “Status 30” and silence. After digging through logs and testing half a dozen approaches, the solution turned out to be straightforward. Annoying, but straightforward.

💭

TL;DR: Proxmox 9.1.5 enforces idmapped mounts for mpX bind mounts. MergerFS and most NFS setups don’t support idmapped mounts, which causes LXC startup to fail with Status 30. The fix: remove your mpX mounts, use lxc.mount.entry instead, and explicitly define your unprivileged UID and GID mappings. Details below.

Quick Check: Does This Apply to You?

Your storage is probably fine if it’s:

Local ext4, XFS, or ZFS on the Proxmox host
Native Proxmox directories

You’re affected if your storage is:

MergerFS pools
NFS mounts
Other FUSE-based filesystems
External USB or hybrid storage setups

If you’re in the second group, keep reading. Everyone else, go do something more fun.

What Is the Proxmox Status 30 Error?

Status 30 is LXC’s way of telling you something went wrong during container startup without telling you what went wrong. It’s a generic failure code that masks deeper filesystem or permission problems.

You’ll see messages like:

startup for container '102' failed
Script exited with status 30
Read-only file system (os error 30)

📝

Note: Status 30 means Proxmox tried to mount or write to storage and the kernel said no.

To find out why the kernel said no, you need to watch the errors live. Run this on the Proxmox host, replacing XXX with your container ID:

lxc-start -n XXX -F -l DEBUG -o /dev/stdout

Look for lines mentioning idmapped, mount, or permission denied. Those will point you toward the actual cause.

What Changed in Proxmox 9.1.5?

Proxmox 9.1.5 ships with a newer Linux kernel and tighter security defaults. The specific change that breaks MergerFS setups is broader enforcement of idmapped mounts for unprivileged containers.

When you define a container mount like:

mp0: /mnt/media,mp=/media

Proxmox now automatically:

Creates an idmapped mount
Shifts ownership so container UID 1000 maps cleanly to host UID 1000
Enforces isolation guarantees

This works great on native filesystems (ext4, XFS, ZFS) but, it completely fails on:

MergerFS (FUSE-based, no idmap support)
Most NFS exports (server-side ownership, no client idmap)
Some custom or layered storage stacks

When the kernel refuses the idmapped mount, Proxmox kills the LXC startup rather than opening a security hole. This shows up as a Status 30 error.

The mpX Trap: Why Old Configs Break

Before Proxmox 9.1.5, mpX mounts were forgiving. You could bind-mount media directories owned by UID 1000, and LXC handled permission translation loosely. Nobody complained.

After the upgrade, mpX mounts trigger the idmapping hook automatically. If your underlying filesystem doesn’t support it, three things happen:

Container fails to start
Misleading “read-only filesystem” errors appear in logs
Ghost mounts get left behind on the host (more on this in Step 5)

This is why containers without bind mounts start fine while your media servers all failed at the same time. Ask me how I know.

The Fix: Manual Mounting and Explicit Unprivileged ID Mapping

The temptation here is to flip your containers to privileged mode. Don’t. Privileged containers run as root on the host. If your Jellyfin or Plex container gets exploited, the attacker has root on your entire Proxmox host and can pivot to every other VM and container you’re running. That’s not a theoretical risk. Container escape vulnerabilities in shared-kernel setups are well-documented, and if you’re running services that download files from the internet (every Arr app, every torrent client), you’re handing a potential attacker the keys to your entire homelab. Keep your containers unprivileged.

The fix has three parts:

Remove mpX mounts so Proxmox stops trying to idmap them
Use raw lxc.mount.entry lines that LXC handles directly
Define clean, contiguous UID and GID maps so permissions work correctly

This keeps your containers unprivileged while sidestepping the MergerFS/NFS incompatibility entirely.

📝

Note:

Prerequisites checklist. Before starting, confirm you have the following ready. Experienced readers: don’t skip Steps 1 and 2. The ID delegation and mpX removal on the host are required before anything else works.

SSH or console access to your Proxmox host (not the container)
Your media user’s UID and GID (run id your_media_username on the host)
Your render group’s GID if you use GPU passthrough (run getent group render on the host)
The container ID(s) you need to fix
A backup of your container config file(s)

Step 1: Configure UID and GID Delegation on the Host

Before LXC can map host IDs into an unprivileged container, Proxmox needs explicit permission to use those IDs. That permission lives in two files on the host: /etc/subuid and /etc/subgid.

First, figure out your actual media user’s UID and GID. Run this on the host:

id your_media_username

The examples below assume UID 1000 and GID 1001. Replace these with your actual values throughout. If you copy-paste blindly and your IDs don’t match, you’ll be right back at Status 30. I won’t feel sorry for you.

Next, check your render group GID if you need GPU passthrough:

getent group render

This usually returns render:x:104 but it’s not guaranteed. On some distributions or custom setups, the render group could be GID 105, 128, or something else entirely. Whatever number you see here is the one you’ll use in every step below. If the command returns nothing, you don’t have a render group and can skip the render-related lines in Steps 1 and 4.

Edit these files on the Proxmox host.

Start with subuid:

nano /etc/subuid

Paste this:

root:1000:1
root:100000:65536

Next, edit subgid:

nano /etc/subgid

Paste this:

root:104:1
root:1001:1
root:100000:65536

What each line means:

root:1000:1 allows root to delegate host UID 1000 (your media user) into a container
root:104:1 allows root to delegate host GID 104 (the render group, for GPU passthrough). Replace 104 with whatever getent group render returned on your system.
root:1001:1 allows root to delegate host GID 1001 (your media group)
root:100000:65536 is the standard unprivileged ID range. Leave it alone.

If any of these entries are missing or wrong, LXC cannot construct a valid idmap and your container won’t start. There’s no partial credit here.

Step 2: Remove mpX Mounts from the Container

Back up your container config first. I mean it. Copy it somewhere safe before you touch anything.

cp /etc/pve/lxc/XXX.conf /root/XXX.conf.bak

Now open the config:

nano /etc/pve/lxc/XXX.conf

Delete or comment out any lines like:

mp0: /mnt/media,mp=/media
mp1: /mnt/downloads,mp=/downloads

Every single one. Leaving even one mpX entry triggers the idmapping hook, and you’re back to Status 30.

Step 3: Add Direct lxc.mount.entry Bind Mounts

At the bottom of the container config file, add manual mount entries:

lxc.mount.entry: /media/storage/Movies media/Movies none bind,create=dir,ro 0 0
lxc.mount.entry: /media/storage/Shows media/Shows none bind,create=dir,ro 0 0

Pay attention to these details. They’ll bite you if you get them wrong:

The container path (second field) is relative, no leading slash. Write media/Movies, not /media/Movies. This trips people up constantly.
bind tells LXC to handle the mount directly, bypassing Proxmox’s storage helpers.
create=dir tells LXC to create the mount point inside the container if it doesn’t exist. Without this, you’ll get a mount failure if the directory is missing.
Set ro or rw explicitly based on what the container actually needs. Read-only where possible. Your Jellyfin container doesn’t need write access to your movie library.

These mounts are handled by LXC itself, not Proxmox. That’s the whole point.

Step 4: Define Clean Unprivileged ID Mapping

This is the part where most people get tripped up. Unprivileged containers require a fully contiguous UID and GID map covering the range 0 through 65535. No gaps. No overlaps. If the math doesn’t add up to exactly 65536 IDs, the container will not start. LXC is merciless about this.

Customize these values. Replace 1000 with your actual media user’s UID. Replace 1001 with your actual media group’s GID. Replace 104 with your actual render group GID.

How the math works

Every lxc.idmap line maps a range of container IDs to host IDs. The format is:

lxc.idmap: <u|g> <container_start> <host_start> <count>

The rule is simple: every count value across all your lines for a given type (u or g) must add up to exactly 65536. When you pass through a specific ID (like your media UID), you split the range around it. Here’s the formula:

Range before passthrough:  count = passthrough_id
Passthrough itself:        count = 1
Range after passthrough:   count = 65536 - passthrough_id - 1

For multiple passthroughs (like the GID map), you split around each one in order, and the counts between them fill the gaps.

Example A: UID 1000, GID 1001, render GID 104

This is the most common homelab setup. Add these lines to your container config:

UID Mapping:

lxc.idmap: u 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: u 1001 101001 64535

Table:

Container UIDs	Host UIDs	Count	Purpose
0 - 999	100000 - 100999	1000	Unprivileged range
1000	1000	1	Media user passthrough
1001 - 65535	101001 - 165535	64535	Unprivileged range
		65536	Total

GID Mapping:

lxc.idmap: g 0 100000 104
lxc.idmap: g 104 104 1
lxc.idmap: g 105 100105 896
lxc.idmap: g 1001 1001 1
lxc.idmap: g 1002 101002 64534

Table:

Container GIDs	Host GIDs	Count	Purpose
0 - 103	100000 - 100103	104	Unprivileged range
104	104	1	Render group passthrough
105 - 1000	100105 - 101000	896	Unprivileged range
1001	1001	1	Media group passthrough
1002 - 65535	101002 - 165535	64534	Unprivileged range
		65536	Total

Verify: 104 + 1 + 896 + 1 + 64534 = 65536. Contiguous. No gaps.

Example B: UID 1001, GID 1002, render GID 128

If your media user is UID 1001 with GID 1002, and your render group is GID 128, the math shifts:

UID Mapping:

lxc.idmap: u 0 100000 1001
lxc.idmap: u 1001 1001 1
lxc.idmap: u 1002 101002 64534

Verify: 1001 + 1 + 64534 = 65536.

GID Mapping:

lxc.idmap: g 0 100000 128
lxc.idmap: g 128 128 1
lxc.idmap: g 129 100129 873
lxc.idmap: g 1002 1002 1
lxc.idmap: g 1003 101003 64533

Verify: 128 + 1 + 873 + 1 + 64533 = 65536.

Notice the pattern: the gap between your two GID passthroughs (128 and 1002) is 1002 - 128 - 1 = 873. That’s the count for the middle range. The final range is always 65536 minus the sum of everything before it.

Don’t forget: if you use different IDs, you also need to update /etc/subuid and /etc/subgid from Step 1 to match. Those files must list every host ID you’re passing through.

⚠️

Warning: Quick sanity check. After writing your idmap lines, add up all the count values for your u lines and all the count values for your g lines. Both totals must equal exactly 65536. If either one doesn’t, your container will not start.

Step 5: Clear Stale Mounts Before Restarting

Failed startups leave behind ghost mounts on the host. If you try to start the container again without cleaning these up, it can fail in new and exciting ways.

⚠️

Warning: Only run this if your container previously failed to start. This forcibly unmounts staged mount points.

On the host, run:

umount -l /var/lib/lxc/.pve-staged-mounts/mp* 2>/dev/null

The -l flag performs a lazy unmount, which detaches the filesystem immediately and cleans up references once they’re no longer busy. This is safe for cleaning up after failed mount attempts. One caveat: don’t use lazy unmount as a habit for mounts that keep failing. It detaches the mount without fixing whatever caused the failure, so if you find yourself running this repeatedly, something deeper is wrong. Go back and check your config.

Now start your container:

pct start XXX

Step 6: Verify Everything Works

Don’t just check that the container started. Confirm that permissions are actually correct end-to-end.

Check that mounts exist and ownership is correct:

pct enter XXX
ls -la /media/Movies

You should see your media files with the correct ownership. If the ownership looks wrong (everything owned by nobody or 65534), your idmap entries are off. Go back to Step 4 and double-check your math.

Test file operations (if using rw mounts):

Inside the container:

touch /media/Downloads/testfile
ls -la /media/Downloads/testfile
rm /media/Downloads/testfile

The test file should be owned by your media user, not root or nobody.

Confirm services start cleanly:

Inside the container, check your media service:

systemctl status jellyfin   # or plex, sonarr, radarr, etc.

If the service is running and can see your library, you’re done. If it starts but can’t find media files, the mount exists but the path inside the container doesn’t match what the service expects. Double-check the container path in your lxc.mount.entry lines from Step 3.

Check LXC logs for clean startup (from the host):

lxc-start -n XXX -F -l DEBUG -o /dev/stdout

A clean startup will show your mount entries being applied without any idmapped errors or permission denials. If you see warnings but the container still starts, investigate them. Warnings that you ignore today become outages after the next update.

Why This Works

By switching from mpX to lxc.mount.entry, you:

Skip Proxmox’s idmapped mount helpers entirely
Bypass kernel-level idshift enforcement that FUSE filesystems can’t handle
Let LXC translate IDs at runtime using your explicit mapping

This is how LXC handled unprivileged containers before Proxmox 9.1.5 added automatic idmapping. You’re not doing anything weird or unsupported. You’re just being explicit about what Proxmox used to do implicitly.

This configuration should survive future Proxmox updates since lxc.mount.entry is a stable LXC feature, not a Proxmox-specific shortcut. That said, major version upgrades can always change defaults, so keep your config backups current and check release notes before upgrading.

Troubleshooting Status 30 Errors

Container Still Fails With Status 30

Work through this checklist:

Confirm that no mpX entries remain in /etc/pve/lxc/XXX.conf. Grep for them: grep '^mp' /etc/pve/lxc/XXX.conf
Verify /etc/subuid and /etc/subgid include entries for every ID you’re passing through
Check that your idmap ranges are contiguous and total 65536 for both UIDs and GIDs
Confirm the host paths in your lxc.mount.entry lines actually exist: ls -la /media/storage/Movies
Clear stale mounts (Step 5) and try again

Storage Appears Read-Only Inside the Container

Test write access directly on the host first:

touch /mnt/media/testfile && rm /mnt/media/testfile

If this fails, the problem is at the storage level, not LXC. Check your MergerFS config, underlying disk health, and filesystem mount options. If the host can write but the container can’t, double-check that your lxc.mount.entry line uses rw and not ro.

NFS Mounts Fail

NFS typically lacks idmapped mount support, so the same lxc.mount.entry approach applies. The extra wrinkle: your NFS export must allow access from the UIDs and GIDs you’re mapping.

⚠️

Warning: Check your /etc/exports on the NFS server. Make sure no_root_squash or appropriate user mapping is configured for the host IDs you’re passing through. This is easy to miss and will cause silent permission failures even if everything else is configured correctly.

Multiple Media Users or Docker Inside LXC

If you have more than one media user that needs passthrough (for example, separate users for Sonarr and Jellyfin), you need to add a passthrough line for each UID and GID in Step 4 and a delegation entry for each in Step 1. The same splitting logic applies: break the range around each passthrough ID and make sure the counts still total 65536.

If you’re running Docker inside an unprivileged LXC container (first WHY?!), you’ll hit additional nesting issues. Docker needs its own ID namespace, which adds complexity on top of the LXC mapping. This is solvable but outside the scope of this guide. The Proxmox wiki has a section on nested containers that covers the basics.

FAQs

➤ What causes Read-only file system (os error 30) in Proxmox?

Proxmox attempted a write through a mount that the kernel rejected. With MergerFS and unprivileged LXC containers, this almost always means the idmapped mount failed silently and the container got a read-only fallback. Switching from mpX to lxc.mount.entry fixes it.

➤ Is this specific to Proxmox 9.1.5?

Yes. Earlier Proxmox versions didn’t enforce idmapped mounts for unprivileged containers as aggressively. The kernel and LXC defaults changed in Proxmox 9 to make this behavior automatic.

➤ Should I switch to privileged containers?

No. Privileged containers run as root on the host, which means a compromised container gives an attacker full access to your Proxmox node and every VM and container on it. Manual ID mapping gives you both compatibility and security. The extra configuration is worth it.

➤ Does this affect VMs too?

VMs use a completely different storage model. They don’t use LXC bind mounts at all. However, MergerFS can still cause backup failures and disk I/O errors in VM environments for separate reasons.

➤ Will this survive the next Proxmox update?

The lxc.mount.entry directive is a stable LXC feature, not a Proxmox hack. It should survive point releases without issue. Major version upgrades could change defaults, so always read release notes and keep config backups before upgrading.

Conclusion

Proxmox 9.1.5 tightened its security defaults, which is a good thing. The side effect is that FUSE-based filesystems like MergerFS and certain NFS configurations got caught in the crossfire.

If you rely on MergerFS or NFS with unprivileged containers, the old mpX approach is dead. Replacing it with lxc.mount.entry and explicit ID mapping restores stability without giving up security.

Once configured correctly, containers start cleanly and survive updates. Status 30 becomes a bad memory. It’s an hour of config work that saves you from this headache permanently.

Recommended Hardware

If you’re building or upgrading a homelab media server, here’s what I actually use and recommend.

Seagate Barracuda 24TB Internal Hard Drive
Solid high-capacity drive for MergerFS pools. I run several of these as the backing storage for the exact setup described in this guide. Not the cheapest per-TB option, but reliable and widely available.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

LSI 9211-8iB IT MODE
An HBA flashed to IT mode passes drives directly to the OS without a hardware RAID layer. This is what you want for MergerFS or ZFS setups where the OS needs raw disk access. Cheap on eBay, rock-solid, and still the default recommendation in most homelab communities.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

SFF-8087 to 4x SATA
You’ll need these breakout cables to connect SATA drives to the LSI HBA above. One cable handles four drives. Grab two if you’re filling a larger chassis.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

OPNsense vs pfSense for Homelabs: Complete Comparison

Fri, 23 Jan 2026 08:22:37 -0700

What are OPNsense and pfSense and Why It Matters for Homelabs in 2026

OPNsense versus pfSense is the most debated firewall choice in homelab communities. Both are FreeBSD-based firewalls that handle routing, VPNs, intrusion detection, and traffic management. The difference isn’t capability. It’s philosophy, user experience, and whether you trust the vendor not to change the deal later.

I ran pfSense for years because it was “the standard.” Then Netgate started moving features to pfSense Plus. The line between “free” and “pay us” kept shifting. I woke up one morning and realized I was building critical infrastructure on a platform where the vendor could arbitrarily decide which features belonged to paying customers. I rebuilt on OPNsense that weekend.

Neither firewall is objectively “better.” But one might fit your tolerance for corporate shenanigans a lot better.

This guide is for homelabbers who want to pick one firewall, deploy it, and move on. You’ll know which one by the end.

💭

TL;DR:
Both OPNsense and pfSense are excellent FreeBSD-based firewalls. If you want a modern UI, more built-in features, and development that won't suddenly go closed-source, pick OPNsense. If you want conservative releases and massive legacy documentation (and trust Netgate), pfSense works fine.

Quick Comparison: OPNsense vs pfSense at a Glance

Feature	OPNsense	pfSense
License	Fully Open Source	CE: Open, Plus: Proprietary
UI Style	Modern sidebar navigation	Traditional top menu
Update Frequency	Bi-yearly major releases	Annual major releases
Built-in IDS	Yes (Suricata)	Requires package install
WireGuard	Built-in by default	Requires plugin
Security Patches	Days after FreeBSD	CE waits for Plus first
Best For	Modern workflows, open-source advocates	Conservative updates, legacy setups

Core Similarities: Why This Choice Is Hard

Both platforms do the same basic job:

FreeBSD-based firewall and router
Stateful packet inspection and NAT
VLANs, LAGG (bond NICs together), multi-WAN failover
VPN: IPsec, OpenVPN, WireGuard
Runs on bare metal or VMs
Works great on Proxmox

For basic WAN-to-LAN routing and site-to-site VPN, either one will work. You could pick based on a coin flip and be fine.

The differences matter when you live with the system for months or years.

UI and Usability: OPNsense vs pfSense Interface Comparison

OPNsense UI Philosophy

OPNsense broke from pfSense’s interface years ago. That decision has paid off.

The UI uses a left-side collapsible menu. Interfaces are under Interfaces. Firewall rules are under Firewall. Services are under Services. Interface descriptions are editable during assignment, not buried three clicks deep where you’ll never find them again.

Virtual NICs live under Interfaces, not Firewall. Intrusion Detection lives under Services, not hidden in a package submenu. When you’re trying to fix something late at night, you won’t spend five minutes hunting for the setting you need.

If you experiment, break things, and rebuild regularly, this consistency may keep you sane.

pfSense UI Philosophy

pfSense uses a top navigation bar with nested dropdowns. It works. It also shows its age.

Strengths:

More default dashboard widgets (about 22 vs OPNsense’s 17)
Consistent with documentation from 2015
Familiar if you’ve used pfSense for years

Weaknesses:

Settings scattered across Firewall, System, and Services (good luck)
Interface descriptions require extra clicks after assignment
Package settings bolted onto the side like afterthoughts

If you learned pfSense first, you know where everything is. If you’re new, you’ll spend time hunting. I’ve watched people stare at the top menu for 30 seconds trying to remember where DHCP server settings live. (Services, if you’re wondering.)

Real-World UI Example: Setting Up VLANs

To create a guest VLAN with internet access but blocked LAN access:

OPNsense:

Interfaces > Other Types > VLAN (create VLAN 10)
Interfaces > Assignments (assign to OPT1)
Firewall > Rules > OPT1 (add allow-internet rule)
Firewall > Rules > OPT1 (add block-LAN rule above it)

pfSense:

Interfaces > Assignments > VLANs (create VLAN 10)
Interfaces > Assignments (assign to OPT1)
Interfaces > OPT1 (enable and configure)
Firewall > Rules > OPT1 (add rules)

Both work. OPNsense puts VLANs under Interfaces where you’d look for them. pfSense buries VLAN creation under Assignments. One extra click that always feels wrong.

UI clarity matters? Pick OPNsense. Years of muscle memory? Stick with pfSense.

Protectli FW6C/FW6D Purpose-built for pfSense/OPNsense, this fanless firewall box is ideal for folks comparing and deploying either solution in a homelab, with reliable Intel NICs and silent operation; the main tradeoff is higher cost versus repurposing old hardware.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Plugin Ecosystems and Built-In Features

OPNsense: More Included by Default

OPNsense ships with these features enabled:

Intrusion Detection (watches your network traffic, alerts on sketchy behavior)
Traffic reporting dashboards
Monit service monitoring (restarts dead services automatically)
CPU, memory, disk widgets
Built-in WireGuard VPN

You can enable most of these without installing a plugin. Fewer plugins mean fewer things that can break during upgrades. (I learned this the hard way with pfBlockerNG, which ate an entire Saturday once.)

Optional plugins exist for SMART monitoring, Wake-on-LAN, and Zenarmor traffic inspection. But the core firewall works fine without them.

pfSense: Package-Driven Power

pfSense CE relies more on packages:

Suricata or Snort for intrusion detection
ntopng for traffic analysis (shows you what’s eating bandwidth)
SMART monitoring
Additional dashboards

The package manager is powerful. It’s also a maintenance risk. When pfSense updates the core system, packages sometimes lag. Sometimes they break. Sometimes they just stop working until the maintainer catches up.

There’s also the CE/Plus split:

pfSense CE: free, open-source (for now)
pfSense Plus: closed-source features, faster updates, tied to Netgate hardware or subscriptions

This matters if you care whether your firewall config depends on features that could disappear behind a paywall. I don’t want to wake up one day and find out the feature I rely on is Plus-only now.

Fewer plugins and more built-in functionality? OPNsense. Specific pfSense packages you can’t live without? pfSense.

The pfBlockerNG Lesson

I ran pfBlockerNG for ad blocking and threat feeds. Worked great for eight months. Then a pfSense core update hit. pfBlockerNG didn’t update in time. The firewall booted fine. DNS stopped working completely.

Spent three hours troubleshooting. Checked DNS forwarder settings. Verified upstream resolvers. Restarted services. Nothing. The logs showed DNS queries arriving but pfBlockerNG was silently dropping everything because its threat feed database was incompatible with the new pfSense version.

Removed pfBlockerNG. DNS came back instantly.

This is the package problem in miniature. When your ad blocker can take down your entire network and the logs don’t quite tell you why, you start questioning your architecture. That Saturday convinced me to rebuild on a platform with fewer external dependencies.

OPNsense vs pfSense Performance and Hardware Requirements

Hardware Requirements and Virtualization

For self-hosting, OPNsense hardware requirements match pfSense:

x86-64 CPU
4 GB RAM minimum, 8 GB recommended
2 NICs minimum (Intel NICs strongly recommended, Realtek will make you question your sanity)
SSD storage

Proxmox Deployment:

Both run well as VMs. Pass through physical NICs or use virtio adapters. Give it 2 vCPUs minimum, 4+ if you’re running IDS. Hardware offloading can cause weird issues with some hypervisors, test it. Back up your configs before hypervisor updates. (You do this already, right?)

I’ve run both on Proxmox with 4 vCPUs and 8GB RAM handling 500Mbps WAN without issues.

Real-World Performance

Both deliver similar throughput on identical hardware. The bottleneck is your NIC or CPU, not the firewall software.

On a quad-core i5 with Intel NICs, expect near line-rate for basic routing (900+ Mbps on gigabit). WireGuard pushes 600-800 Mbps. OpenVPN is CPU-bound, usually 200-400 Mbps. Turn on IDS and lose 10-30% depending on rulesets.

If your numbers are terrible, it’s probably hardware offloading or bad NIC drivers. (Realtek, I’m looking at you.)

Performance is a tie. Choose based on other factors.

Performance Benchmarks: Real Numbers

Tested on identical hardware (i5-8500, 16GB RAM, Intel i350-T4 NICs):

Routing Performance:
OPNsense: 940 Mbps WAN-to-LAN (line rate)
pfSense: 938 Mbps WAN-to-LAN (line rate)

WireGuard VPN:
OPNsense: 720 Mbps
pfSense: 710 Mbps

OpenVPN:
OPNsense: 380 Mbps
pfSense: 375 Mbps

With IDS Enabled (Suricata, 3 rulesets):
OPNsense: 680 Mbps (-27%)
pfSense: 670 Mbps (-28%)

Performance difference is negligible. Your hardware matters more than your platform.

📝

Note: These are not my numbers I had a friend who has a 1Gbps test. Made for easier math.

Update Philosophy: OPNsense vs pfSense Release Cycle

OPNsense Updates

OPNsense follows a predictable schedule:

Major releases twice yearly (January and July)
Security updates and patches as needed
Plugin updates independent of core system
Clear change logs and migration guides

The web UI shows pending updates with one-click installation. Rollback options exist if something breaks. Development is transparent. Community input matters.

Updates feel modern and reliable.

pfSense Updates

pfSense CE takes a more conservative approach:

Major releases roughly annually
Minor updates and security patches as needed
pfSense Plus gets updates first
CE trails behind (sometimes weeks)
Some features migrate to Plus-only

This frustrates people. CE users wait for security patches that Plus users already have. You’re constantly aware of what you’re missing. The free tier feels like a free tier.

For “set it and forget it” homelabs, pfSense’s slower pace could be a feature or a frustration. Depends on your perspective.

Regular updates and transparency? OPNsense. Conservative updates and slower pace? pfSense.

Dell OptiPlex 7070 Micro A cost-effective, quiet mini PC that can be repurposed as a pfSense/OPNsense box for homelab beginners, though it lacks multiple NICs out of the box and will require USB or PCIe NICs for full functionality.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Trust and Long-Term Viability

This is where it gets personal.

OPNsense:

Fully open-source, no proprietary split
Community-driven development
No vendor lock-in
Decool GmbH sponsors but doesn’t control features

pfSense:

Netgate controls everything
CE is open, Plus is closed
CE feels like the free tier of a paid product
Netgate’s business goals don’t align with homelab users

I switched to OPNsense because I don’t want my firewall’s future tied to quarterly earnings calls. pfSense CE isn’t dying tomorrow. But I don’t like the trajectory.

When a company starts moving features behind paywalls, it doesn’t stop. It accelerates. I’ve seen this before.

Open-source purity matters? OPNsense. Netgate ecosystem matters more? pfSense.

My Migration Weekend: What Actually Happened

I ran pfSense for four years before switching. The migration took six hours over one weekend.

Saturday - Setup and Config Migration

Spun up OPNsense VM on Proxmox. Exported pfSense config to XML, tried importing. It accepted the file but only 60% transferred cleanly.

What worked: Interface assignments, VLANs, basic firewall rules, DHCP scopes.

What broke: NAT rules needed manual recreation. VPN configs had to be rebuilt from scratch. DNS forwarder settings didn’t transfer.

WireGuard rebuild: 20 minutes.

Sunday - Testing and Cutover

Ran both firewalls in parallel for testing. Shut down pfSense, changed VLAN assignments on switch, updated DHCP gateway IPs.

Total downtime: about 20 minutes.

Kept pfSense VM around for two weeks as backup. Never needed it.

What I’d Do Differently

Export VPN client configs before starting. I had to message six people with new configs during the cutover.

Test VLAN isolation more thoroughly. Found a misconfigured rule Monday morning that let guest traffic reach management VLAN. Fixed in five minutes but should’ve caught it Sunday.

Been running OPNsense for 18 months now. No regrets.

When You Should Stay on pfSense

Don’t switch if:

You have complex pfBlockerNG configs you can’t easily recreate.
- Zenarmor exists on OPNsense but it’s not identical. If you’ve got custom threat feeds and DNSBL configs that took months to tune, migration pain might not be worth it.
Your network depends on pfSense-specific packages.
- Some packages don’t have OPNsense equivalents. Check before committing to migration.
You have working configs and no pain points.
- Migration has costs. If pfSense works, and you’re not frustrated, stay put. I switched because the CE/Plus split bothered me and I had a package break. If you don’t have these problems, you don’t need to solve them.

Practical Decision Guide for Homelab Firewalls

Ask yourself:

Modern UI that reduces mistakes? → OPNsense
Rely on specific pfSense packages? → pfSense
Care about open-source purity? → OPNsense
Want ultra-conservative updates? → pfSense
Run everything in Proxmox VMs? → Either works, OPNsense slightly easier
Need maximum plugin flexibility? → pfSense

If you’re undecided, install both in VMs. Spend an afternoon configuring VLANs and WireGuard. Your preference will become obvious. Don’t agonize over this for weeks. Spin them up, click around, pick one.

Decision Tree: Which Firewall Should You Pick?

Do you already run pfSense with no issues?
- YES → Stay on pfSense (don’t fix what isn’t broken).
- NO → Continue…
Do you rely on pfSense-specific packages?
- YES → Stay on pfSense (migration pain isn’t worth it).
- NO → Continue…
Does the CE/Plus split bother you?
- YES → Switch to OPNsense.
- NO → Continue…
Do you want a modern UI with better organization?
- YES → Switch to OPNsense.
- NO → Continue…
Do you want faster security updates?
- YES → Switch to OPNsense.
- NO → Stay on pfSense (conservative updates suit you).

If you end up at “Stay on pfSense” but still feel uncertain, that uncertainty is telling you something. Listen to it.

Common Mistakes That Will Bite You

Don’t Virtualize on Hardware You’re Using for Other Things

Your firewall VM needs dedicated hardware or a hypervisor that’s always on. I’ve watched people wonder why their network dies when they reboot their workstation to install updates. Because your firewall is on it. Obviously.

Run your firewall on a dedicated box, a separate hypervisor, or accept that rebooting your daily driver takes down your entire network. There’s no middle ground here.

Don’t Skip Backups Before Updates

Both platforms make this easy:

OPNsense: System > Configuration > Backups > Download configuration

pfSense: Diagnostics > Backup & Restore > Download configuration as XML

Save it locally with the date in the filename: firewall-backup-2026-01-31.xml

Do this before updates. Do this before changing anything important. Do this monthly even if you’re not changing anything. Store it somewhere that’s not the firewall. Your NAS, your workstation, cloud storage, doesn’t matter. Just not on the firewall itself.

When (not if) you need to restore, you’ll thank past-you for being paranoid.

Don’t Enable Every IDS Rule

More rules ≠ more security. You’ll kill performance and get flooded with false positives you’ll ignore.

Start with recommended rulesets. Monitor for a week. Add more only if you need them. I ran with three rulesets for 18 months before adding a fourth. You don’t need 47 different threat feeds.

Don’t Use Realtek NICs If You Can Avoid It

They work. They also cause weird throughput issues, driver headaches, and inexplicable packet loss under load.

Intel NICs cost $20 more used on eBay. Buy Intel. The i350-T2 and i350-T4 are solid choices. Your future self will appreciate it when you’re not troubleshooting phantom network issues at midnight.

Don’t Trust Default Settings for Production

Both platforms ship with sensible defaults for home use. But “sensible defaults” means:

No firewall rules blocking RFC1918 (private IP addesses) traffic on WAN (fine for home, terrible for dual-WAN or VPS)
DNS resolver allowing queries from all interfaces (convenient, not secure)

Review the defaults. Adjust for your environment. Lock down access to the web UI. Enable stricter firewall rules. Don’t assume “default” means “secure.”

Minimum Viable Firewall Setup

Stop overthinking the initial config. Day one, you need:

WAN interface configured - DHCP from ISP or static IP, whichever your ISP provides
LAN interface with DHCP enabled - Both do this automatically during install
Default allow rule on LAN - Both create this automatically
DNS set to upstream resolvers - 1.1.1.1 and 8.8.8.8, or your preference

That’s it. Everything else is optional.

VLANs? Add them when you need device isolation.
VPNs? Add them when you need remote access.
IDS? Add it when you want visibility into traffic.
Custom dashboards? Add them when the defaults feel limiting.

Start simple. Add complexity only when you have a specific need. Your firewall’s job is routing packets and blocking threats, not looking impressive in screenshots.

Troubleshooting Common OPNsense and pfSense Issues

Internet Works, but Throughput Is Terrible

What you see: Slow speeds despite fast connection

The fix: Disable hardware offloading first. This is the most common culprit.

OPNsense: Interfaces > Settings > Disable “Hardware CRC”, “Hardware TSO”, “Hardware LRO”
pfSense: System > Advanced > Networking > Disable all hardware checksum offloading

Reboot. Test again.

If that doesn’t fix it, check IDS rulesets. Too many active rules kills performance. System > Intrusion Detection > Download > verify only 2-3 rulesets are enabled.

Reboot. Test again.

If that doesn’t fix it, check IDS rulesets. Too many active rules kills performance. System > Intrusion Detection > Download > verify only 2-3 rulesets are enabled.

Verify your NIC drivers are loaded correctly:

# SSH into firewall, check what driver your NIC is using
ifconfig -a | grep -A 4 "em0"

If you see “re0” (Realtek), you found your problem. Intel NICs use “em”, “igb”, or “ix” drivers. Realtek uses “re”. Replace the NIC.

If you’re seeing 100 Mbps on gigabit, the NIC negotiated wrong. Check System > Interfaces > [Interface] and verify it’s set to auto-negotiate or manually force 1000baseT full-duplex.

VPN Is Slow

What you see: WireGuard or OpenVPN performing poorly

The fix:
Verify WireGuard is using kernel implementation (not userspace).
Check VPN > WireGuard > Instances > verify “Type” shows kernel implementation.

Disable unnecessary logging (verbose logging kills performance).
VPN > WireGuard > Advanced > set log level to “error” only.

Test without IDS. Suricata inspecting VPN traffic = very slow.
Services > Intrusion Detection > disable temporarily, test VPN speed.

WireGuard should be fast. If it’s not, your config or hardware is wrong.

Upgrade Broke Something

What you see: Features missing or broken after update

The fix:
Restore config backup (you made one, right?).
System > Configuration > Backups > restore previous config.

Check package compatibility in changelogs.
Before updating, read the release notes. They list package compatibility issues. Review deprecated features list. Sometimes features get removed. Check migration guides.

Test packages individually after core upgrade.
Update core first, reboot, then update packages one at a time.

Restore your backup. Try again. Five minutes reading release notes can save an hour troubleshooting. (Yes, I have learned this the hard way.)

Security Differences That Actually Matter

Both platforms are secure by default. The differences are operational, not architectural.

OPNsense Security Advantages

Two-factor authentication built-in. No plugin needed. System > Access > Users > [Select User] > Generate new secret. Works with Google Authenticator, Authy, or any TOTP app.

IDS integrated and easier to configure. Services > Intrusion Detection > Download tab. Select rulesets, enable IDS, done. No separate package installation or config files to manage.

Faster security patches. No CE/Plus delay. When a FreeBSD security advisory drops, OPNsense patches hit within days. pfSense CE users wait for Plus to get patched first.

More frequent security updates. Bi-yearly major releases plus security patches as needed. pfSense CE releases are annual with longer gaps between security updates.

pfSense Security Advantages

More mature IDS rulesets. Snort has been around longer than Suricata. More documentation, more tuned rules for specific scenarios. If you need very specific detection rules for niche attacks, pfSense’s Snort documentation is a deep rabbit hole.

More third-party security plugins. ntopng integration is tighter. More options for anomaly detection and traffic analysis. If you want to build a full security monitoring stack, pfSense has more plugin options.

More documented attack mitigation examples. Decade of forum posts, blog tutorials, and Stack Overflow answers. If you’re mitigating a specific attack, someone’s documented how to do it on pfSense.

What Actually Matters

Neither platform has had a major security incident in recent years. Your security posture depends more on configuration than platform choice.

Common security mistakes I see:

Web UI exposed to WAN (don’t do this)
Default admin passwords (change them immediately)
No firewall rules blocking RFC1918 on WAN (matters for dual-WAN setups)
Permissive outbound rules on LAN (most people allow all, should be more restrictive)

Fix these regardless of platform. A misconfigured OPNsense box is less secure than a properly configured pfSense box, and vice versa.

What Surprised Me After Switching

OPNsense updates are faster. pfSense updates took 10-15 minutes and always required a reboot. OPNsense updates finish in 2-3 minutes. Most don’t need a reboot. The few that do reboot in under 60 seconds.

The documentation is different. pfSense has more forum posts and third-party tutorials dating back to 2008. Google any pfSense problem and you’ll find 47 blog posts about it. OPNsense has cleaner official docs but fewer community tutorials. Took me a few weeks to adjust to reading official docs instead of blog posts.

Built-in features I didn’t know I wanted. Monit caught a failing DNS resolver once and restarted it before I noticed. I woke up, checked logs, saw “unbound died, Monit restarted it 3 hours ago.” That alone justified the switch. On pfSense I would’ve woken up to “DNS is broken” messages from family.

The community is smaller but more active. pfSense has more users. OPNsense has more engaged users. Forum questions get answered faster on OPNsense because there are fewer “have you tried turning it off and on again” responses. People assume competence.

Plugin updates don’t break things. Because most features are built-in, there are fewer plugins to break during core updates. I haven’t had a plugin break in 18 months on OPNsense. On pfSense, I had plugin breakage every 3-4 months.

Quick Wins After Installation

First 30 minutes with either platform:

Change default admin password
Enable automatic config backups
Set up 2FA (OPNsense: built-in, pfSense: use package)
Configure DNS over TLS (prevents ISP snooping)
Enable basic IDS with recommended rulesets
Test failover to backup DNS resolver

Do these immediately. Everything else can wait.

What I Was Wrong About

I thought migration would take all weekend. Took six hours of actual work. Most of that was rebuilding OpenVPN configs because I didn’t export them properly first.

I thought I’d miss pfSense packages. Haven’t needed a single pfSense-specific package in 18 months. Everything I relied on either exists natively in OPNsense or has an equivalent plugin.

I thought OPNsense would be less stable. It’s been rock-solid. Only reboots are for updates. Uptime between reboots averages 6-8 weeks. On pfSense I was rebooting every 3-4 weeks when packages broke.

I thought the smaller community would be a problem. Smaller community means better signal-to-noise ratio. Questions get answered by people who actually know the codebase, not people guessing based on pfSense experience.

I thought performance would be identical. It is, mostly. But OPNsense’s update speed and reboot time makes maintenance faster. Shaving 10 minutes off update time doesn’t sound like much until you’re doing it monthly.

When Your Firewall Is Good Enough

Stop tweaking when:

WAN to LAN routing works at line rate
VPNs connect reliably and stay connected
You haven’t touched the config in a month
Uptime is measured in weeks, not hours
Family/roommates don’t complain about the network
You stop checking the dashboard daily

Your firewall’s job is to be invisible. Once it disappears into the background, you’ve won. Move on to other projects.

The best firewall is the one you forget about. If you’re thinking about your firewall daily, something’s wrong. Fix it or replace it.

MINISFORUM MS-A2 Nice to have, not required. Why it fits this post: With multiple 10GbE and 2.5GbE ports, this mini workstation offers flexible, high-performance hardware for running OPNsense/pfSense or as a multi-role homelab node, though it may be overkill for simple firewall-only setups.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

FAQs: OPNsense vs pfSense for Homelabs

➤ What's the easiest firewall for a homelab?

OPNsense. Better UI, fewer required plugins. You’ll spend less time hunting through menus.

➤ Does OPNsense run better on low-end hardware than pfSense?

No meaningful difference. Hardware quality matters more. A good Intel NIC beats a bad Realtek NIC regardless of firewall choice.

➤ Why do pfSense updates feel delayed?

pfSense CE trails pfSense Plus. Netgate prioritizes Plus for paying customers. CE gets updates eventually. You wait.

➤ How do I set up WireGuard without plugins?

pfSense requires installing the plugin. OPNsense ships with it by default.

➤ Is OPNsense's IDPS as good as pfSense + Suricata?

They both use Suricata. Same engine, same rules, same detection. OPNsense integrates it cleaner.

➤ pfSense menu is confusing, how does OPNsense compare?

OPNsense uses a left-side menu with clearer grouping. Things are where you’d expect them. Not revolutionary, but noticeably better.

➤ Can I trust Netgate long-term?

Netgate is a for-profit company. They need revenue. OPNsense is community-driven. If the CE/Plus split bothers you now, it’ll only get worse. Pick accordingly.

➤ Best plugins for homelab monitoring?

ntopng on pfSense for traffic analysis. Zenarmor on OPNsense for deep packet inspection. Both work well.

➤ How do I migrate from pfSense to OPNsense?

Export XML config, import selectively, manually verify interfaces and rules. Plan for manual reconfiguration. Not one-click, but doable in an afternoon. (Make a backup first. Obviously.)

Conclusion: Pick Your Homelab Firewall and Move On

In 2026, choosing between OPNsense and pfSense isn’t about raw capability. It’s about philosophy, workflow, and trust.

pfSense is powerful, stable, and widely documented. OPNsense feels more modern, more open, and more forgiving when you experiment.

I want my firewall to fade into the background. For me, that’s OPNsense. For you, it might be pfSense.

Pick one. Document your setup. Back up before upgrades. Get back to building the fun parts of your homelab.

Your firewall should be boring. That’s the whole point.

Sources

Official Documentation

Visit

Official Documentation

Visit

How to Install, Configure, and Migrate to a Consolidated PostgreSQL Server

Sat, 17 Jan 2026 06:48:12 -0700

If you’re running more than a couple of Docker stacks, chances are you’re also running more PostgreSQL containers than you want to admit. I hit my breaking point at six separate Postgres containers, each with its own volume, backup strategy, and maintenance quirks. Every time I ran: docker compose pull && docker compose up -d it felt risky.

Consolidating PostgreSQL databases into a single dedicated server eliminates scattered backups, reduces resource bloat, and makes future migrations trivial, which is exactly what you want from a database. In this guide, you’ll learn how to install PostgreSQL on Debian, configure remote database access, and migrate Docker PostgreSQL containers to a centralized VM without breaking your apps or losing data.

This PostgreSQL migration guide moves you from multiple Docker-based instances to one dedicated server running in a Debian 13 VM on Proxmox. Expected downtime: 10-30 minutes per app during migration. Risk level: Medium, but I’ll also cover recovery strategies.

This is written for users who already understand Docker, basic Linux administration, and Postgres fundamentals, but want a clean, repeatable way to consolidate databases.

💭

TL;DR: Create a Debian 13 VM in Proxmox, install PostgreSQL natively, enable secure remote access, migrate each Docker database using pg_dump, then update your Docker stacks to point at the new centralized server for simpler management and backups.

Why a Dedicated PostgreSQL VM Beats Multiple Containers

Before running any commands, let’s talk about why this is worth the effort.

When each Docker stack runs its own Postgres container, you’re dealing with:

Duplicated memory and CPU usage across every instance
Backups scattered across volumes (good luck finding the right one when you need it)
Version upgrades happening at different times (or not at all)
Monitoring and tuning that’s inconsistent at best

A single PostgreSQL server in a VM gives you:

One place to back up and restore, your future self will thank you
Centralized performance tuning that actually matters
Cleaner Docker stacks with fewer moving parts
Easier upgrades and security patching (do it once, not six times)

Here’s the thing: databases need to be treated as infrastructure, not app dependencies. Treating Postgres like shared infrastructure pays off quickly. I wish I’d done this years ago.

More details on why you should do this:

My post on why you should consolidate your PostgreSQL Docker Containers in to on consolidated VM

Visit

Prepare the Proxmox VM (Debian 13)

VM Sizing and Creation

In Proxmox, create a new VM with these baseline specs. These specs work well for 5 to 10 typical homelab apps:

OS: Debian 13 ISO
CPU: 2 to 4 cores
RAM: 4 to 8 GB
Disk: 20 to 50 GB SSD, VirtIO
Network: Bridge to your homelab subnet
Enable QEMU Guest Agent in VM options

PostgreSQL benefits more from RAM and fast storage than raw CPU. If you have the memory to spare, err on the side of more, you won’t regret it.

Install Debian 13 (Minimal)

During the Debian installer:

Choose a minimal install, no desktop environment (you don’t need it)
Assign a static IP, saves headaches later
Install openssh-server, so you can manage the VM remotely with SSH

After the first login, update the system and install the QEMU guest agent:

sudo apt update && sudo apt upgrade -y
sudo apt install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

The guest agent improves shutdown handling, IP reporting, and backup consistency in Proxmox. It’s not required, but it’s one of those “install it now, appreciate it later” things.

MINISFORUM MS-A2
This compact mini-workstation offers powerful CPU options and serious I/O, making it ideal for running a consolidated PostgreSQL server in a Proxmox VM with room for future growth.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Install PostgreSQL on Debian 13

Decision: Default Debian Repo or Official PostgreSQL Repo?

Alright, this is the first real fork in the road. Your choice here affects file paths and version numbers for the rest of the guide.

Option A: Debian default repository (RECOMMENDED)

Pros: simpler, stable, fewer surprises
Cons: version may lag behind upstream (Debian 13 uses PostgreSQL 17)
Install paths: /etc/postgresql/17/main/
Service name: postgresql

Install with:

sudo apt update
sudo apt install -y postgresql postgresql-contrib

Option B: Official PostgreSQL APT repository

Pros: access to PostgreSQL 18 or newer features
Cons: slightly more setup complexity, one more thing to maintain
Install paths: /etc/postgresql/18/main/
Service name: postgresql

If you want the latest features:

sudo apt install -y curl ca-certificates
sudo install -m 0755 -d /etc/apt/keyrings
curl -o /etc/apt/keyrings/pgdg.asc https://www.postgresql.org/media/keys/ACCC4CF8.asc
sudo chmod a+r /etc/apt/keyrings/pgdg.asc

echo "deb [signed-by=/etc/apt/keyrings/pgdg.asc] https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" | sudo tee /etc/apt/sources.list.d/pgdg.list

sudo apt update
sudo apt install -y postgresql-18 postgresql-contrib-18

📝

Note: The rest of this guide assumes Debian 13’s default PostgreSQL 17. If you chose PGDG, replace /etc/postgresql/17/main/ with /etc/postgresql/18/main/ in all config file paths. I know, I know, it’s annoying, but that’s the price you pay for bleeding edge.

Verify the Service

PostgreSQL starts automatically after installation. Let’s make sure it’s actually running:

sudo systemctl status postgresql
sudo systemctl enable postgresql

If you see “active (running)”, you’re golden. Now access the admin shell:

sudo -i -u postgres psql

You should see the postgres=# prompt. Check your version with SELECT version();
Output should look like this:

postgres=# SELECT version();
                                                      version                                                      
-------------------------------------------------------------------------------------------------------------------
 PostgreSQL 17.7 (Debian 17.7-0+deb13u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit

Then exit with \q.

MINISFORUM MS-01 Mini Workstation
Its multiple NVMe slots and dual 10G SFP+ networking make it a practical, quiet, and efficient choice for hosting a dedicated PostgreSQL server and handling VM workloads.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Configure PostgreSQL for Remote Access

By default, PostgreSQL only listens on localhost. That’s good for security, but useless for Docker containers on other hosts. Let’s fix that.

Enable Network Listening

Edit postgresql.conf (adjust path for your version):

sudo nano /etc/postgresql/17/main/postgresql.conf

Find and set:

listen_addresses = '*'

This allows PostgreSQL to listen on all interfaces. Don’t worry, access control is handled separately, so you’re not opening the floodgates here.

Configure Client Authentication

Edit pg_hba.conf:

sudo nano /etc/postgresql/17/main/pg_hba.conf

Add a rule for your Docker subnet(s) and your LAN. For example:

# LAN Subnet
host    all     all     172.27.0.0/24     scram-sha-256
# Docker 1 Subnet
host    all     all     172.17.0.0/16     scram-sha-256
# Docker 2 Subnet
host    all     all     172.18.0.0/16     scram-sha-256

Use scram-sha-256 authentication instead of md5 where possible. It’s more secure and the modern default. Your Docker clients will handle it fine.

Restart PostgreSQL:

sudo systemctl restart postgresql

Firewall the Database

Never expose PostgreSQL to the internet. Just don’t. Lock it down to your trusted subnets.

Using UFW:

sudo apt install -y ufw
sudo ufw allow from 172.17.0.0/16 to any port 5432 proto tcp
sudo ufw enable

Verify it is working:

sudo ufw status

Adjust the subnet to match your Docker hosts or Proxmox bridge. If you’re not sure what subnet to use, check your Docker network with docker network inspect bridge.

It should look like this when you are done:

Status: active

To                         Action      From
--                         ------      ----
5432/tcp                   ALLOW       172.27.0.0/24             
22/tcp                     ALLOW       Anywhere                  
5432/tcp                   ALLOW       172.18.0.0/16             
5432/tcp                   ALLOW       172.17.0.0/16

Checkpoint:

From another host or container already running Postgres, test connectivity.

docker exec -it <container_name> /bin/bash

Run this to test if the firewall is allowing traffic on this subnet

psql -h <vm_ip> -U postgres

If it connects and asks for a password, you’re good.
Press ctrl-c to abort the connection and exit to leave the container.

If it fails, check logs with:

journalctl -u postgresql

Nine times out of ten, it’s either pg_hba.conf or the firewall. Double-check both.

Create Users and Databases for Docker Apps

Here’s where a lot of people mess up: they dump everything into a single database with a single superuser. Resist that urge.

Identify Existing Containers

On your Docker host(s):

docker ps | grep postgres

Make a list of containers, databases, and users. Seriously, write it down or put it in a text file. You’ll reference it constantly.

⚠️

Warning: I recommend that you DO NOT consolidate the Immich Postgres database. They use older versions of Postgres and Postgres extensions. I tried to do this and wasted quite a few hours, and then I realized that if I got it working it would be a pain to update in the future. Just leave it in a docker container unless you REALLY know what you are doing.

Create a dedicated role and database per application. It makes troubleshooting and permissions way simpler later.

sudo -i -u postgres psql

Example:

CREATE ROLE ExampleUser WITH LOGIN PASSWORD 'StrongPasswordHere';
CREATE DATABASE example_db OWNER ExampleUser;

Repeat this for each former Docker-based Postgres instance. Yeah, it’s a bit tedious, but you only do it once.

Test access:

psql -h localhost -U ExampleUser -d example_db

If you see the example_db=> prompt, you’re set. Exit with \q.

💡

Tip: Matching users and database names to applications (like example and example_db) makes your life so much easier six months from now when you’re trying to remember which database belongs to what.

Migrate Docker PostgreSQL Databases to Dedicated Server

Alright, this is the heart of the PostgreSQL migration process. Take your time here, rushing this step is how you end up restoring from backups (You have backups right? RIGHT?).

Handle Extensions and Ownership Issues First

Before dumping, identify potential problems. This saves you from “why won’t it restore?” headaches later:

# Check for extensions
docker exec -it <container> psql -U <user> -d <db> -c "\dx"

# Check for custom roles
docker exec -it <container> psql -U <user> -c "\du"

Common issues you’ll hit:

Extensions like pg_trgm or uuid-ossp may need manual creation on the target server
```
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
```
Role ownership conflicts between different container dumps (especially if you’re using pg_dumpall)

Dump the Data

Decision point here:

Small homelab DBs (under a few GB): dumping while containers are running is usually fine
Larger or critical DBs: stop the app container first to guarantee consistency

For single database (recommended):

docker exec -it <container> pg_dump -h 127.0.0.1 -U postgres -d example_db --format=plain --no-owner --no-privileges > example_dump.sql

The --no-owner --no-privileges flags avoid role and ownership conflicts during restore. You’ll set ownership manually on the new server anyway.

For all databases and roles (advanced, usually overkill for homelabs):

docker exec -it <container> -h 127.0.0.1 pg_dumpall -U <user> > full_dump.sql

Watch the output. If you see errors about missing permissions or roles, that’s your cue to use --no-owner --no-privileges.

Transfer Dumps to the VM

Use scp or VSCode to download and upload to the new server:

scp db_dump.sql user@postgres-vm:/tmp/

If you’ve got multiple dumps, throw them all in /tmp/ on the VM. Just remember to clean them up later.

Restore into the New Server

On the PostgreSQL VM:

psql -h localhost -U ExampleUser -d example_db -f /tmp/db_dump.sql

Repeat for each application. Yeah, it’s repetitive. Put on some music.

If you hit extension errors like “extension uuid-ossp does not exist”, install them manually:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

Most common extensions you’ll need: uuid-ossp, pg_trgm, hstore. Install them as needed.

The Samsung 9100 PRO 2TB
Great choice for a PostgreSQL database because its very high IOPS and low latency keep reads and writes snappy under load, while the sustained throughput helps with WAL logging, indexes, and vacuum/maintenance jobs without the whole system feeling sluggish.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Update Docker Stacks to Use the Central Database

This step removes PostgreSQL from your Docker stacks entirely. It’s weirdly satisfying.

In your docker-compose.yml:

Comment out the postgres service (Remove once you know it works)
Comment out volume definitions tied to Postgres (Remove once you know it works)
Update environment variables to point at the new server

Example:

environment:
  POSTGRES_HOST: <postgres_VM_IP>
  POSTGRES_DB: example_db
  POSTGRES_USER: ExampleUser
  POSTGRES_PASSWORD: StrongPasswordHere

Recreate the stack:

docker compose down
docker compose up -d

Your application should now connect to the centralized PostgreSQL server. Check the logs to make sure it’s connecting:

docker compose logs -f

If you see database connection errors, double-check your environment variables. Typos in the hostname or database name trip up 80% of people here.

Once you do this for one stack, the rest should be faster.

PostgreSQL Performance Tuning for Homelabs

Out of the box PostgreSQL settings are conservative. Here’s safe starting points for a homelab:

Edit postgresql.conf:

shared_buffers = 1GB
work_mem = 16MB
max_connections = 100

Why these settings matter:

shared_buffers: PostgreSQL’s main cache. Rule of thumb is 25% of system RAM, but too much can actually hurt performance on smaller systems. For a 4GB VM, 1GB is the sweet spot.
work_mem: Per-operation memory for sorts and joins. This multiplies by concurrent connections, so be conservative. 16MB is safe for most homelabs.
max_connections: Many apps hold idle connections. 100 is safe for most homelabs, you’re probably not hitting 50 concurrent connections anyway.

⚠️

Warning: Don’t blindly scale these up. A 4GB VM with work_mem = 64MB and 100 connections could theoretically use 6.4GB of RAM during heavy queries. This is how you OUT OF MEMORY (OOM) kill your databases.

Restart PostgreSQL after changes:

sudo systemctl restart postgresql

These settings work well for read-heavy media workloads. If you’re running something write-heavy, you’ll want to tune further, but this is a good baseline.

Troubleshooting PostgreSQL Migration Issues

Connection Refused from Docker Containers

This is the most common issue. Here’s the checklist:

Confirm PostgreSQL is listening: ss -lntp | grep 5432
Verify listen_addresses = '*' is set and not commented out
Check firewall rules with sudo ufw status
Double-check pg_hba.conf subnet and authentication method

If you’re still stuck, check the logs:

journalctl -u postgresql -n 50

Look for “connection refused” or “no pg_hba.conf entry” messages. They’ll tell you exactly what’s wrong.

pg_dump Fails with “Role Does Not Exist”

This usually means roles from the old container don’t exist yet on the new server.

Fix by either:

Creating the roles first with CREATE ROLE, or
Using --no-owner --no-privileges during dump and restore (recommended)

Using --no-owner --no-privileges is cleaner. You’re not trying to preserve complex permission structures, you just want the data.

Authentication Errors After Migration

Frustrating, I know. Check these:

Ensure passwords match what’s in Docker environment variables (no trailing spaces)
Confirm scram-sha-256 is supported by your client library (it should be)
Check for copy-paste errors in passwords, seriously, this happens more than you’d think

If you’re still stuck, temporarily switch to md5 in pg_hba.conf to isolate the issue. If that works, it’s a scram-sha-256 compatibility problem.

Performance Worse Than Before

Wait, what? Yeah, this can happen. Here’s why:

Your containers may have been memory-starved without you realizing it, so they were “fast” because they weren’t doing much
The new server is actually doing proper caching and query planning
You need to increase VM RAM or revisit shared_buffers and work_mem

Run EXPLAIN ANALYZE on slow queries to see what’s happening. Usually it’s just a matter of giving PostgreSQL more memory to work with.

Extension Errors During Restore

If you see “extension does not exist” errors, install them manually:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "pg_trgm";

Most homelab apps use a handful of common extensions. Install them once and you’re done.

FAQs

➤ How do I connect to PostgreSQL from Docker containers on a different host?

Expose PostgreSQL on the VM’s IP, allow the Docker subnet in pg_hba.conf, and ensure your firewall permits port 5432 only from trusted subnets. Never open it to the internet, really, don’t do it.

➤ What's the safest way to migrate a large Docker PostgreSQL database without downtime?

For homelabs, brief downtime is safest. Stop the app, run pg_dump, restore, then restart the app pointing at the new server. Trying to do zero-downtime migrations in a homelab is usually more trouble than it’s worth.

➤ Why can't I access PostgreSQL after install?

By default, PostgreSQL listens only on localhost. You must update listen_addresses and pg_hba.conf, then restart the service. This trips up everyone the first time.

➤ Should I use Debian repos or the official PostgreSQL repo?

Debian repos prioritize stability. Official repos give newer versions. For most homelabs, Debian’s version is the safer default. Unless you need a specific PostgreSQL 18 feature, stick with Debian’s package.

➤ How much RAM and CPU should I allocate to a PostgreSQL VM?

For 5 to 10 small apps, 2 to 4 CPU cores and 4 to 8 GB RAM is sufficient. PostgreSQL benefits more from RAM than CPU. If you’re running out of resources, add RAM first.

➤ Can I migrate Docker PostgreSQL databases while containers are running?

Yes, for small databases (under a few GB). For consistency, stopping the app container is safer. The downtime is usually under 10 minutes, your users might not even notice.

➤ What's the QEMU guest agent used for?

It improves Proxmox integration, clean shutdowns, and backup behavior. It’s not mandatory but recommended. Install it now, and thank yourself later when you’re doing VM backups.

Conclusion

Consolidating multiple Docker-based PostgreSQL instances into a single dedicated server is one of those changes that feels intimidating but pays off immediately. You reduce clutter, simplify backups, and gain real control over your data layer.

The key takeaways:

Use a dedicated Debian 13 VM for PostgreSQL, treat it as one of your most important VMs
Keep one user and database per application (makes troubleshooting way easier)
Migrate with pg_dump --no-owner --no-privileges, not filesystem copies
Lock down network access to trusted subnets only
Handle extensions and roles proactively during migration

If you’re tired of babysitting half a dozen Postgres containers like I was, this approach will make your homelab cleaner and more predictable.

Resources

PostgreSQL Official Documentation

Visit

Debian PostgreSQL Wiki

Visit

Proxmox VE Documentation

Visit

Fractal Design Define 7 XL
This full-tower case is useful if you want a quiet, storage-heavy homelab server for Proxmox, but may be overkill for smaller or more compact builds.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Should You Consolidate PostgreSQL Databases In One VM

Fri, 16 Jan 2026 07:39:34 -0700

Why Consolidate Multiple PostgreSQL Databases Into One VM

If your homelab’s quietly accumulated half a dozen or more Postgres containers, one per Docker stack, you’re not alone. This is how it always starts: an app needs a database, the compose file spins one up, and you move on. Fast-forward a year or two, and you’re patching several Postgres containers, backing up all the separate volumes, and troubleshooting six or more slightly different configurations.

Consolidating PostgreSQL databases into a single VM eliminates operational overhead. You get centralized backups, upgrades, and better resource utilization, critical time-savers for homelabs running 3+ databases across Home Assistant, Wiki.js, Immich, and monitoring stacks. One instance means one backup strategy, one patch cycle, and one tuning target instead of managing scattered containers.

I hit that wall myself. Managing six separate PostgreSQL containers felt like busywork instead of actual homelabbing. Consolidating them into a single Postgres VM changed that overnight. Fewer moving parts, simpler backups, and one place to tune database performance.

This post explains why consolidating your PostgreSQL databases onto one VM is often the better choice for intermediate homelabbers, how it simplifies management and backups, and when you absolutely shouldn’t do it.

Who should consolidate: Homelabbers running 3+ Postgres containers with low to moderate traffic workloads like Home Assistant, Wiki.js, and monitoring stacks.

Who should not: Those with high-write databases, strict isolation requirements, or apps that need different PostgreSQL versions.

💭

TL;DR: Running all your Postgres databases on one dedicated Postgres VM reduces sprawl, simplifies backups, and cuts management overhead, as long as your workloads are modest, and you plan for resource contention.

Why Consolidating PostgreSQL Databases Matters

The hidden cost of “one database per stack” isn’t CPU or RAM. It’s operational overhead.

Every Postgres container means:

Its own data volume
Its own backup job (or worse, no backup at all)
Its own upgrade and patch cycle

From an infrastructure perspective, this is wasteful. PostgreSQL’s shared buffer cache, background workers, and WAL processes all duplicate across instances. A single instance hosting multiple databases eliminates this duplication. In my own setup, memory usage dropped from 3.2GB across six containers to 1.8GB with one consolidated instance.

For a homelab where workloads are rarely extreme, consolidation’s usually a net win.

My post on how-to consolidate your PostgreSQL Docker Containers in to on consolidated VM.

Visit

My Story: Death by a Thousand Containers

At one point, I was running six separate PostgreSQL containers:

Home Assistant
Wiki.js
Immich
A monitoring stack
Two side projects I barely touched

Each had its own compose file and volume. When it came time to back them up, I had six cron jobs dumping databases in slightly different ways. When PostgreSQL 13 went end-of-life, I had to plan multiple upgrades.

After consolidating everything into one Postgres VM, backups became a single script, upgrades happened once, and adding a new database was a 30-second task instead its own mini-project.

One Postgres VM vs One Postgres Container Per Stack

The Container-Per-App Model

This model’s popular because it’s easy to start with:

Drop a postgres: image into your compose file
Link it to your app
Forget about it

Pros:

Strong isolation boundaries
Easy to reason about for beginners
App and database lifecycles are tightly coupled

Cons:

Fragmented backups
Repeated configuration and tuning
Higher memory and disk overhead
More patching and monitoring work

This approach scales poorly as your homelab grows.

The Dedicated Postgres VM Model

In this model, you run one PostgreSQL instance on a dedicated Postgres VM. Each app gets its own database and role inside that instance.

Pros:

Centralized management and upgrades
One backup strategy for all databases
Better overall resource utilization
Easier monitoring and performance tuning

Cons:

Less isolation than separate containers
Risk of resource contention if poorly sized
Requires more up-front planning

For most intermediate homelabs, the pros outweigh the cons. You’re trading a bit of isolation for dramatically simpler operations.

MINISFORUM MS-A2 Must have for this build. Why it fits this post: Its high core count, fast networking (dual 10GbE), and flexible storage make it ideal for running a consolidated PostgreSQL VM with room for future database growth and multiple homelab workloads.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Why a VM Instead of LXC or More Containers

Postgres VM vs LXC Container

Running PostgreSQL in LXC containers is tempting. They’re lightweight and fast. But for databases, the trade-offs matter.

VM advantages for PostgreSQL:

Better I/O isolation under load
Cleaner snapshot and backup integration with hypervisors like Proxmox
Fewer surprises from shared kernel behavior
Predictable fsync behavior with dedicated virtual disks

LXC advantages:

Lower RAM overhead (200-500MB saved)
Faster startup

Proxmox-specific considerations:

Use VirtIO SCSI with “Write back” cache for VM disk performance
If you’re on ZFS, disable sync writes for the VM dataset to avoid double-fsync
For LXC, unprivileged containers require proper UID/GID mapping for Postgres

Here’s the thing: PostgreSQL’s sensitive to disk latency and I/O jitter. A VM gives you more predictable behavior, especially when multiple databases share the same instance. For a dedicated Postgres VM, this predictability’s usually worth the small overhead.

How Consolidating PostgreSQL Databases Simplifies Backups

This is where consolidation really shines.

With multiple containers, backups often look like this:

Different schedules
Different dump formats
Different retention policies
That one database you forgot about entirely

With one Postgres VM, you can choose a single approach:

Logical backups using pg_dump for each database
Physical backups using pg_basebackup
Or a full-featured tool like Barman

Because PostgreSQL’s designed to host multiple databases in one instance, unified backups aren’t a hack, they are how it should be done.

Practical example:

#!/bin/bash
DATABASES=("homeassistant" "wikijs" "immich" "grafana")
for db in "${DATABASES[@]}"; do
  pg_dump -h localhost -U backup_user -d "$db" | gzip > "/backups/${db}_$(date +%Y%m%d).sql.gz"
done

Restores are simpler too. You restore one database, not an entire container volume. When you’re staring at a corrupted Wiki.js database, you’ll appreciate the difference.

Resource Utilization and Performance

Why One Instance Is Usually Faster

Every PostgreSQL instance has overhead:

Background workers (autovacuum, stats collector)
Shared buffers (typically 128MB default per instance)
WAL processes

When you run six instances, you pay that cost six times. A single instance with six databases shares those resources way more efficiently.

The Noisy Neighbor Problem

The main risk is one database hogging resources. We’ve all been there, Immich decides to index 10,000 photos while Home Assistant’s trying to log sensor data.

Mitigations:

Separate roles per app
Per-database configuration settings
Connection pooling with PgBouncer
Monitoring query behavior

If one workload regularly exceeds 50% of available CPU or I/O, it might deserve its own instance. Consolidation’s not all-or-nothing.

GMKtec Mini PC Workstation Must have for this build. Why it fits this post: The powerful i9 CPU and ample multitasking capability provide a strong foundation for hosting a dedicated PostgreSQL VM and supporting additional homelab services on a single machine.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Should You Consolidate Your PostgreSQL Databases?

Use this quick test:

If your databases are mostly low to medium traffic, consolidate.
If one database has heavy writes or constant load, consider isolating it.
If you value simplicity over maximum isolation, consolidate.
If uptime requirements differ wildly between apps, consider partial consolidation.

Many homelabs end up with a hybrid approach: one Postgres VM for most apps, and a separate instance for the outlier that’s constantly hammering the disk.

What Homelab Software Benefits Most

A dedicated Postgres VM works especially well for apps that already support external databases.

Common examples:

Home Assistant
Wiki.js
Immich
Monitoring stacks like Grafana
Internal tools and dashboards
n8n

These apps benefit from stable connections, predictable performance, and easy backups.

Media servers that use PostgreSQL for metadata also fit well, as long as write rates are reasonable.

High-Level Migration Strategy

At a high level, migration looks like this:

Inventory your existing databases
Build a dedicated Postgres VM
Dump each database
Restore into the new instance
Update app connection strings

This is usually downtime-friendly for homelabs, but you can also stage it database by database if you’re paranoid about breaking everything at once. (I don’t blame you.)

Basic Setup for a Postgres VM

For larger homelabs (5-10 databases):

4 to 8 CPU cores
16 to 32 GB RAM
SSD or NVMe storage
PostgreSQL 16 or newer

For smaller homelabs (3-5 databases):

2 to 4 CPU cores
8 to 16 GB RAM
SSD storage
PostgreSQL 16 or newer

Key configuration ideas:

shared_buffers around 25% of RAM
effective_cache_size around 75% of RAM
Conservative max_connections with PgBouncer in front

These defaults give you room to grow without constant tuning. You can always optimize later when you actually have data showing where the bottlenecks are.

Security Considerations

Consolidation reduces the number of exposed services, which is good. But isolation now happens at the database level instead of the container level.

Best practices:

One role per app
Strong passwords or certificates
Restrictive pg_hba.conf
No shared superuser credentials

This isn’t less secure than containers if done correctly, but it does require discipline. Don’t get lazy and give everything the postgres superuser account because “it’s just a homelab.”

MINISFORUM MS-01 Mini Workstation Nice to have, not required. Why it fits this post: Its compact size, multiple NVMe slots, and real homelab networking (dual 10G SFP+ plus 2.5GbE) make it a practical, quiet option for a PostgreSQL VM, though with slightly less raw power than the top picks.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Troubleshooting Common PostgreSQL Consolidation Problems

One Database Is Slowing Everything Down

Symptoms:

High CPU or I/O usage
Other apps feel sluggish
Your spouse complains that Home Assistant’s not responding

Fixes:

Identify heavy queries with pg_stat_statements
Limit connections per app
Move the noisy database to its own instance if needed

Apps Cannot Connect After Migration

I know what you’re thinking: “I updated the connection string, why isn’t it working?”

Checklist:

Verify pg_hba.conf allows the Docker subnet
Check firewall rules
Test with pg_isready

That last one’s saved me more times than I can count. If pg_isready fails, your app’s not going to connect either.

Backups Take Too Long

Options:

Switch from logical to physical backups
Run dumps in parallel
Exclude rarely changed databases from daily dumps

Version Conflicts

You can’t mix PostgreSQL major versions in one instance. Period.

Solution:

Upgrade all databases together
Or run a second instance temporarily during migration

Yeah, this part’s finicky. Plan your upgrades carefully.

FAQs

➤ How do I prevent one database from starving others?

Use connection limits, PgBouncer, and per-database settings. Monitor resource usage and be ready to split workloads if necessary.

➤ What's the minimum VM size for 5 to 10 databases?

For typical homelab apps, 4 cores and 16GB RAM is a solid baseline. For smaller setups, 2 cores and 8GB works fine. Scale up if you see sustained load.

➤ Can I mix PostgreSQL versions in one instance?

No. One instance equals one major version. Plan upgrades accordingly.

➤ How does backup time change with consolidation?

Backups are usually faster and simpler because you avoid container overhead and duplicated jobs. One script instead of six.

➤ Is a VM really better than LXC?

For PostgreSQL, yes in most cases. VMs provide better I/O isolation and simpler snapshot workflows.

➤ What apps work best with a shared Postgres VM?

Apps with moderate workloads and good external database support, like Home Assistant, Wiki.js, and monitoring tools.

➤ How do I handle high-write workloads?

Tune WAL settings, use fast storage, and consider isolating that workload if it dominates the system.

➤ Does consolidation reduce Docker overhead?

Yes. You eliminate multiple Postgres images, volumes, and background processes.

➤ How can I migrate with minimal downtime?

Dump and restore during low-usage windows, or stage databases one at a time. For a homelab, a few minutes of downtime’s usually fine.

➤ What tools help monitor contention?

Prometheus with a Postgres exporter, pg_stat_statements, and log analyzers are all effective.

➤ Are there security risks?

The risk shifts from container boundaries to role and permission management. Follow least-privilege principles and you’ll be fine.

Resources

PostgreSQL Official Documentation

Visit

Conclusion

Consolidating all or some of your PostgreSQL databases into one dedicated Postgres VM is one of those changes that feels scary at first and obvious in hindsight. You trade a bit of isolation for dramatically simpler management, cleaner backups, and better resource utilization.

For my homelab, moving away from six separate containers was a relief. One upgrade, one backup strategy, one place to look when something goes wrong.

If you’re juggling multiple Postgres containers today, consider consolidation. Start small, monitor closely, and split workloads only when the data tells you to. Your future self, restoring a database in the middle of the night, will thank you.

Intel NUC 12 Pro (NUC12WSHi5) Nice to have, not required. Why it fits this post: This mini PC offers a balance of performance, quiet operation, and expandability for a PostgreSQL VM, but may be more limited for heavy multi-database or high-I/O scenarios compared to workstation-class options.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Why I Ditched Kodi for Jellyfin for My Media Playback

Sat, 10 Jan 2026 07:12:29 -0700

Jellyfin vs Kodi: which media server is better for you? If you’ve ever said “Kodi is awesome, but…” and then sighed, this post is for you.

Kodi was my media center for years. I loved the skins, the endless tweaks, and the feeling that I could make it do anything. But once it had to work for my wife, friends, and multiple TVs, Kodi stopped being a fun hobby and turned into an ongoing tech support job.

That’s when I finally ditched Kodi as my primary media player and moved to Jellyfin. Not Kodi with network shares. Not Kodi with a bunch of sync hacks. Not even Kodi with the Jellyfin plugin, which is good but still not the clean fix I wanted.

I switched to Jellyfin server and Jellyfin clients. It solved the three things that made Kodi painful: syncing watched status across devices, transcoding files that wouldn’t play, and sharing media remotely without being a tech support desk.

This article explains why, from the perspective of someone who’s run both for years.

💭

TL;DR: Kodi is a powerful front-end player, but Jellyfin is a true media server with simple clients. Jellyfin wins for transcoding, remote access, sharing with friends, and keeping watched status synced everywhere. For most households, that makes it the better choice.

Kodi vs Jellyfin: The Mental Model That Changes Everything

Before we get into features, you need to understand one core difference. This alone explains why Jellyfin feels easier once you switch.

Kodi: A Player First

Kodi is designed to run on the device connected to your TV. Each Kodi box:

Scans media itself
Maintains its own library database
Tracks watched status locally
Depends on the device’s hardware to play files

You point Kodi at local files or network shares, and it works great for that use case. But every device is effectively on its own unless you add extra layers like shared databases or third-party services (Like Trackt).

And look, setting up MySQL database sharing across Kodi instances? That’s a weekend project that’ll break in a few months. I could never keep the database working for more than a few months at a time.

Jellyfin: A Server With Clients

Jellyfin flips the model.

One Jellyfin server indexes your entire library
All metadata, artwork, and watched status live in one place
Every device connects as a client
The server decides whether to direct-play or transcode

For most people, one central server is simpler than maintaining multiple Kodi installations. You’re managing one thing instead of five.

Getting Started: What Jellyfin Setup Actually Looks Like

You don’t need an enterprise server to run Jellyfin. Honestly, you probably have something lying around that’ll work.

Where Jellyfin Can Run

NAS systems like Unraid or TrueNAS
Mini PCs and Intel NUCs
Old desktops
Even Raspberry Pi for light use (though transcoding will not work well)

Beginner Setup Reality Check

Install Jellyfin server - Can be installed on just about any computer it doesn’t need much
- Intel 8th Gen or newer for transcoding
Point it at your media folders - Movies, TV Shows, Music
- Can be network storage like Unraid, OpenMediaValt, or just a simple NAS
Let it scan and download metadata - This takes a while the first time
Install the Jellyfin app on your streaming device
- Like: the NVIDIA Shield, Smart TV, or even some gaming consoles
Log in and start watching - It really is just that easy

The whole process takes maybe an hour if you already have media organized. Compare that to setting up Kodi on every device you want to watch on, then explaining to your spouse why the living room TV shows doesn’t show the same watch progress on the bedroom one.

Hardware Expectations

Here’s the thing: hardware matters, but not as much as you’d think.

Mostly direct play, one or two users: any old desktop works fine
Multiple remote users, lots of transcoding: Intel Quick Sync (Intel 8th Gen or newer) or a GPU helps massively
Weak CPU with no hardware acceleration: expect stuttering when transcoding

If you’re just watching locally and your files are already in formats your devices support, you can run Jellyfin on a potato. It’s when you start transcoding 4K movies for your friend’s phone that you need real hardware.

Why Jellyfin Beat Kodi in My House

Kodi was fine when it was just me. I could tinker, fix things, restart services. But once my wife started using it daily, the friction became obvious:

Different Kodi boxes had different watched statuses
One update broke a skin and suddenly nothing looked familiar
Some files played on one TV but not another
Explaining “just back out and refresh the library” got old fast

I tried Kodi with the Jellyfin plugin, and while it helped with library sync, it still left me maintaining two layers: Jellyfin plus Kodi on every device. Every Kodi update was a potential disaster. Every new device meant configuring Kodi again.

Switching to native Jellyfin clients finally solved the problem. One app, consistent interface, no per-device configuration hell.

NVIDIA SHIELD Pro
A premium Android TV client, it offers excellent Jellyfin playback, smooth 4K HDR support, and broad codec compatibility, making it a top choice for users wanting a seamless living room experience with Jellyfin.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Jellyfin Transcoding: Making Files Play Everywhere

Alright, so here’s where Jellyfin really shines compared to Kodi.

Kodi plays files locally. If the device can’t decode the file, playback fails or stutters. Kodi has no server-side transcoding, it’s all on the client device.

Jellyfin includes a full transcoding engine based on FFmpeg. This means the server can:

Convert unsupported codecs on the fly
Downscale 4K video to 1080p for older TVs
Adjust bitrate for slow connections
Convert audio formats like TrueHD or DTS-HD to stereo

In simple terms: Your phone can now play that 4K HDR movie because Jellyfin converts it to something your phone understands, in real time.

Your friend with the ancient Fire Stick? They can watch your 4K Blu-ray rips because Jellyfin handles the conversion. With Kodi, they’d just get a black screen or stuttering mess.

Hardware Acceleration Warning

Jellyfin supports hardware-accelerated transcoding on Intel Quick Sync, NVIDIA NVENC, and AMD VA-API. When it works, your server can handle multiple streams without maxing out the CPU.

When it doesn’t work: You get stuttering, buffering, or the server crashes under load.

I know what you’re thinking: “how hard can it be?” Well, driver issues on Linux are real. Wrong permissions for hardware devices will bite you. Codec support varies by GPU generation. Test hardware transcoding with one stream before depending on it, because finding out it doesn’t work when three people are trying to watch at once is not fun.

Jellyfin + Intel QuickSync - The Complete Guide
How to install and configure Jellyfin in an unprivileged LXC container with QuickSync.

View Article

Centralized Library and Watched Status Sync

Jellyfin tracks watched episodes, movies, and resume positions down to the second. Start a show on your living room TV, pause halfway through, and resume on your phone in bed. It just works.

Kodi can sync watched status, but only if you set up a shared MySQL database, use third-party services like Trakt, or run Kodi as a front-end to Jellyfin. Jellyfin does it by default. No configuration, no third-party accounts, no database setup.

This centralized approach extends to all metadata, artwork, and library organization. Change something once on the server, and every client sees the update immediately.

This is where Jellyfin completely outclasses Kodi.

Yes, you can share Kodi libraries remotely using VPNs or SMB shares. But it usually involves explaining network paths, teaching friends how to mount drives, or giving out file share credentials.

And then they call you because it stopped working after a Windows update. Or their router rebooted. Or they got a new phone and don’t remember the setup steps.

Jellyfin Is Designed for This

Jellyfin includes user accounts, per-library permissions, bandwidth limits, and secure authenticated access. You can expose Jellyfin using port forwarding with HTTPS, a reverse proxy, or a mesh VPN like Tailscale.

⚠️

Warning: If you port forward Jellyfin, use HTTPS and strong passwords. Web-facing media servers are targets. Don’t be the person who gets their server compromised because they used “password123.”

Friends just install an app, log in, and watch. Because of transcoding, it works even on weak devices. No explaining network shares. No VPN configuration. No tech support calls at 10pm.

Common Jellyfin Pain Points to Expect

Look, Jellyfin isn’t perfect. Here’s what’ll probably trip you up:

Hardware Transcoding Failures

Driver issues on Linux (especially NVIDIA)
Wrong permissions for hardware devices (/dev/dri access problems)
Codec support varies by GPU generation

When hardware transcoding fails, Jellyfin falls back to software transcoding, which will max out your CPU. You’ll know because your server fans will sound like a jet engine.

Weak Server Performance

Software transcoding taxes weak CPUs
Multiple 4K transcodes need serious hardware
Remote users expect things to “just work” regardless of your setup

If you’re running on an old laptop with a dual-core CPU, don’t expect to transcode 4K to three people simultaneously. It just won’t happen.

Android TV App Limitations

Some cheap Android TV boxes struggle with the official app
HDR passthrough can be finicky
Third-party clients like Findroid sometimes work better

The official Jellyfin Android TV app is solid, but if you’ve got a $30 Android box from Amazon, you might have issues. Try Findroid if the official app gives you trouble.

Seagate Barracuda 24TB Internal Hard Drive
Large, affordable storage is essential for a growing media library, and this drive provides ample capacity for movies and shows, though it lacks NAS/enterprise features for heavy multi-user or RAID use.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Why Native Jellyfin Beats Kodi Plus the Jellyfin Plugin

The Jellyfin plugin for Kodi is excellent. It turns Kodi into a Jellyfin client, syncing libraries and watched status. I used it for months.

But with Kodi plus Jellyfin, you still manage Kodi settings on every device, Kodi or Jellyfin server updates can break things. Native Jellyfin clients remove an entire layer of troubleshooting.

My rule: I use Kodi plus Jellyfin for myself when I want customization. I never give Kodi to friends or family. They get native Jellyfin clients, because I value my free time.

Troubleshooting Common Issues

Playback Stutters or Buffers

First, check if the stream is transcoding or direct playing. In the Jellyfin dashboard, you can see active streams and whether they’re transcoding.

If it’s transcoding:

Enable hardware acceleration if you haven’t already
Lower client bitrate for weak devices
Consider pre-converting very high bitrate files if you’re hitting this constantly

If it’s direct playing and still stuttering, your network’s probably the issue.

High CPU Usage on the Server

Too many software transcodes happening at once
Enable hardware transcoding if available
Consider pre-converting very high bitrate files

If you see 100% CPU usage and your server’s crawling, someone’s transcoding without hardware acceleration. Fix that first.

Remote Access Works Locally but Not Outside

Verify port forwarding or VPN configuration
Confirm users are connecting to the correct external address
Check firewall rules on both the server and router

A few minutes testing this yourself saves an hour or more of back-and-forth with friends who can’t connect.

FAQs

➤ Is Jellyfin completely free like Kodi?

Yes. Jellyfin is fully open source and free, with no paid tiers. No premium features locked behind paywalls, no subscriptions, nothing.

➤ Do I need a powerful server?

Not for basic use. You only need more power if you expect multiple transcodes at once. If you’re mostly direct playing to local devices, an old desktop is fine.

➤ Can I still use Kodi with Jellyfin?

Absolutely. Kodi plus the Jellyfin plugin is a great power-user setup. I still use it on my main TV because I like the customization. But I don’t inflict it on anyone else.

➤ Is Jellyfin as customizable as Kodi?

No, and that’s intentional. Jellyfin favors simplicity over endless customization. You can theme it a bit, but you’re not building custom skins or installing dozens of add-ons.

➤ Will Jellyfin always transcode my files?

No. Jellyfin direct-plays whenever possible and only transcodes when needed. If your client supports the file format, codec, and resolution, Jellyfin just streams it directly. Transcoding only kicks in when something doesn’t match.

Conclusion: Why Jellyfin Won for Me

Kodi is still amazing software. If you love tweaking and customizing, Kodi will always have a place. I’m not saying Kodi is bad, I’m saying it’s designed for a different use case.

But for most people, especially families and shared households, Jellyfin is the better tool. One server, synced playback everywhere, reliable transcoding, easy remote access, and simple apps that just work.

I ditched Kodi not because it failed, but because Jellyfin solved the problems Kodi was never designed to solve. If you’re tired of being the household media IT department, Jellyfin might be your way out.

Ready to set up your own Jellyfin server? Check out the official Jellyfin documentation for installation guides and best practices.

ASRock Intel ARC A380 Challenger
This low-power GPU enables efficient hardware transcoding for Jellyfin, especially useful if you have multiple users or diverse client devices, but it’s not required if your clients can direct play all your content.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Resources

Jellyfin Official Documentation

Visit

Kodi Wiki

Visit

Intel Quick Sync Video Guide

Visit

How to Install and Configure Fail2Ban on your Jellyfin LXC

Thu, 01 Jan 2026 07:03:16 -0700

If you’ve exposed Jellyfin to the internet, whether through port forwarding or a reverse proxy, you’re already being scanned. Bots see an open login page and immediately start stuffing passwords trying to guess their way in.

Ask me how I know.

I had the default username jellyfin when I first setup and exposed Jellyfin to the internet. Once I did this that the account was constantly being hammered by bots that found the login page. I found it because the account would get locked by Jellyfin and I couldn’t login to watch anything. I knew better but, here I was looking at thousands of failed login attempts from IPs spread across multiple countries.

I immediately changed the default username. This helped the account was no longer getting locked out. However, the Jellyfin server was still being assaulted by bots on a daily basis. So, I knew I needed an additional layer of security. Fail2Ban was the easy choice.

This guide covers installing and configuring Fail2Ban for a Jellyfin LXC without banning yourself. We’ll cover direct exposure, reverse proxy setups, Docker-in-LXC gotchas, and monitoring bans over time.

💭

TL;DR:

Fail2Ban watches Jellyfin logs for failed login attempts and automatically blocks abusive IPs. With the right jail, filter, and network configuration, you can stop brute-force attacks in their tracks even behind a reverse proxy all without locking yourself out.

Quick Start for Experienced Users:
Create filter /etc/fail2ban/filter.d/jellyfin.conf
Create jail /etc/fail2ban/jail.d/jellyfin.local
Verify firewall backend (iptables or nftables)
Configure reverse proxy trust if needed
Test with fail2ban-regex

Why Fail2Ban Protects Your Jellyfin Server

Here’s the thing: Jellyfin has authentication and its rate limit lockout is per user not global. If it isn’t set on a user account an attacker can try thousands of passwords per hour without consequence.

Fail2Ban does this globally, and you don’t have to set it per user.

Fail2Ban does this by:

Watching log files for suspicious patterns
Counting repeated failures from the same IP
Adding firewall rules to block that IP for a set time

For context, the Jellyfin default HTTP port is 8096 and the default HTTPS port is 8920. Whether you expose these directly or run Jellyfin behind a reverse proxy on port 443 (HTTPS), failed login attempts look the same in the logs. That’s actually good news. It means one Fail2Ban config works for both scenarios.

Pre-Deployment Checklist

Answer these before touching any of your configs. Trust me, five minutes now saves an hour of troubleshooting later:

Exposure method: Direct port forwarding or reverse proxy?
Jellyfin port: Using default 8096 or custom?
Firewall backend: iptables or nftables? (Check with sudo iptables --version and sudo nft --version)
Container setup: Jellyfin directly in LXC or Docker-in-LXC?
Reverse proxy: If yes, are real client IPs logged?
Trusted networks: What IPs should never be banned?

📝

Note:

I’ll be configuring this on an unprivileged LXC running Debian 13 with nftables.

So, all of my examples will be for this setup.

Checking Your Firewall Backend

Modern Debian systems often use nftables with iptables as a compatibility layer.
You need to know which one Fail2Ban will actually use:

# Check what's actually running
sudo systemctl status nftables
sudo systemctl status netfilter-persistent

Fail2Ban works with both, but the actions you configure will differ.
Getting this wrong means bans won’t actually happen.

Installing Fail2Ban on Debian/Ubuntu LXC

Alright, let’s get Fail2Ban installed:

sudo apt update
sudo apt install fail2ban
sudo systemctl status fail2ban

If you see active (running), you’re golden. Fail2Ban starts automatically and will survive reboots.

Example:

● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; preset: enabled)
     Active: active (running) since Wed 2025-12-31 11:22:01 MST; 20h ago
 Invocation: 9a7ce4195aaa4dc48dc750363bb9b954
       Docs: man:fail2ban(1)
   Main PID: 329267 (fail2ban-server)
      Tasks: 13 (limit: 7051)
     Memory: 15.7M (peak: 24M)
        CPU: 4min 37.380s
     CGroup: /system.slice/fail2ban.service
             └─329267 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Dec 31 11:22:01 racknerd-ea37d8f systemd[1]: Started fail2ban.service - Fail2Ban Service.
Dec 31 11:22:01 racknerd-ea37d8f fail2ban-server[329267]: Server ready

MINISFORUM MS-01 Mini Workstation This mini workstation is ideal for running Jellyfin in an LXC container and experimenting with Fail2Ban, offering enough power and networking for a secure, flexible homelab setup.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Creating the Jellyfin Fail2Ban Filter

Filters live in /etc/fail2ban/filter.d/ and tell Fail2Ban what a “failed login” looks like in your logs.

sudo nano /etc/fail2ban/filter.d/jellyfin.conf

Add this:

[Definition]
failregex = ^.*Authentication request for .* has been denied \(IP: "<ADDR>"\)\.
ignoreregex =

⚠️

Warning: Jellyfin log formats can change between versions. I learned this the hard way after an update when bans mysteriously stopped working. Always test your filter after upgrades.

Test the Filter

Before going any further:

Make sure to have some failed logins today
Test the filter against your actual logs
- REPLACE: YYYYMMDD with today’s date

sudo fail2ban-regex /var/log/jellyfin/jellyfinYYYYMMDD.log /etc/fail2ban/filter.d/jellyfin.conf --print-all-matched

You should see matched lines with IP addresses highlighted.

Example:

|  [2025-12-31 07:22:27.102 -07:00] [INF] Authentication request for "test@test" has been denied (IP: "140.32.72.74").
|  [2025-12-31 07:22:28.787 -07:00] [INF] Authentication request for "test@test" has been denied (IP: "140.32.72.74").
|  [2025-12-31 07:41:08.539 -07:00] [INF] Authentication request for "test@test" has been denied (IP: "140.32.72.74").
|  [2025-12-31 07:41:10.368 -07:00] [INF] Authentication request for "test@test" has been denied (IP: "140.32.72.74").

If you see zero matches, your regex is wrong or your log path is incorrect.

💡

Tip: Don’t skip this step. I’ve wasted hours debugging jails that would never work because the filters never matched anything.

Creating the Jellyfin Jail Configuration

Jails define what happens when the filter finds matches.

sudo nano /etc/fail2ban/jail.d/jellyfin.local

Base Configuration (Without a Reverse Proxy)

[jellyfin]
enabled  = true
filter   = jellyfin
logpath  = /var/log/jellyfin/jellyfin*.log
backend  = polling

maxretry = 5
findtime = 10m
bantime  = 20m

port     = 8096,8920
protocol = tcp

action   = nftables[type=multiport]

ignoreip = 127.0.0.1/8 ::1

# Optional: add YOUR LAN subnet to ignoreip (recommended)
# Examples (pick the one that matches your network, or use the exact /24 you use)
# 10.0.0.0/8
# 172.16.0.0/12
# 192.168.0.0/16

This means: 5 failures within 10 minutes results in a 20-minute ban. Adjust these to taste, but don’t make maxretry too low or the bantime too long, you could lock yourself out when you mistype your password while trying to watch something away from home.

💡

Tip: backend = polling is needed because Jellyfin creates a new log file every 24 hours with a unique name. This allows fail2ban to read these files.

This is basics of Fail2Ban used when you are exposing your Jellyfin directly to the internet via port forwarding. I highly Recommend a Reverse Proxy rather than exposing Jellyfin directly to the internet.

I will cover more advanced setups like reverse proxies at a later date.

RaspberryPi 4GB The Raspberry Pi is a budget-friendly, low-power option if you are wanting to test Fail2Ban and Jellyfin in a lightweight, isolated environment before deploying to larger servers.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Monitoring and Maintenance

Watch Ban Activity

Want to see bans happen in real-time? This is oddly satisfying:

sudo tail -f /var/log/fail2ban.log

You’ll see IPs getting banned as they trip your thresholds. After the first few, you realize just how many bots are constantly probing your server.

Unban Yourself

Locked yourself out? It happens. From the LXC console:

sudo fail2ban-client set jellyfin unbanip 192.168.1.50

Replace with your actual IP. You’ll be unbanned immediately.

Best Practices for Fail2Ban Management

Keep bantime finite. Infinite bans sound appealing, but they’re risky. You could ban yourself permanently
Test filters after every Jellyfin update. Log formats change
Review ban logs monthly for patterns. If you’re getting hammered from specific countries, consider additional firewall rules
Document your unban procedure somewhere you can access when locked out

Troubleshooting Common Fail2Ban Issues

No bans occur: Wrong filter regex, wrong logpath, or Jellyfin’s logging level is too low. Use fail2ban-regex to debug. Also check that Fail2Ban is actually reading the log file, permissions matter.

Locked out completely: Access your LXC console (not SSH—that’s blocked too), unban manually, then add your IP to ignoreip in the jail config.

FAQs

➤ Will Fail2Ban ban my own IP?

Yes, if you exceed maxretry. Use ignoreip for your home network or keep the unban command handy. I’ve locked myself out more times than I’d like to admit.

➤ What's the difference between bantime and findtime?

findtime is the detection window, how far back Fail2Ban looks for failures. bantime is how long the ban lasts. So with findtime = 600 and maxretry = 3, you get banned if you fail 3 times within 10 minutes. The ban then lasts for bantime seconds.

➤ Does Fail2Ban work with nftables?

Yes, but verify the backend configuration matches your system. Modern Debian uses nftables but Fail2Ban might still default to iptables compatibility mode. Check your jail config.

➤ Is Fail2Ban useful for local-only Jellyfin?

Not really. It matters when Jellyfin is exposed beyond your LAN.

Conclusion: Harden Your Jellyfin Installation

If your Jellyfin instance is reachable from the internet, Fail2Ban is essential. Brute-force attempts are constant and invisible until you check your logs. I was shocked when I first looked, thousands of attempts per day from IPs all over the world.

By understanding your network topology, configuring the correct jail and action, and monitoring bans periodically, you turn Jellyfin from a soft target into a more secure service. This is just the third step in hardening your Jellyfin LXC.

You should have already:

Be using an unprivileged LXC - LXC Guide for Jellyfin
Set Firewall Rules
Secured your SSH - How to secure SSH
Now Fail2Ban

I learned this by watching bad actors trying to brute-force my server for days. Now they get five tries and a timeout. Yours should too.

Next steps:

Pair Fail2Ban with HTTPS and strong passwords
Add a reverse proxy like NGINX or Caddy

Resources

Fail2Ban Official Wiki

Visit

Jellyfin Official Documentation

Visit

Protectli FW6C/FW6D This dedicated firewall appliance can help you by implementing network-level protections and monitor traffic, complementing Fail2Ban’s application-level security for a more robust homelab.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

DIYMEDIASERVER 2025 Year in Review

Sat, 27 Dec 2025 06:32:28 -0700

Looking Back at the Mess We Started With

It’s December 27th, and somehow we made it through our first year!

If you’ve been following along, you know this blog started as a therapy journal in my journey of fixing my media server that kept falling. One tower doing everything. ISP router I’d never logged into. Backups that were “I should really do that.” The classic homelab setup.

2025 was the year I finally stopped duct-taping problems and built something that actually works. Four boxes with dedicated jobs. Proxmox running things properly. Docker that doesn’t make me want to throw my keyboard. And yeah, actual backups that saved my ass more than once.

You asked the important questions. I burned my nights and weekends figuring shit out. Here’s a summary of what we accomplished in 2025.

The Big Picture

This year, DIYMediaServer turned into a complete blueprint for running your own media infrastructure. Not the “install Jellyfin and pray” tutorial. The whole thing: hardware, virtualization, networking, storage, automation, and the backup strategy that lets you experiment without worry.

If you’re still running everything on one machine with an ISP router, this 2025 review is your roadmap out. No enterprise budget required. Just better decisions and way fewer panic reboots during movie night.

The Wins: What Actually Got Published

I wrote a lot this year. Maybe too much. But every post came from a real problem I hit or a question one of you asked.

Hardware That Makes Sense

The four-box architecture was the turning point. Instead of one overworked machine doing everything badly, I split responsibilities:

The Router - Kicked the ISP router to modem-only duty and built a proper OPNsense box. VLANs, firewall rules, actual logs.

The NAS - Said goodbye to VM storage nightmares and USB drives hanging off Proxmox nodes. Dedicated hardware, proper HBAs, filesystems that won’t explode. My media library finally has a real and stable home.

The Compute Node - Apps got their own Proxmox box. One dead component used to take down everything. Not anymore. Compute crashes? Router and storage keep humming along.

The Backup Server - PBS finally got its own machine and became the “try anything without fear” box. Break something with an upgrade? Five-minute restore instead of rebuilding from scratch.

These weren’t abstract posts. They’re the exact setup I’m running, with all the gotchas I hit along the way spelled out, so you don’t have to.

Docker’s Comeback Tour

Remember when I was all-in on LXCs? Yeah, about that.

2025 was my public admission that I’d been fighting containers the wrong way. The LXC hell trilogy laid it all out: UID/GID nightmares, NFS permission walls, the “secure by default” trap that made simple media sharing an absolute nightmare.

I crawled back to Docker for the media stack and documented the whole journey. The Arr suite comparison showed exactly why throwing Radarr, Sonarr, and friends into Docker Compose is better than individual LXCs. Cleaner updates. Simpler mounts. One export to storage and done.

LXCs still have their place for lightweight services and utilities. But for media apps? Docker won, and I’m not too proud to say I was wrong.

But, I just might give LXCs another try in 2026 using a different mounting methods.

Automation That Actually Works

Your media stack should work for you, not the other way around. This year we built out the full automation chain:

Download management: SABnzbd, Radarr, Prowlarr guides that turn “I want this show” into “it’s already downloaded and sorted.” Complete with the Usenet vs torrents breakdown and SABnzbd vs NZBGet comparison.

Media processing: Tdarr running in an unprivileged LXC with QuickSync, letting your Intel iGPU chew through transcodes while you do literally anything else.

Profilarr will be covered in 2026 as an alternative to Tdarr.

The Boring Stuff That Saved My Weekends

Some posts won’t get much traffic, but they quietly prevent disasters:

parted and mount points - So your drives don’t unmount on reboot
UID/GID mapping in Proxmox - Ending the “Permission denied” screaming sessions
HBA guide - Why cheap SATA cards will ruin your ZFS pool
Debian 12 to 13 upgrade fix - The systemd credential bug that hit everyone on Proxmox 9
SSH hardening - Stop leaving root login wide open
The 24-hour NFS crash loop story - A debugging nightmare with MergerFS that taught me more about the kernel than I wanted to know

Each one small. Together? They turn “mostly works” into “boringly reliable.”

Network and Security Upgrades

The networking stack finally grew up:

Proper routing with OPNsense. VLANs separating family devices from the media stack from random IoT garbage. Pi-hole v6 on multiple nodes, synced with Nebula so your DNS actually stays consistent.

Not sexy stuff. But it’s the difference between “my Smart-Switch can somehow access my NAS shares” and “everything is where it should be and logged.”

What’s Missing?

Let me be honest about my documentation gaps, because 2026 needs to address them:

Remote access - I’ve barely touched this. You’ve got a great local setup, but accessing your media from outside your network safely? That’s the next frontier. I picked up a cheap VPS during Black Friday sales, and I’m building out a multi-part series on using it as a secure front door. Caddy for reverse proxy, Wireguard to tunnel back home, keeping your services and ISP IP hidden behind the VPS. No exposing ports directly. No hoping your ISP doesn’t change your IP. Actual security with the flexibility to access everything remotely.

NFS and MergerFS don’t play nice - The 24-hour crash loop story hinted at this, but there’s a bigger problem. NFS and MergerFS together create weird edge cases and performance issues I’ve been working around instead of fixing. Early 2026, I’m diving into VirtioFS as an alternative and rethinking how storage gets shared between Proxmox hosts and VMs. This one’s going to be a deep dive with real testing. I’ll be testing an alternative mounting method for MergerFS as well.

Monitoring and alerting - The stack is more stable now, but you’re still flying blind. When did that disk start filling up? Is Jellyfin actually responsive or just running? Uptime Kuma, Discord Alerts, Bash scripts, and simple health checks need to be covered.

Installing and Configuring Proxmox - I have talked about how I use Proxmox but, I haven’t documented how to install or configure it yet.

Hardware deep dives - The guides covered what to buy, but not enough on why. Power efficiency numbers. Noise levels. Heat management. Budgets from “I have $500” to “I can spend $2000.”

Recovery scenarios - PBS is set up, but I haven’t actually documented what a full restore looks like. Or migrating everything to new hardware.

The “complete stack” templates - I haven’t been great at creating good copy and paste solutions (Intentionally. I want you to learn not just copy and paste). But some of you have asked for more full “recipes” builds that are copy, paste, adjust to taste.

More debugging stories - I will be focusing on more real problems. The weird bugs. More Lightbulb moments documented. The “here’s what I tried that didn’t work before I found the solution.”

Where You Might Be Right Now

“Everything’s still in one box”

Start with the four-box hardware guide. Move routing off first, then storage. You don’t need to do it all at once, but every piece you split out makes the whole system more resilient.

“LXC permissions are killing me”

The LXC hell series is literally your story. Switch media apps to Docker, keep LXCs for the lightweight stuff. Your blood pressure will thank you.

“Backups? There’s a USB drive somewhere…”

PBS guide. Find a cheap mini PC, add a big drive, let Proxmox handle it. The first time you restore instead of rebuild, you’ll wonder why you waited.

“My ISP router… works?”

OPNsense build. One weekend. You’ll immediately see the difference when you can actually control what’s happening on your network.

“I’m new and this is overwhelming”

Start small. Pick the SSH hardening guide. Get one Arr app running. You don’t need the full four-box dream build on day one. Build confidence with small wins, then come back for the architecture.

Before and After

I want to be clear about what changed over the last year:

Before: One box doing everything. LXCs everywhere with permission nightmares. VM storage on a prayer. ISP router mystery settings. “Backups” = good intentions.

Now: Dedicated router, NAS, compute, and backup boxes. Proxmox with clear roles. Docker for media apps. Automated downloads with Radarr and SABnzbd. OPNsense with VLANs. PBS with actual tested restores.

Your homelab shouldn’t be a second job. It should work quietly in the background and let you actually use your media instead of constantly fixing things. Don’t get me wrong, tinkering is still fun, but I want to choose when to tinker or just sit back and enjoy a show or movie without the server interrupting.

What’s Next

2025 was foundations. Getting the architecture right, escaping container hell, setting up backups, and basic networking.

2026 is where we go deeper:

Remote access allowing sharing with friends
Monitoring and alerting that actually helps
Complete stack templates you can copy
More budget vs performance breakdowns
Disaster recovery walkthroughs
Ansible Playbooks
Better MergerFS setup
More real debugging stories

This blog exists because I got tired of forum posts from 2015 that assumed you already knew everything. The goal is making this stuff accessible. Not dumbed down. Just explained properly, with the context that matters. It is also forcing me to keep my skills sharp and to keep learning.

Setup One Thing Before New Year’s

You’ve got a week. Pick something from this year’s posts and do it:

Move your routing to OPNsense
Set up PBS
Configure proper SSH hardening
Get Radarr automating one library

One thing. Build momentum. Start 2026 with a win instead of another “I really should do that.”

You’re not just ditching Netflix. You’re building infrastructure you actually understand and control. That’s worth the effort.

Thanks for reading this year. See you in 2026.

Hit me up on Reddit or E-mail if there’s something specific you want covered. I’m making the list now.

Sync Multiple Pi-hole Servers with Nebula Sync

Sat, 13 Dec 2025 07:32:28 -0700

You add a blocklist to your first Pi-hole. Easy. Then you remember you’ve got two more Pi-holes scattered around your network. Each one needs the same update. Manually. You tab between admin pages, copying settings, and by the second one you’re asking yourself why you ever thought multiple Pi-holes was a good idea.

Nebula Sync On GitHub fixes this. It keeps multiple Pi-hole servers in sync by automatically copying blocklists, local DNS records, and settings from one primary Pi-hole to all your replicas. Change something once on the primary, and Nebula pushes it everywhere else within a few mins.

If you’re running multiple Pi-holes and you’re tired of manual updates, this guide will get you set up. If you can log into pihole/admin and run Docker, you can do this.

💭 TL;DR

Run multiple Pi-hole servers for redundancy, designate one as primary, and use Nebula Sync to automatically replicate blocklists, local DNS, and settings to all replicas without manual updates.

Quick checklist:

2+ working Pi-hole nodes (same major version, ideally v6)
One node chosen as PRIMARY (the only one you edit)
A basic understanding of Docker/Compose
Router/DHCP hands out both Pi-hole IPs (DNS) for failover

Why Sync Multiple Pi-hole Servers?

Why Run More Than One Pi-hole?

One Pi-hole works great until it doesn’t. Maybe you’re updating it at 2am and something breaks. Maybe the SD card dies. Whatever the reason, when your single DNS server goes down, your entire network loses internet. Your spouse can’t stream. The smart home stops working. You know how this goes.

Multiple Pi-holes solve this:

Redundancy: One Pi-hole fails, DNS keeps working.
Maintenance without downtime: Update one node while the other handles queries.
Better coverage: Every device stays protected during updates or failures.

The problem? Managing them manually is a pain. Every blocklist or whitelist addition, every DNS entry, every setting tweak has to be repeated on each node. That gets old fast.

Two Sync Approaches, One Clear Winner for v6

You’ve got two main options for syncing Pi-holes:

Gravity Sync is the old reliable. It’s a bash script that syncs databases over SSH. Works great for Pi-hole v5.x, but it wasn’t built for v6’s API architecture.

Nebula Sync is newer and designed specifically for Pi-hole v6’s web API. It syncs more than just gravity databases and handles the modern Pi-hole setup better.

We’re using Nebula Sync here because it’s built for v6 and just works cleaner with current Pi-hole versions.

Prerequisites and Lab Layout

What You Need

Before you start, make sure you have:

Two or more working Pi-hole servers
Each Pi-hole accessible at http://<ip>/admin or https://<host>/admin
An admin password set on each Pi-hole
Something that can run Docker (often one of the Pi-holes works fine)

RaspberryPi 4GB - Must have for this build.
Quiet, cheap, and plenty for Pi-hole + Nebula Sync.
If you’re doing heavy DNS for a big network, use a small x86 box instead.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Example Setup

Throughout this guide, I’ll use:

pihole1 at 192.168.1.10 (Primary)
pihole2 at 192.168.1.11 (Replica)

Swap in your own IPs. You can add more replicas later.

Check Pi-hole Versions (Important)

Log into each pihole/admin dashboard and check the version at the bottom of the page.

Keep all nodes on the same major version, ideally v6.x. Mixing versions causes weird issues. If they don’t match, update each node:

pihole -up

Decide Where Nebula Sync Will Run

Two common options:

Option A (simplest): Run Nebula Sync as a Docker container on the primary Pi-hole.
Option B: Run it on a separate Docker host that can reach all Pi-hole admin URLs.

For most people, Option A is easiest.

Step 1: Verify Each Pi-hole Works Standalone

Don’t skip this. If a Pi-hole is broken before you sync it, you’ll just spread the brokenness around.

On each Pi-hole:

Open http://<pihole-ip>/admin.
Log in with the admin password.
Confirm the dashboard loads and shows recent queries.
From the terminal, tail logs:

pihole -t

From a client device, temporarily set DNS to only that Pi-hole and browse a few sites.

If DNS queries show up in the log, you’re good. If not, fix networking or service issues before moving on.

Step 2: Gather URLs and Credentials

Nebula Sync talks to Pi-hole via the web API, so you need the exact URLs and passwords.

For each Pi-hole, write down:

Full admin URL, including /admin
- Example: http://192.168.1.10/admin
Admin password

Nebula expects this format:

URL|password

Example:

http://192.168.1.10/admin|SuperSecretPassword

💡

Tip: About 80% of sync failures happen because someone forgot /admin at the end of the URL. Don’t be that person.

Step 3: Create a Nebula Sync Docker Compose File

Most people deploy Nebula Sync with Docker Compose or Portainer.

Example `compose.yml`

services:
  nebula-sync:
    image: ghcr.io/lovelaze/nebula-sync:latest
    container_name: nebula-sync
    environment:
      - PRIMARY=http://192.168.1.10/admin|PRIMARY_PASSWORD
      - REPLICAS=http://192.168.1.11/admin|REPLICA_PASSWORD
      - FULL_SYNC=true
      - RUN_GRAVITY=true
      - CRON=*/5 * * * *
    restart: unless-stopped

Replace the URLs and passwords with your actual ones.

⚠️

Warning: Putting passwords directly in the compose file works but isn’t great. For better security, use a .env file:

Do this instead from the same directory where your compose.yaml file lives

nano .env

and paste this:

PIHOLE_PRIMARY_URL=http://192.168.1.10/admin
PIHOLE_PRIMARY_PASSWORD=YourSecretPassword

PIHOLE_SECONDARY_URL=http://192.168.1.11/admin
PIHOLE_SECONDARY_PASSWORD=YourSecretPassword

Then reference them in compose like this:

- PRIMARY=${PIHOLE_PRIMARY_URL}|${PIHOLE_PRIMARY_PASSWORD}
- REPLICAS=${PIHOLE_SECONDARY_URL}|${PIHOLE_SECONDARY_PASSWORD}

Now you can share your compose file and not have to worry about removing the password.

Example 2 .env `compose.yaml`

services:
  nebula-sync:
    image: ghcr.io/lovelaze/nebula-sync:latest
    container_name: nebula-sync
    env_file:
      - .env
    environment:
      - PRIMARY=${PIHOLE_PRIMARY_URL}|${PIHOLE_PRIMARY_PASSWORD}
      - REPLICAS=${PIHOLE_SECONDARY_URL}|${PIHOLE_SECONDARY_PASSWORD}
      - FULL_SYNC=true
      - RUN_GRAVITY=true
      - CRON=*/5 * * * *
    restart: unless-stopped

Key Environment Variables Explained

PRIMARY: The Pi-hole you’ll always edit manually. This is your source of truth.
REPLICAS: Pi-holes that receive config from the primary. Separate multiple with spaces.
FULL_SYNC: Set to true to sync everything Nebula supports.
RUN_GRAVITY: Tells Pi-hole to run gravity after syncing.
SCHEDULE: Cron-style interval. */5 * * * * means every 5 minutes, a good starting point.

Common mistakes:

Missing /admin
Wrong http:// vs https://
Typos in passwords

Step 4: Deploy Nebula Sync

From the directory containing your compose file:

docker compose up -d

Then check logs:

docker logs -f nebula-sync

What you want to see:

Successful connection to primary
Sync operations targeting replicas
No authentication or connection errors

If you see authentication errors, double-check those URLs and passwords. Connection errors? Verify HTTP vs HTTPS and make sure you can load the admin pages in a browser from the Docker host.

Step 5: First Sync Test with Gravity and Blocklists

Time to confirm real data is syncing.

On the primary Pi-hole:

Go to Group Management > Adlists.
Add a test blocklist or toggle an existing one.
Click Save and Update

Wait for the next Nebula run (or restart the container because who has patience?).

On the replica:

Open /admin.
Navigate to Group Management > Adlists.
Confirm the new list appears and domain counts match closely.

If it’s there, gravity syncing works. Nice.

Step 6: Sync Local DNS and Custom Entries

This is where Nebula Sync really shines compared to older tools. Custom DNS entries sync automatically.

On the primary:

Go to Local DNS > DNS Records.
Add:
- Hostname: tim.example.com
- IP: 10.0.0.50
Save.

After the next sync:

On the replica:

Open Local DNS > DNS Records.
Search for tim.example.com.
Confirm it exists and points to the same IP.

Test it:

nslookup tim.example.com 192.168.1.11

You should get 10.0.0.50.

Step 7: Day-to-Day Workflow (Primary/Replica Rules)

Once everything’s working, the rules are simple:

Always make changes on the primary Pi-hole.
Treat replicas as read-only in the UI.
Let Nebula Sync handle propagation.

You can adjust the sync frequency if needed. For most homelabs, every 5 to 15 minutes works well. More frequent syncing means less drift time but more API calls hitting your Pi-holes.

Step 8: Router and Client DNS Configuration

To actually benefit from multiple Pi-holes, clients need to know about them.

Simple Setup: Two DNS IPs

In your router’s DHCP settings:

DNS 1: 192.168.1.10
DNS 2: 192.168.1.11

Clients automatically fail over if one Pi-hole is unavailable. It’s not instant, but it works.

Advanced Option: Virtual IP

If you’re feeling ambitious, tools like keepalived can give you a single virtual IP that floats between Pi-holes. This is optional and overkill for most people.

Step 9: Testing Failover and Basic Pi-hole Tests

Make sure your redundancy actually works:

Ensure clients receive both DNS IPs from DHCP.
Stop Pi-hole on the primary or reboot the server.
Browse the web from a client.
Check the replica’s Query Log for activity.

Useful commands:

pihole -t to watch live queries
dig or nslookup against each Pi-hole IP
Visit ad-heavy sites and confirm blocks appear

Step 10: Maintenance and Updates

Updating Pi-hole

On each node:

pihole -up

Keep versions aligned to avoid API mismatches.

Updating Nebula Sync

From the compose directory:

docker compose pull
docker compose up -d

Backup Strategy

Before major changes:

Export Pi-hole config from the primary
Keep a copy offline

If something breaks:

Stop the Nebula container.
Restore the primary from backup.
Restart Nebula Sync.

Troubleshooting Common Problems

Quick Troubleshooting Table

Symptom	Likely cause	Fix
Authentication errors in Nebula logs	Wrong password or URL format	Re-check password and make sure the URL includes `/admin`
Connection errors / timeouts	Wrong scheme (HTTP vs HTTPS) or network issues	Verify `http://` vs `https://`, check firewalls, make sure the admin UI loads in a browser
Changes not appearing on replicas	FULL_SYNC disabled, schedule not running, or edits made on replica	Confirm `FULL_SYNC=true`, check logs for runs, only edit the primary
Nodes drift after updates	Mixed major versions	Upgrade all nodes; don’t mix v5 and v6
Expecting DHCP to sync	Not supported	Keep DHCP on router or manage separately

Nebula Sync Fails Authentication

Double-check admin passwords.
Confirm /admin is included in the URL.
Verify HTTP vs HTTPS.

Changes Not Appearing on Replicas

Confirm FULL_SYNC=true.
Check Nebula logs for recent runs.
Make sure changes were made on the primary only.

Mixed Pi-hole Versions

Upgrade all nodes to the same major version.
Don’t mix v5 and v6.

DHCP Expectations

Nebula Sync does not sync DHCP settings or leases. Keep DHCP on your router or manage it separately.

Beelink SER5 (Ryzen 5 5600H) Nice to have, not required.
Best for people upgrading from a Raspberry Pi who want Pi-hole plus extra Docker containers without lag, but it costs more and uses more power than a Pi.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

FAQs (Nebula Sync + Pi-hole)

➤ Can I sync more than two Pi-hole servers with Nebula Sync?

Yes. Define one primary and add multiple replicas in the REPLICAS variable. Example:

- REPLICAS=http://ph2.example.com|password,http://ph3.example.com|password

or with env:

- REPLICAS=${PIHOLE_SECONDARY_URL}|${PIHOLE_SECONDARY_PASSWORD},${PIHOLE_TERTIARY_URL}|${PIHOLE_TERTIARY_PASSWORD}

➤ Do I have to run Nebula Sync in Docker?

Docker is the most common and easiest approach for updates and isolation.

➤ oes Nebula Sync work with Pi-hole v6?

Yes. It’s designed around Pi-hole v6’s web API and HTTPS admin interface.

➤ Will Nebula Sync keep DHCP settings in sync?

No. DHCP settings and leases are node-specific and don’t sync.

➤ Can I edit settings directly on replicas?

You can, but Nebula will overwrite them on the next run. Save yourself the headache and only edit the primary.

➤ What happens if a replica is offline during sync?

Nebula will fail that run and catch up when the replica comes back online.

➤ Is it safe to mix HTTP and HTTPS?

Yes, as long as each Pi-hole is defined with the correct scheme in Nebula’s config.

➤ How often should I run the sync?

Every 5 to 15 minutes is typical for homelabs.

➤ Do I still need to run `pihole -g` on replicas?

No. Run it on the primary only. Nebula syncs the results.

➤ How do I test that everything works?

Add a test DNS record or blocklist on the primary and confirm it appears and functions on replicas.

Conclusion

Running multiple Pi-hole servers for redundancy is great until you realize you’ve tripled your management overhead. Nebula Sync fixes this by letting you treat one Pi-hole as the source of truth and having the rest automatically mirror it.

If you’re tired of juggling multiple pihole/admin pages and trying to remember which server has the latest config, this setup changes everything. Start with two nodes, get comfortable with the workflow, then add more as you need them.

Next steps:

Experiment with sync schedules
Add a third replica
Explore virtual IP failover if you want true high availability

Once you’ve got this running, you won’t go back to manual Pi-hole updates.

MINISFORUM MS-01 Mini Optional upgrade.
Best for stepping up from Pi-hole into a Proxmox mini-lab with serious networking thanks to built-in 10GbE and 2.5GbE, but it’s unnecessary overkill if you’re only doing simple Pi-hole sync.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Best Proxmox Backup Server Setup (2025): Backups That Actually Work

Mon, 01 Dec 2025 05:04:02 -0600

I deleted my entire photo library.

~40,000 photos. Years of memories. Gone in the time it takes to hit enter.

I was in the Proxmox shell, typing a command to delete an LXC I didn’t need anymore. I fat-fingered the ID. The wrong container vanished. My Immich server. The thing that held every family photo, every vacation, every moment my wife cared about preserving.

I knew what I did the instant I hit enter. That sick feeling in your stomach when you realize you just deleted something that matters.

The photos themselves were fine. I had those backed up separately. But the albums? The organization? The metadata? The hundreds of hours my wife spent sorting and curating everything? That was gone.

It took several days of painstaking work to put it all back. Re-creating albums. Re-adding photos to albums. My wife’s reaction was… let’s just say worse than when the internet went down for a few hours.

That’s when I stopped telling myself I’d set up proper backups “eventually.”

I pulled an old DOGE mining rig from 2013 out of the closet, bought a cheap 2U case, and had Proxmox Backup Server running a few hours later.

Now when things break I don’t worry about it, I just restore the backup that is always less than 24hrs old.

💭 TL;DR

ZFS, RAID, and snapshots are not backups. A dedicated Proxmox Backup Server gives you image based backups of your VMs, LXCs, and configs on a separate box. That means you can break your Proxmox compute node, or even replace it, and bring everything back in minutes instead of days.

Seagate BarraCuda Internal Hard Drive 8TB
Right now one of the best price per GB you can find. Also has a 2-year warranty.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Everyone Talks About Backups. Almost Nobody Actually Has Them.

You tell yourself the same thing everyone else does:
“I have ZFS, I am fine.”
“I have RAID, I am fine.”
“I have snapshots, I am fine.”

Before I built my backup server, I lost data more than once. I broke VMs trying to optimize things. I had to rebuild LXCs from scratch because I thought I was careful enough to not need backups. Then I thought “I use Ansible playbooks and I can reconfigure services quickly”, but Ansible doesn’t restore your actual data.

When my all-in-one server PSU died while I was at work. It took out the router, storage, and compute all at once. When it was fixed, two VMs wouldn’t boot. Likely corruption from the sudden power loss.

But I still didn’t build a backup server. Adding another box meant:
More power draw.
More complexity.
More things to maintain and update.

Then I deleted Immich.

That was the line.

What Proxmox Backup Server Actually Is

Proxmox Backup Server, or PBS, is not a fancy rsync script. It is a dedicated backup appliance for Proxmox.

It does image level backups of LXCs and VMs. That means it backs up the whole guest, not just a few config files you hope you got right. When you restore, you are putting the entire VM or container back exactly how it was.

Core PBS features you actually care about:

Deduplication
PBS breaks data into chunks and reuses them across backups. Ten backups of the same VM do not use ten times the space.
Incremental backups
The first backup is large. After that, PBS only stores the changes. That means daily backups are actually realistic.
Retention and pruning
You can set rules like “keep 7 daily, 4 weekly, 6 monthly” and PBS will handle cleanup.
Verification
PBS can verify that backups are readable. That is the part most people skip until it is too late.
Encryption, if you want it
Helpful if the box is in a location you do not fully trust.

Short version. PBS is the ctrl-z for your Proxmox stack.

Why The Backup Node Needs Its Own Box

If you run PBS on the same hardware you are backing up, you are not doing backups. You are making local copies and hoping the box never dies.

Backups should live on different hardware. Period.

Here is why PBS needs to be a separate node and not just a VM with to everything else.

Hardware failure isolation
If your compute node dies, you still have PBS. You can rebuild a fresh Proxmox host, reconnect it to PBS, and start restoring guests. If PBS lived on that same dead box, you would be staring at a pile of useless backups on disks you cannot even boot.

NAS failure isolation
Same story for storage. If your NAS dies and PBS is just another datastore on that NAS, you lose both the source and the backups in one shot.

Security isolation
If something nasty gets into your compute node or NAS, it should not be able to casually wipe your backups. PBS on its own box, with good firewall rules, is much harder to wipe.

Upgrade and experiment freedom
You want to be able to reinstall Proxmox on the compute node without touching PBS. You want to be able to test new Proxmox versions, new kernels, new storage layouts. That is only safe if your backups live somewhere else.

One simple rule:

If the thing you are backing up and the backup live on the same physical box, you do not have a backup. You have a copy.

How I Finally Built This Thing

After the Immich incident, I was done making excuses.

I had an old DOGE mining rig from 2013 sitting in a closet. Yes, a DOGE mining rig. That hardware bought during the peak of meme cryptocurrency mania was about to become the most critical piece of infrastructure in my homelab.

Intel G1610 CPU.
GIGABYTE GA-B75M-D3H motherboard.
16GB of RAM that probably worth more than the entire rig today (Thanks AI).

It never made me any money mining Dogecoin. But it was about to save my ass repeatedly.

I bought a cheap 2U Rosewill case and moved everything over. A few hours later, PBS was running.

I threw in a 128GB SSD for the PBS system and 2 4TB HDDs for backup storage. That was it.
Total cost: ~$100 for the case.
I had some old drives on hand for the OS and storage.

Now that ancient hardware backs up:

8 VMs
12 LXCs
Everything that matters in my homelab

Most guests get nightly backups. A few less critical ones get weekly backups. I keep 4 nightly backups, one monthly, then everything older gets auto pruned. And thanks to deduplication, I am only using 12% of the available storage.

If a CPU that once supported mining joke cryptocurrency can handle PBS for 20 guests, you do not need to overthink your hardware.

The first thing I did after getting PBS up and running was testing a restore. I picked my backup Pi-hole server since I run two and losing one wouldn’t matter. I backed it up. Then I deleted it on purpose.

Five minutes later it was back. Running. Working. Like nothing happened.

The relief I felt was immense. A weight I didn’t even realize I was carrying just lifted. All those years of anxiety about breaking things. All those careful, tentative changes to production services. All that tiptoeing around my own infrastructure. Gone.

This actually worked.

I have restored several LXCs and VMs at least two dozen times since then. Testing migrations. Trying new features. Breaking things to see what happens. Every time it is five minutes to get back to working.

Rosewill FBM-X2-400-HELIX
Compact Micro ATX tower with a pre-installed 400 W PSU, room for multiple 2.5 and 3.5 inch drives, and enough airflow options for a tidy budget backup server build.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

How PBS Backs Up Proxmox Better Than Your Scripts

You can absolutely hack together backups with rsync, tar, and hope. You can write bash scripts that dump configs and copy directories.

PBS is better for one reason. It speaks Proxmox.

PBS uses datastores
You create one or more datastores on the PBS box. These are just directories on disks, usually large HDDs or SSDs. Proxmox guests get backed up into those datastores.

Backups are chunked and deduped
PBS stores data in chunks. If several VMs or containers share the same data, PBS stores that data once and references it many times. This reduces space and makes incrementals light.

Backups are incremental
First backup is full. After that, PBS only needs changed chunks. You can run nightly backups without filling disks in a week.

Backups are guest aware
VM backups use snapshot mechanisms correctly. LXC backups include config and data in a consistent way. You are not racing writes like you might be with raw rsync.

Restores are simple
From the Proxmox UI you can:

Restore a VM or LXC when you break it
Restore to a new ID so you can test first
Move a guest to a different node during restore (I use this on a lot)

You don’t need to hunt down that random blog post you followed three months ago. You don’t need to remember which flags you used or how you configured the service. PBS gives you the entire machine, exactly as it was before you broke it.

What You Should Back Up With PBS

You probably do not need to PBS your entire lab. Backup the things that matter most.

Back up with PBS:

VMs that matter
- Docker stack VM
- Home Assistant or other important services
- Anything with a non-trivial config that would suck to rebuild
LXC containers that matter
- Reverse proxy
- DNS Servers
- Ansible and Playbooks
- Jellyfin / Plex
- Your media stack if you like LXCs

Things that PBS is not ideal for

Huge media libraries
40 TB of movies do not belong in PBS. That is what your NAS redundancy is for. Worst case, you redownload.
Cold archives for years
You can keep long retention if you want to, but PBS is best for working backups of services, not glacier style storage.

💡

Tip: If it would take you hours to reconfigure by hand, put it in PBS. If you can redownload or recreate it easily, do not waste PBS space on it.

A Backup Strategy That Does Not Suck

You need something simple enough that you will actually keep it.

Here is what I run and it works well:

Schedules

Nightly backups for critical VMs and LXCs (Immich, Home Assistant, reverse proxy, databases)
Weekly backups for less critical stuff (test environments, secondary services)
Backup window at 2am when nobody is streaming

Retention

Keep 4 backups total
One monthly snapshot
Everything older gets pruned automatically

This gives me short term protection against bad updates and my own stupid mistakes without eating up too much storage.

Verification

Turn on verification jobs, so PBS periodically checks backups for corruption. It is not enough to have files. You need files that actually restore.

Lightweight 3 2 1 (Future Goal)

If you want to get fancy later:

3 copies of important data
- Running VM or LXC
- PBS backup
- Optional offsite copy of PBS datastore or config
2 types of media
- Internal PBS disk
- External USB drive or another storage box
1 offsite
- Could be a cloud bucket, a box at a friend’s house, whatever

Do not overthink this from day one. Get PBS on a separate box first. Get nightly backups running. Then start thinking about offsite copies.

Networking And Security For PBS

This box protects everything else. Do not just drop it on the same flat network as your kids tablets.

Keep it on a management VLAN

Put PBS on a subnet used for servers and admin stuff
Only Proxmox nodes and your admin machine should talk to it

Lock down firewall rules

Allow only Proxmox hosts and your admin box to connect on PBS ports
Block general LAN clients from hitting the PBS web UI directly
No random IoT gear or smart TVs talking to PBS

No direct internet exposure

Do not port forward PBS from your router
If you need remote access, go through VPN
- Tailscale, WireGuard, or a similar tunnel from your admin PC

PBS doesn’t need to be a fortress, but it does need to be harder to reach and harder to destroy than the machines it is backing up.

Hardware For A PBS Node

Good news. This box does not need to be powerful. It just needs to be reliable and have enough disk.

Here is what I am actually running:

My PBS Build (2013 DOGE Mining Rig)

The hardware that failed to make me rich mining meme cryptocurrency in 2013 is now the backbone of my backup strategy.

CPU: Intel G1610 (a decade old dual core)
Motherboard: GIGABYTE GA-B75M-D3H
RAM: 16GB
System: 128GB SSD
Storage: 2 Mirrored 4TB HDDs
Case: 2U Rosewill
Backing up: 8 VMs and 12 LXCs
Current usage: 12% of 4TB after months of nightly/monthly backups

If this ancient hardware can handle 20 guests with daily backups, you definitely do not need to overthink it.

General Guidelines

4 to 16 GB of RAM is plenty for most homelabs
Small SSD for the PBS system (128GB works fine)
Big HDD or SSD for datastore (2-4TB is a good start)
CPU does not matter much, disk and network do

You probably have spare hardware sitting around that is more than capable.

Rosewill RSV-Z2800U
This is the case I use for my PBS: It is a 2U rackmount server chassis that provides plenty of drive bays and solid airflow for a homelab or small server. It is a good pick if you want a sturdy case that can grow with your storage and hardware needs.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

What Happens When You Keep Ignoring Backups

Eventually you will break something.

Maybe it’s an update that doesn’t play nice (looking at you Jellyfin) Maybe you type the wrong container ID in the terminal. A typo that destroys a something important.

Without PBS:

Stare at the error
Dig through old blog posts to remember your setup
Reinstall services one by one
Fix permissions and rewire configs
Hours disappear

With PBS:

Open Proxmox
Click restore
Pick last night’s backup
Wait five minutes
Done

Last month I upgraded Jellyfin from 10.10.07 to 10.11. The database migration failed. Pre-PBS that would have been a full day to rebuild and rescan my media. With PBS it was a five minute restore.

Before PBS, I had anxiety about touching production services. I tiptoed around my own lab.

Now I experiment freely. I test upgrades without fear. I try new configurations to see what breaks. Worst case, I lose 24 hours of data and spend five minutes on a restore.

Simple Setup Flow

Here is the high level checklist. You do not need a full tutorial to get started.

Grab a spare box or mini PC (seriously, check your closet)
Install Proxmox Backup Server on it
Add a datastore on a big disk
On your Proxmox compute node, add PBS as a backup remote
Create backup jobs for the VMs and LXCs that matter
- Daily schedule for critical stuff
- Weekly for everything else
- Reasonable retention rules (start simple)
Run the first backup and watch it complete
Do a test restore into a new VM or LXC ID
Confirm the restored guest actually boots and works
Optionally: delete something on purpose just to prove you can get it back

After that, backups go from “I should do something” to “this is just part of how the stack runs”.

What’s Next

At this point you have four roles in your on prem cloud:

Router at the edge
NAS for storage
Compute for apps and services
Backup to save you from your own bad decisions

And this backup server? It is the one that lets you sleep at night.

Best Proxmox Compute Server Builds (2025): Why Your Homelab Needs a Dedicated Compute Node

Sat, 22 Nov 2025 06:35:02 -0600

It was 8 AM on a Tuesday.

I was already at work when my phone rang. It was my wife: “Nothing is working this morning. No internet, no Jellyfin, nothing.”

I walked her through checking the server. No lights. No fan noise. She tried the power button. Nothing.

The PSU was dead. And with it? Everything. Router, storage, media server, home automation, my entire IT infrastructure in one box, dead.

I left work, drove to BestBuy, bought a new PSU, and spent the next hour getting everything back online. Four hour where my wife couldn’t work from home, couldn’t stream anything, couldn’t do basic internet tasks. Outage duration: about four hours total.

That’s when I committed to tearing it all apart.

This is Part 4 in our series, and today we’re covering the dedicated compute node. The server that runs all your applications while your router handles traffic and your NAS stores your files.

If you’re running everything on one machine right now? This is your warning shot.

💭 TL;DR

A dedicated Proxmox compute server allows you to rebuild entire Docker stacks, snapshot VMs before risky changes, and reboot for updates. All without taking down your internet or storage. On the other hand, one box means one failure takes everything down. Three boxes means isolation, stability, and the freedom to break things safely.

Why Your Homelab Needs a Dedicated Proxmox Compute Server

Running everything on one machine feels efficient. It feels smart. It is neither.

It’s complicated. And it’s fragile.

Here’s what actually happens when you cram routing, storage, and compute into a single Proxmox server:

One failure takes down everything.

One dead PSU. One bad kernel update. One stuck VM. Suddenly your internet is gone, your files are inaccessible, and your entire household is asking when things will work again.

Reboots become a crisis.

Need to apply Proxmox updates? Cool. Your router goes down. Your NAS goes offline. Every service you run disappears for ten minutes while you pray everything comes back in the right order.

Boot order becomes a nightmare.

I ran a virtualized NAS on my all-in-one Proxmox server for way too long. Proxmox wouldn’t reliably mount NFS shares before LXCs like Jellyfin tried to start. I tried systemd automounts, autofs, custom scripts, all of it. Nothing was reliable enough. Every boot was a gamble. Would Jellyfin find its media? Would the shares even mount? I’d spend ten minutes hand-holding the server back to life, restarting services manually until everything lined up.

One workload can kill everything else.

Kick off a Tdarr batch transcode job and watch your CPU pin at 100%. Now your router is struggling. DNS queries are timing out. Someone’s work VPN drops mid-call. All because you decided to transcode some files.

A full filesystem cascades.

One container fills your root partition with logs. Now your storage is broken too. Your apps won’t start. Your VMs won’t boot. And you’re stuck SSHing in to clean up the mess before anything works again.

What Separation Actually Gives You

Splitting compute away from routing and storage fixes all of this before it becomes a crisis.

Fault isolation that actually works.

A few weeks ago I completely rebuilt several LXCs and VMs on my compute box. I moved the entire Arr suite from separate LXC containers into one Docker VM. I rebuilt my Immich server from scratch. Nobody noticed. Not a single complaint. The only time my wife knew something was happening was when I asked her to let me know when her show was over so, I could reboot the server. Four minutes later, Jellyfin was back and she kept watching.

That’s what separation gives you. The freedom to break things, test things, rebuild things, all without taking down the internet or losing access to your files.

Sane boot order.

Your NAS boots after the router. NFS and SMB shares are ready and waiting. Your router is already routing. Then your Proxmox compute node boots, mounts storage paths, and starts services in a predictable order. No more race conditions. No more “will it work this time” anxiety. Things just come up clean.

Better performance across the board.

Transcoding, Sonarr indexing, torrent hashing, container updates, all of that lives on hardware designed to handle it. Your NAS focuses on serving files fast. Your router focuses on routing packets and running OPNsense. Everyone stays in their lane and does their job well.

This isn’t overkill.
This is building your homelab correctly. With purpose. So it works reliably every single time.

Intel NUC 12 Pro (NUC12WSHi5) Compact mini PC for lightweight Proxmox servers capable of GPU Passthrough, Several VMs, and LXCs.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

What the Proxmox Compute Node Actually Does

The compute node is where your Homelab apps and services live.

This is the server where you run:

Media servers: Jellyfin, Plex, Emby
Media automation: Sonarr, Radarr, Prowlarr, Bazarr, Lidarr
Download clients: qBittorrent, SABnzbd, NZBGet
Media processing: Tdarr for transcoding and file cleanup
Reverse proxy: Nginx Proxy Manager or Traefik
Remote access: Tailscale, Cloudflare Tunnel, or WireGuard
Self-hosted services: Home Assistant, Immich, Audiobookshelf, Kavita, Nextcloud

The Proxmox compute server is responsible for:

Hosting all your containers, VMs, and LXCs
Handling heavy CPU loads like video transcoding, media analysis, and file processing
Mounting storage from your NAS over NFS or SMB without breaking when mounts are slow
Exposing services safely through your router and reverse proxy
Keeping everything isolated enough that when one app crashes, it doesn’t cascade

Think of it as the app layer in your home data center architecture. Router at the edge. NAS storage at the bottom. Compute in the middle doing the heavy lifting.

Why Proxmox VE Is the Right Hypervisor for Homelab Compute

You can absolutely run everything on bare metal Linux with Docker. You can force it.

You’ll also hate yourself when you want to move a service, pass through a GPU, snapshot before an upgrade, or deal with backups that don’t suck.

Proxmox VE solves most of those problems with one installation.

Why Proxmox works so well for homelab compute servers:

Web UI that doesn’t make you want to throw your keyboard
Native support for both LXC containers and full VMs
Easy snapshots and backups that actually save you when things break
Good integration with NFS, SMB, and iSCSI for mounting external NAS storage
Straightforward PCIe and GPU passthrough for hardware transcoding
Flexible enough to grow into Proxmox clusters later if you add more nodes

LXC vs VMs vs Docker in Proxmox

You have three layers to work with in Proxmox VE:

Workload	Best Fit	Why
Lightweight Linux services	LXC	Low overhead, fast boot, easy resource limits
Full OS instances	VM	When you need complete isolation or non-Linux guests
App-level deployment	Docker	Huge ecosystem, easy configs, stacks and compose

Here’s a sane Proxmox layout pattern that actually works in production:

Proxmox VE at the base layer
A few LXC containers for core infrastructure services (reverse proxy, monitoring)
One or more VMs running Docker for your application stacks

Why use VMs for Docker instead of LXCs?

Proxmox themselves advise against running Docker inside LXC containers. Running containers inside containers gets weird fast. You’ll hit issues with nested namespaces, cgroup limitations, and storage drivers. A VM gives you clean kernel isolation and full control without the headaches.

My current Proxmox compute server setup as an example:

I’m running an Intel i5-12600K with 64 GB of RAM, a 6-disk RAID-Z2 array for protected VM and LXC storage, and a 2 TB NVMe drive for Proxmox itself plus workloads that need fast, unprotected storage.

On top of that:

Jellyfin - Runs in an LXC so I can pass through Intel QuickSync for hardware transcoding without losing the ability to share the iGPU with other containers or the Proxmox host
Docker VM for the Arr suite - Sonarr, Radarr, Prowlarr, all in one VM managed with Docker Compose
Docker VM for automation tools - n8n, Node-RED, OpenWebUI, and Home Assistant
Nginx Proxy Manager LXC - Reverse proxy handling all external access
Individual service LXCs - Audiobookshelf, Ansible, Hugo - Each doing one job, cleanly isolated

I don’t share media outside my house because cable upload speeds are trash, but inside the house I’ve never hit issues with up to three simultaneous 4K streams.

And now? I can rebuild or test elements of it without anyone noticing. This is the point of separating compute from the router and storage.

Storage Access in Proxmox Without the Pain

This is where a lot of homelab builders get burned.

Your Proxmox compute node should not be where your media lives. It should be where your media is accessed and used.

Here’s the right way to handle storage:

Media and files live on your dedicated NAS server
NAS exports storage via NFS or SMB shares
Proxmox compute box mounts those shares and passes them into LXCs and VMs

My NAS is bare metal Debian 13 with a MergerFS pool, connected to the compute box over 10 GbE. It serves both NFS and SMB shares depending on what needs them.

The Storage Migration Process

When I finally pulled storage off the all-in-one, the process was straightforward but took some planning:

Step 1: Build the new NAS first. I installed Debian 13, MergerFS, NFS, and SMB.
Step 2: Physically move the Hard Drives and HBA. Pulled the HBA and 7 drives out of the all-in-one host and moved them to the new dedicated hardware.
Step 3: Configure MergerFS, NFS, and SMB Configured the MergerFS storage pool. Configured NFS and SMB shares.
Step 4: Verify everything. I left the old storage VM off but in place for a week. Just in case anything went sideways. Once I was confident, I removed it and I haven’t looked back since.

Rules to Save You From Storage Headaches

Use consistent mount points across everything.
Pick a path structure and stick to it:

/media/storage/movies
/media/storage/shows
/media/storage/music

Mount these into your Proxmox LXCs and VMs so the paths inside match exactly. Life is dramatically easier when Jellyfin, The arr suite, and SABnzbd all agree on where /movies, /shows, and /music live.

Keep transcode and temp work on local SSD.

Let Jellyfin and Tdarr use local NVMe or SSD paths for transcoding cache and analysis. Don’t hammer your NAS with endless small writes if you don’t have to. Your NAS will thank you, and your transcodes will be faster.

Mount read-only where you can.

For plain media directories that rarely change, mount them read-only to services that only need to read. A misbehaving app can’t delete your entire movie library if it doesn’t have write access.

Network Configuration for Proxmox and NAS

Your Proxmox compute node and NAS should be on the same network for best performance. Use static IP addresses for both so your mounts don’t break if DHCP leases change.

For 1 GbE networks: This works fine for most home users. You’ll get roughly 100-115 MB/s transfer speeds, which handles multiple 1080p streams and light 4K transcoding without issues.

For 2.5 GbE networks: The sweet spot for cost vs performance in 2025. You’ll get 250-280 MB/s, plenty for heavy 4K streaming and multiple simultaneous transcodes.

For 10 GbE networks: Overkill for most, but if you’re running lots of VMs, doing heavy transcoding, or have multiple users, the 1000+ MB/s speeds make everything feel instant.

Seagate BarraCuda Internal Hard Drive 8TB
Right now one of the best price per GB you can find. Also has a 2-year warranty.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Best Proxmox Compute Server Hardware for 2025

You don’t need a screaming 1U datacenter monster for a good Proxmox homelab. You just need the right balance of CPU cores, RAM, and storage.

Here’s what that looks like.

Budget Proxmox Compute Server Build

Specs:

4-core CPU with VT-x/AMD-V support
8-16 GB RAM (minimum 8 GB)
250-500 GB SSD for Proxmox and VMs
1 GbE or 2.5 GbE NIC

Good for:

1080p media streaming with Jellyfin or Plex
2-3 simultaneous users
A handful of Docker containers in one VM
Light home automation and a few LXCs

Why 16GB of RAM?

Proxmox itself needs about 2 GB minimum. Each VM or heavy LXC will want 2-4 GB depending on workload. With 8 GB total, you can run Proxmox plus 2-3 lightweight VMs or several LXCs comfortably. Bump to 16 GB if you want headroom.

Hardware examples:

Used Dell OptiPlex 7050 SFF, HP EliteDesk 800 G3, Lenovo ThinkCentre Tiny M720q, or any decent mini PC with an Intel chip that has Quick Sync. Add an SSD, maybe bump the RAM if it’s cheap, install Proxmox VE, and you’re running.

This tier works if your needs are simple and, you’re just getting started with Proxmox homelabs.

Dell Wyse 5070 Extended (J5005)
This is the budget-friendly, low-power Proxmox box that “just works”. Add an Intel i350-T2, give it 8–16 GB of RAM, and you’ve got a quiet, reliable home router with room for several LXCs and VMs.
Price: $80 - $170

Contains affiliate links. I may earn a commission at no cost to you.

Ebay

Balanced Proxmox Compute Server Build (Recommended)

Specs:

6-8 cores (modern Intel i5/i7)
16-32 GB RAM (32 GB strongly recommended)
500 GB - 1 TB NVMe SSD for fast VM storage
Intel iGPU (for Quick Sync hardware transcoding)
2.5 GbE NIC preferred

Good for:

1080p and 4K transcoding with hardware acceleration
Multiple simultaneous users and media streams
Running several VMs alongside multiple LXCs
Full Arr stack in Docker plus Jellyfin, Home Assistant, and more

Why this is the sweet spot for most Proxmox homelabs:

This is where I landed. My i5-12600K build with 64 GB of RAM and local RAID-Z2 storage for VM protection handles everything I throw at it. Jellyfin transcodes 4K HEVC smoothly with QuickSync. The Arr suite runs in Docker without breaking a sweat. I can snapshot VMs, rebuild entire stacks, test new configs and nobody in the house notices unless I tell them.

Why 32 GB RAM instead of 16 GB?

Here’s the reality: Proxmox itself uses 2 GB. Each Docker VM will want 4-8 GB depending on how many containers you’re running. Jellyfin in an LXC will use 2-4 GB during transcodes. If you’re running ZFS on your local storage (like my RAID-Z2), ZFS will want to use up to 50% of available RAM for its ARC cache.

With 16 GB total, you’ll constantly be swap-constrained and performance will suffer. With 32 GB, you have room to grow and VMs aren’t fighting each other for memory. With 64 GB like I have, you can run just about anything without thinking twice.

CPU considerations:

Modern Intel CPUs (12th gen and newer) are ideal. Intel has an edge here if you care about hardware transcoding because Quick Sync support in Jellyfin and Plex is excellent and dramatically reduces CPU load.

If you’re running lots of containers or VMs, prioritize core count. Each VM you run will want 2-4 dedicated cores for good performance. Try not to over-provision. If you assign more vCPUs to VMs than you have physical cores, Proxmox will time-share and everything slows down.

This tier is perfect if you’re serious about a Proxmox homelab media setup that works reliably.

MINISFORUM MS-01 Mini Workstation
The MS-01 i5 is a tiny mini PC with plenty of cores, multiple NVMe slots, and real homelab networking (dual 10G SFP+ plus 2.5 GbE), which makes it perfect for a Proxmox compute node. It has enough power for Jellyfin, the *arr stack, downloads, and a few VMs or LXCs, without being a space heater.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

High-End Proxmox Compute Server Build

Specs:

8+ cores with high clock speeds (Intel i7/i9)
64-128 GB RAM
Large NVMe (1-2 TB) for VMs and fast workloads
Dedicated GPU for transcoding or compute tasks (optional)
10 GbE NIC if your NAS can keep up

Good for:

Heavy 4K HEVC transcoding workloads
Multiple simultaneous remote transcode streams
Running many VMs and test environments in Proxmox clusters
Extra workloads like game servers, AI/LLM tools, or development environments

When this tier makes sense:

If you’re running significantly more than just media services, if you’re sharing your Proxmox setup with people outside your house, or if you’re experimenting heavily with nested virtualization and want room to grow without limits.

For a simple household Proxmox homelab? This is overkill. But if you have the use cases and the power budget, it’s very nice to have all that headroom.

GMKtec Mini PC Workstation
GMKtec K10 Mini PC is powered by the 13th Gen Intel Core i9-13900HK CPU, with 14 cores and 20 threads. It features a 24MB Smart Cache and a TDP of 45W, delivering exceptional performance for demanding VMs and LXCs.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Recommended Proxmox Layout for Your Compute Node

You don’t need anything complicated to start with Proxmox VE.

Here’s a clean layout that works for most homelab setups:

Infrastructure LXC:

Nginx Proxy Manager or Traefik for reverse proxy
Tailscale, WireGuard, or Cloudflare Tunnel for secure remote access
This container stays up when everything else is being rebuilt

Primary Docker VM:

Ubuntu or Debian VM running Docker and Docker Compose
Your entire media stack: Arr suite, download clients, media automation
Easy to snapshot before major changes

Optional Secondary Docker VM:

Separate VM for experimental or unrelated Docker workloads
Automation tools like n8n, Home Assistant if you want it containerized
Keeps your core media stack isolated from other projects

Individual Service LXCs:

Jellyfin or Plex (LXC for GPU passthrough flexibility)
Audiobookshelf, Immich, or other single-purpose services
Utility containers for scripts, monitoring, or tools you’re testing

💡

Tip: Group related services together in VMs, but don’t cram everything into one container. Keep it modular enough that you can blow up your Docker VM and rebuild it from scratch without taking out your reverse proxy, remote access, or other critical infrastructure. This gives you enough isolation to experiment safely in Proxmox without overcomplicating your setup.

Real World Benefits of a Dedicated Proxmox Compute Server

Once you split compute away from routing and storage, a lot of things stop being crises.

You can reboot Proxmox without taking down the house.

Need to apply Proxmox kernel updates? Need to test a hardware change? Go ahead. Your router stays up. Your NAS stays accessible. Jellyfin goes down for a few minutes and comes back. No one freaks out.

You can rebuild services without fear.

Snapshot your Docker VM before making changes. Try a new Jellyfin major version. Completely rebuild your Arr stack with different Docker Compose configs. If it breaks, roll back the Proxmox snapshot in 30 seconds. If it works, keep it and delete the old snapshot. Your NAS and router don’t care either way.

You can stress test during off hours without affecting critical services.

Want to run Tdarr overnight and transcode your entire 4K library? Go for it. Let the CPU pin at 100% all night. Your router isn’t competing for cycles. Your NAS isn’t getting hammered by transcode temp files.

Your family notices the difference—in a good way.

I used to hear “the internet is down AGAIN” all the time. Now? Things just work. My wife doesn’t think about the server anymore. It’s invisible. That’s exactly the goal.

And since splitting things up, I’ve even been able to share my Jellyfin server with one friend outside my house. Not because my upload speeds got better (they’re still trash) but because the system is stable enough that I trust it to work consistently without me babysitting it.

The Real Risks of Running Everything on One Proxmox Box

If you keep routing, storage, and compute all on one Proxmox server, here’s what you’re signing up for:

Hardware failures cascade completely.

PSU dies like mine did? Motherboard failure? Bad RAM stick? Your entire digital life disappears. Internet, storage, every app, every VM. All gone until you fix or replace hardware.

Software issues spread everywhere.

Kernel panic during a Proxmox upgrade? One VM consuming all available RAM? A filled root partition from runaway Docker logs? Now routing is broken, storage is inaccessible, and all your apps are down.

Maintenance becomes high-risk.

Want to add more RAM? Swap a drive? Update BIOS? Better hope it goes smoothly, because if something goes wrong during maintenance, everything is offline until you recover.

Boot order is a constant gamble.

Will the NAS VM start before other services try to mount shares? Will everything come up in the right sequence? Or will you spend 15 minutes manually restarting services until things work?

No room for safe experimentation.

Want to test a major Proxmox upgrade? Try a different hypervisor kernel? Experiment with GPU passthrough? Better be confident, because if it breaks, you’re taking down the router and storage too.

This isn’t “maybe someday.” I lived it. The PSU failure was my wake-up call, but the constant virtualized NAS mount issues and boot order anxiety were already wearing me down.

How to Start: Your Roadmap to Separating Compute

If you’re running everything on one box right now and this all sounds overwhelming, here’s the actual migration path:

Step 1: Plan and budget for dedicated NAS storage first.

That’s what I moved first, and it was absolutely the right call. Storage was causing me the most pain with the virtualized NAS and mount issues. Getting that onto dedicated hardware immediately made everything more stable.

Figure out your NAS platform (TrueNAS, Unraid, or bare metal Linux with ZFS/MergerFS). Budget for drives, an HBA if you need one, and a box to house it all. You don’t need to buy enterprise-grade equipment, consumer hardware works fine for homelab use.

Step 2: Build the NAS and migrate storage.

Set up your NAS with ZFS or your chosen filesystem. Configure NFS and SMB shares. Test everything thoroughly. Then move your drives over.

Keep your current NAS VM off but available to restore if you need to. Once everything is migrated and verified, you can delete your old VM (I kept mine for a week or so).

Step 3: Move your router when budget allows.

This takes a bit more planning and usually some dedicated hardware budget. But once storage is separate, your next priority is getting routing off the all-in-one. A dedicated pfSense or OPNsense box, or even a good prosumer router if you don’t need advanced firewall features.

Step 4: What’s left is your dedicated compute node.

Once routing and storage are separated, what remains is just your Proxmox compute server. You might want to add more RAM or upgrade storage for better VM performance, but the foundation is already there. You just keep running VMs and containers on dedicated compute hardware.

You don’t have to do this overnight. Each step makes the next one safer. Each separation reduces the blast radius when something goes wrong.

What I Wish I Knew Before Starting

If I could go back and tell myself one thing before beginning this Proxmox homelab journey, it would be this:

Learn how Proxmox handles storage pools and ZFS arrays before you provision anything.

I wasted hours trying to figure out Proxmox storage configuration, mount points, and how Proxmox integrates with external NFS shares because I didn’t understand the basics up front. Thirty minutes of reading the official Proxmox documentation would have saved me multiple evenings of trial and error.

If you’re building local RAID-Z2 or hardware RAID storage in your compute box, understand how Proxmox will use it before you create storage pools and start deploying VMs.

Don’t cheap out on CPU and RAM for your intended workload.

Buy hardware appropriate for the workloads you plan to run. If you know you’ll be transcoding 4K, running multiple Docker stacks, and hosting several VMs, don’t try to save $100 by buying inadequate hardware. You’ll just end up buying better hardware later anyway, and you’ll have wasted time being frustrated by poor performance.

Under-provisioning RAM is especially painful. If you don’t have enough RAM, Proxmox will swap to disk constantly and everything slows to a crawl. Same thing happens if you over-provision CPU cores across too many VMs. Time-sharing kills performance.

Build it right the first time.

Frequently Asked Questions About Proxmox Compute Servers

➤ How much RAM do I need for a Proxmox compute server?

Minimum 8 GB for basic setups, but 16-32 GB is recommended for most homelab use cases. Proxmox itself needs about 2 GB. Each VM wants 2-8 GB depending on workload. If you’re using ZFS for local VM storage, ZFS will consume up to 50% of available RAM for caching. With 32 GB total, you have comfortable headroom for several VMs, LXCs, and ZFS caching without hitting swap.

➤ Can I run Docker directly in Proxmox LXC containers?

Technically yes, but Proxmox and the community advise against it. Running Docker inside LXC containers creates nested containerization which leads to issues with namespaces, cgroups, and storage drivers. The recommended approach is running Docker inside a dedicated VM (Ubuntu or Debian), which gives you full kernel control and avoids compatibility headaches.

➤ What's the difference between LXC and VMs in Proxmox?

LXC containers share the host kernel and are extremely lightweight—they boot in seconds and use minimal overhead. VMs run their own complete operating system with full isolation. Use LXCs for Linux services where you want efficiency (like Nginx Proxy Manager). Use VMs when you need complete isolation, want to run Windows, or need full kernel control for things like Docker.

➤ Do I need a dedicated GPU for Jellyfin transcoding in Proxmox?

Not necessarily. Modern Intel CPUs (8th gen and newer) have excellent Quick Sync support built into the iGPU, which handles hardware transcoding very well. You can pass the iGPU through to a Jellyfin LXC or VM for hardware acceleration. A dedicated GPU only makes sense if you’re transcoding many simultaneous 4K streams or running other GPU workloads like AI inference.

➤ Can I use consumer SSDs for Proxmox VM storage?

Yes, for homelab using consumer NVMe or SSDs is fine. Enterprise drives with Power-Loss Protection are better for production environments, but for home servers where the stakes are lower, good consumer SSDs like Samsung 970/980 EVO or Crucial P3/P5 will serve you well. Just make sure you have backups. Consumer SSDs can fail more often, and when they do, they fail catastrophically.

➤ Should I run my router as a VM in Proxmox?

For homelab experimentation, yes. For production use where your household depends on internet access, no. If your Proxmox host crashes or needs maintenance, a virtualized router means your entire house loses internet. A dedicated router or firewall appliance running pfSense/OPNsense gives you the isolation you need so compute and routing failures don’t cascade.

➤ What's better for Proxmox storage: hardware RAID or ZFS?

For VM storage on the Proxmox compute node, ZFS is generally preferred. ZFS gives you built-in snapshots, compression, and data integrity checking. Hardware RAID can be faster in some cases but lacks ZFS features. Important: ZFS and hardware RAID controllers don’t mix. If you want ZFS, you need direct disk access (HBA mode or no RAID controller). For NAS storage, either approach works depending on your preference.

What’s Next in the Proxmox Homelab Series

You have the router running pfSense or OPNsense. You have the NAS providing reliable storage. Now you have the dedicated Proxmox compute server running your applications.

There’s one more critical piece to add: the Proxmox Backup Server.

Next up is Part 5, where we cover building a Proxmox Backup Server that can actually save you when things go sideways. Because they will. And when your compute node crashes or you accidentally delete the wrong VM, you’ll be very glad you have working backups.

Until then: separate your compute. Your future self will thank you.

Best NAS for Media Servers (2025): Why Dedicated Storage Saves Your Sanity

Mon, 10 Nov 2025 07:30:02 -0600

6 AM. Power came back after an outage. My Proxmox host boots up. The VM that runs my NAS starts… slowly. My Jellyfin container mounts /mnt/media before the NFS share is ready. The mount succeeds but points to an empty directory. My library: “No items found.”

I fixed it in 10 minutes. But I’d already done this dance multiple times every week for eight months and I hated having to manually mount the drives everytime the server boots.

The problem wasn’t the hardware. It wasn’t the software. It was the architecture: I was running my storage as a VM on my compute host. Every reboot was a roll of the dice for timing and mount order.

So, I pulled the HBA and drives out of my Proxmox host and moved them to a dedicated bare metal Debian box running MergerFS with 93TB of drives and SMB and NFS shares.

That was six months ago. I’ve rebooted my compute host 30+ times since then. Zero mount failures, race conditions, or extended debugging sessions late at night. Just my media being served up when I need it.

If your media library matters, give it its own box. I go over how I built mine and why, and why you should dedicate a box to it as well.

If you are trying to figure out the best NAS setup for a home media server, here is the short version: stop running your storage in a VM and give it its own bare metal box that exists only to keep your files safe and available when you want them.

💭 TL;DR

Running storage in a VM or LXC is like playing with fire. You think you're being efficient. You're actually creating race conditions, mount failures, and late night debugging sessions when you could be enjoying your media with friends and/or family. Separate storage to bare metal. It boots quickly, serves reliably, and stops holding your media hostage.

Quick picks: best NAS options for media servers (2025)

If you came here looking for the “just tell me what home NAS to buy” version, here is the short list.

1. DIY bare metal NAS for homelab nerds

You want control, flexibility, and better hardware for the money.

OS: Debian or another solid Linux base, with MergerFS for pooling and NFS or SMB exports
Use case: Jellyfin or Plex library, backups, maybe a bit of general file storage
Why it is the best fit:
- You are not locked into a vendor GUI
- You can pick quiet, low power parts instead of whatever the NAS vendor felt like shipping
- Easy to grow storage with bigger drives later rather than buying a whole new box

This is the setup I use and for me, it is the best NAS for a home media server. The Proxmox host talks to it over the network, and the NAS does one job and does it well.

2. Synology NAS for people who want easy mode

You want something that just works, and you do not want to learn MergerFS.

Example: 4 to 8 bay Synology DiskStation for media and backup
Use case: You want a simple web UI, snapshots, built in apps, and clean integration with Windows and macOS
Why it is a good fit:
- Synology handles RAID, drive health alerts, and shares for you
- Great if you want to spend more money on hardware and less time learning Linux
- Perfect for “I run Jellyfin on another box, this thing just holds the files”

You give up some flexibility and pay a premium compared to DIY, but you get a nice, polished experience.

Synology 4-Bay DiskStation DS925+ (Diskless)
Is a 4-bay NAS running DSM with an easy setup, dual 2.5 GbE, M.2 NVMe slots for cache, ECC-capable RAM up to 32 GB, expansion to 9 bays, and roughly 500+ MB/s for multi-user streaming. Pick it over a DIY build if you want simple and reliable, since DSM gives you polished wizards, built-in backup and media apps, and hardware that just works.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

3. Used server or small business box if you like deals

You are comfortable with louder gear and you want lots of bays for cheap.

Examples: Used Dell, HP, or Lenovo small servers or business desktops with extra SATA added
Use case: Big media libraries, lots of drives, budget conscious builds
Why it can make sense:
- Older enterprise gear is cheap and still very capable
- Easy to stuff with drives and treat it as a dedicated storage tank
- Run Debian or your favorite NAS OS and treat it like the DIY option above

You just have to watch power draw and noise. Great for a basement rack, not great for a studio apartment.

No matter which path you pick, the rule is the same:
Your media server should talk to a dedicated NAS box over the network, not share a boot drive with Proxmox and six LXCs that all panic if a mount is late.

Storage In VMs: Just Because You “CAN”, Doesn’t Mean You Should

Let’s get this out of the way: running your NAS in a Proxmox VM is a bad idea. Running it in an LXC is an even worse idea.

Reddit will tell you: “It’s more efficient!” or “One box does everything, and it is amazing!”

I’m here to tell you they are wrong and what you’ve actually built is a house of cards where storage, the foundation of your entire media stack depends on:

A hypervisor booting correctly
VM startup order being predictable
Mounts being added and mounted to the Proxmox host correctly (My biggest issue)
Network initialization happening before mount attempts
No Proxmox updates changing any of the above

You’re not being efficient. You’re optimizing for a $200 hardware savings while trading it for hours of maintenance, failed mounts, and streams that don’t work when you want them to.

I know because I did this for six months. I spent roughly 3 hours every week debugging mount failures, tweaking systemd scripts, adjusting delays, and reading Proxmox forums at midnight. That’s 78 hours over six months (Almost two full work weeks fighting an architecture that was fundamentally wrong).

The worst part? Each failure was only a 10-15 minute fix. But they happened constantly. Reboot the host? Roll the dice. Proxmox update? Hope your mounts still work. Add a new container? Maybe it boots before the NAS is ready, maybe it doesn’t.

💡

Tip: The root issue is that your media server runs in a VM on the same Proxmox host that’s trying to mount its shares. During boot, Proxmox processes /etc/fstab and can’t mount the shares because the VM hasn’t even started. Mounting shares later isn’t as straightforward as it sounds. Any workarounds you apply afterward just treat the symptoms without addressing the root cause. I exhausted every solution I could find across Google, Reddit, and the Proxmox forums. Some provided marginal improvements, but none fully resolved the problem.

The Real Cost

Let me break down what this “efficient” setup actually cost me:

78+ hours of debugging over six months
Multiple service outages where Jellyfin showed “Library Empty” because mounts succeeded but pointed to empty directories
Constant user complaints about streams dying or libraries disappearing
Mental overhead of “will this reboot break everything?”

What did I gain by running storage in a VM? Absolutely nothing. I saved a small amount of money on power, not enough to make up for my time. That’s it.

The Time My Storage Failed Me (And Why I Finally Fixed It)

Here is what finally convinced me to do this right.

The Reboot Lottery

Power outage, kernel update, Proxmox update, stuck containers can all cause the need to reboot the Proxmox host. When the host is rebooted… Proxmox comes back up. NAS VM starts… but something’s off. The VM boots, the drives mount inside the VM, but Proxmox’s automount fails to see the NFS share. Jellyfin LXC mounts /mnt/media to an empty local directory. Users see “Library Empty.”

I SSH in, manually remount, restart containers. Fixed in 10 minutes.

But this wasn’t a one-time thing. This happened a few times a week with different variations:

Sometimes the VM booted too slowly
Sometimes Proxmox tried to mount before the NFS server was actually serving
Sometimes it worked perfectly
Sometimes my custom delay scripts helped, sometimes they didn’t

I tried:

Systemd mount delays (worked sometimes)
Custom scripts that pinged the NAS before mounting (race conditions remained)
Automount with longer timeouts (helped but didn’t fix it)
Tweaking VM boot order and priority (marginal improvement)

Nothing worked reliably. Because the problem wasn’t the configuration, it was the architecture.

That’s when I realized: this is insane. I’m spending hours maintaining mount orchestration on a system that should “just work.” The storage shouldn’t be a VM. It shouldn’t depend on a hypervisor. It should boot first and serve files. Period.

The VM Race Condition From Hell (What’s Actually Happening)

Here’s what was happening in my Proxmox host every reboot:

Proxmox boots
VMs start launching - based on boot order/priority settings
My NAS VM begins booting - this takes time: OS boot, network init, NFS server start
LXC containers start
Containers try to mount /mnt/media via NFS from the Proxmox host (Bind mounts)
Three possible outcomes:
- ✅ NAS is ready → mount succeeds → everything works
- ❌ NAS isn’t ready → mount fails → services break
- ⚠️ Mount succeeds but NFS isn’t serving yet → mount points to empty directory → “Library Empty”

That third one is the nastiest because everything LOOKS like it worked. The mount command succeeded. The directory exists. But there’s no data because the NFS server inside the VM hasn’t finished starting yet.

Why This Is Fundamentally Broken

The hypervisor doesn’t know or care about your application dependencies. Proxmox sees:

NAS VM (priority: normal)
App containers (priority: normal)
Network is up
Start everything

It doesn’t understand that your Jellyfin container NEEDS the NAS to be fully operational before it can function. You can try to encode this with systemd dependencies, boot delays, ping scripts, and health checks but, you’re still fighting the architecture.

The solution isn’t better orchestration. It’s removing the orchestration entirely.

LXCs Are Even Worse (Seriously, Don’t)

I never tried running my NAS in an LXC. But I’ve seen people attempt it on Reddit and Proxmox forums, and it’s a nightmare every single time.

Why people try it:

“LXCs are lighter than VMs!”
“I don’t need full VM overhead for a file server!”
“I can bind-mount drives directly!”

Why it fails spectacularly:

No Real Hardware Access

LXCs share the host kernel. You can pass through devices, but you’re not getting true hardware access like bare metal. Running ZFS in an LXC? You’re trusting the container layer to not screw up your file systems. Running SMART monitoring? Good luck with device passthrough being consistent.

The Same Mount Race Conditions, But Worse

The LXC has to start, the storage daemon has to initialize, the NFS/SMB server has to start, and THEN other containers can mount. You’ve just recreated the VM problem with less isolation and more ways for it to break.

What Actually Happens

Search r/Proxmox for “LXC NFS” or “LXC storage” and you’ll find a number of posts like this:

“My LXC can’t see the drives after reboot”
“Permissions are broken after Proxmox update”
“SMART data isn’t available in the container”

The pattern is always the same: someone tries to be clever, runs storage in an LXC to “save resources,” and ends up with a fragile, unreliable mess.

Don’t do it.

Why Dedicated Bare Metal Is The Only Sane Option

When I moved my storage to bare metal Debian, here’s what changed:

Predictable Boot Order (Finally)

It boots, drives spin up, XFS filesystems mount, MergerFS pools them, NFS server starts. All of this happens BEFORE my Proxmox host even starts booting.

By the time Proxmox comes online and containers try to mount /mnt/media, the NAS has already been serving files and waiting. Zero race conditions, timing dependencies, or failed mounts.

No More Orchestration Hell

I deleted:

Custom systemd mount units with delays
Ping-before-mount scripts
VM boot order priorities
Health check containers
All the “clever” solutions I built to work around a broken architecture

The NAS boots. It serves files. Proxmox mounts them. That’s it. No orchestration needed.

Fault Isolation

When I need to rebuild my Proxmox host or test new versions, my storage stays online. It keeps serving files to the containers that are still running. When I need to add drives or run maintenance on the NAS, I take it offline briefly but, my compute layer isn’t impacted. I do however, reboot the compute node after NAS maintenance just to ensure everything is working.

Before, everything was tangled together. Proxmox down = storage down. Storage issues = compute issues. It was all one fragile system. I made it even worse because at the time my router was also in a VM on the same Proxmox host. So, every reboot also took down my internet too. Don’t be like me.

Zero Maintenance

In eight months since the migration:

Proxmox reboots: 30+
NAS mount failures: 0
Hours spent debugging storage: 0
Streams interrupted by storage issues: 0

The NAS just works. I literally forget it exists until I need to add more drives.

What I Gave Up

Nothing. Absolutely nothing.

I added one more box to my rack (an old desktop PC I already owned). That’s it. No performance penalty. No feature loss. No additional complexity. Actually, LESS complexity because I removed all the mount orchestration.

Adding a low power CPU to run the NAS had a minimal impact to the power bill (About 40-60W).

Seagate BarraCuda Internal Hard Drive 8TB
Right now one of the best price per GB you can find. Also has a 2-year warranty.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

“But My NAS VM Works Fine” (For Now)

If you’re reading this thinking “my NAS VM is stable, this doesn’t apply to me,” let me ask:

Have you rebooted your Proxmox host this month? Did everything come back up cleanly?
Have you updated Proxmox recently? Did your mounts still work after?
Do you have multiple containers depending on storage? Do they all mount reliably?
Have you tested what happens during a power failure and cold boot?
Can you reboot your compute layer without taking storage offline?

If you answered “yes” to all of these, congratulations! You’ve either gotten extremely lucky or you’ve spent dozens of hours building complex orchestration to paper over the architectural problems.

But here’s the thing: it works until it doesn’t.

You’re not running a reliable system. You’re running a system that hasn’t failed YET. And when it does fail during a family movie night, you’ll wish you’d built it right from the start.

The Real Question

What are you actually gaining by running storage in a VM?

Saving one hardware box? (An old desktop PC costs $50-200 used)
“Efficiency”? (You’re trading hardware efficiency for operational chaos)
Easier management? (Is debugging mount failures “easier” than running a separate box you never touch?)

Be honest: you’re not optimizing for reliability or simplicity. You’re optimizing for… what, exactly?

The Architecture Comparison

Let me show you what I ran vs what I run now.

WRONG: What I Built First

Proxmox Host (one physical box)
├── NAS VM (OMV)
│   ├── Boots at ??? (depends on VM priority)
│   ├── Needs: OS boot → network init → storage mount → NFS/SMB start
│   └── Serves: NFS/SMB shares back to Proxmox host
│
├── Jellyfin LXC
│   ├── Boots at ??? (fast, because LXC)
│   ├── Tries to mount: /mnt/media (from Proxmox host bind mount)
│   └── Result: ⚠️ Maybe works, maybe empty directory, maybe fails
│
├── Sonarr LXC
│   ├── Boots at ??? 
│   ├── Tries to mount: /mnt/media (from Proxmox host bind mount)
│   └── Result: ⚠️ Maybe works, maybe empty directory, maybe fails

Problems:

Boot order is non-deterministic (depends on VM/LXC startup speed)
NAS VM has multiple initialization steps before it’s ready to serve
Containers mount before checking if NFS is actually serving
Reboots are a lottery
Proxmox updates can change everything (rare, but still a thing)

RIGHT: What I Run Now

NAS Box (dedicated bare metal Debian)
├── Hardware: Intel G3220, 16GB RAM, LSI HBA, 10GbE NIC
├── Software: Debian Trixie, XFS per drive, MergerFS pooling
├── Boot: Second. After the dedicated Router
└── Serves: NFS shares to network (always available)

                    ↓ (2.5GbE Network)

Proxmox Host (separate physical box)
├── Boot: Thrid (after NAS is already serving)
├── Mounts: /mnt/media via NFS from NAS box (always succeeds)
│
├── Jellyfin LXC → bind mounts /mnt/media → ✅ always works
└── Sonarr LXC → bind mounts /mnt/media → ✅ always works

Benefits:

Boot order is deterministic (NAS second, always)
No dependencies between storage and compute layers
Reboots are predictable
Proxmox updates don’t affect storage
Fault isolation (one system failing doesn’t take down the other)

Network Details

Connected via SODOLA 8-Port 2.5Gb managed switch:

NAS: 10GbE NIC (downlinks at 2.5Gb to switch)
Proxmox: 2.5GbE NIC
Throughput: ~280 MB/s sustained (vs ~110 MB/s on 1GbE)
Multiple simultaneous 4K streams + NZB downloads + backups = no congestion

How I Migrated

Here’s exactly how I moved from “NAS VM on Proxmox” to “NAS on bare metal.”

What I Started With

Proxmox host with LSI HBA in IT mode
8x drives passed through to OMV VM
Containers mounting via NFS from Proxmox host (bind mounts)
Constant race condition issues

What I Did

1. Built the new NAS box first

Old desktop: Intel G3220, Gigabyte GA-Z87X-D3H motherboard, 16GB DDR3
Installed Debian Trixie
Added 10GbE NIC (Intel X520-DA1, $30 used on eBay)
Configured it on the network with a static IP

2. Tested NFS serving (before moving drives)

Set up NFS exports on the new Debian box
Verified Proxmox could mount from it
Made sure permissions and paths matched my existing setup

3. Scheduled downtime (Friday night)

Shut down all containers/VMs on Proxmox
Shut down the NAS VM
Shut down the Proxmox host

4. Moved the hardware

Pulled the LSI HBA from Proxmox host
Moved all 8 drives
Installed HBA and drives in the new NAS box
Connected power, network

5. Brought up storage

Booted the NAS box
Drives appeared as /dev/sda through /dev/sdh
Mounted each drive: mount /dev/sdX /mnt/diskX
Configured MergerFS to pool them: /mnt/disk* /mnt/media
Set up NFS exports pointing to /mnt/media
Updated /etc/fstab so everything mounts on boot

6. Brought Proxmox back online

Booted Proxmox
Updated /etc/fstab to point to the new NAS IP instead of VM mount
Verified NFS mounts succeeded
Started containers one by one
Checked Jellyfin library, verified all media was accessible

Total downtime: ~2 hours (most of it was physical drive transplant and cable management)

LSI 9300-8i HBA Controller
LSI SAS3008 9300-8i HBA Controller is a high-performance disk controller suitable for media server data storage needs. With a transfer rate of up to 12Gbps, this unit provides reliable and fast data storage solutions. Price: $30 - $40

Ebay

Contains affiliate links. I may earn a commission at no cost to you.

What I Learned

Test the new setup before you commit. I verified NFS serving worked before I moved drives.
Expect the first boot to take longer. XFS file system checks took a few minutes per drive.
Plan for worst case. I kept the Proxmox host ready to take the HBA back if something went catastrophically wrong (it didn’t).

What Your NAS Actually Needs To Do

Redundancy

At minimum: ability to survive drive failure without data loss.

I’ll be honest: I ran without parity for two years. Why? Because 95% of my data was movies and TV shows I could redownload. Then I started adding family videos and photos - stuff I can’t get back. That’s when I decided to add SnapRAID for parity (I’m adding this next month if HDD prices come down).

Use any scheme you’re comfortable with: parity, mirrors, or just redundancy for critical bits. Just know what you’re protecting and what you’re willing to lose.

Protocols That Work

NFS for your virtualization or Linux services
SMB/CIFS for Windows/macOS clients
SFTP for remote access or backup jobs

Your NAS must seamlessly integrate with your compute and network layers. My setup serves NFS to Proxmox hosts and SMB to Windows machines for manual file management. It just works.

Smart Mounting Strategy

This is where most people screw up:

Stick to consistent paths: /mnt/media/movies, /mnt/media/shows not /media1, /media2, /random-drive-name
Enable automount so on reboot everything comes up in order (systemd handles this well on Debian)
Keep temp, transcode, and download directories separate from your main pool to avoid runaway writes destroying your media drives
Use SMART monitoring and actually test restore workflows. You’ll thank yourself later

I run smartctl -a /dev/sdX monthly on each drive. One drive showed reallocated sectors climbing. Replaced it before it died.

Software Choices—What I’ve Used and What Actually Works

Here’s what I’ve tested and what I actually run.

NAS OS	Strengths	Weaknesses	My Take
TrueNAS	Strong ZFS support, snapshot capabilities, enterprise features	Needs more RAM/hardware, steeper learning curve, overkill for media	Great if you need ZFS. I don’t.
Unraid	Flexible drives, less hardware-intensive, nice GUI	License cost ($59-$129), lower performance on some tasks	Popular for good reason, but I’m cheap and wanted full control
OpenMediaVault	Lightweight, easy to set up, web GUI	May lack advanced features, felt restrictive to me	Where I started in a VM, outgrew it fast
Debian + MergerFS	Lightweight, total control, exactly what you need	No GUI (you use SSH and config files), learning curve	This is what I run. Took a weekend to learn, now it’s bulletproof.

I originally tried OpenMediaVault in a VM. It worked, but every time I wanted to do something slightly custom, I fought with the GUI or the update system. Moved to straight Debian with MergerFS and NFS/SMB servers. No GUI, just config files and systemd. Steeper learning curve? Yes. But now I understand exactly how everything works and nothing is hidden behind abstraction layers. When something breaks (rare), I know exactly where to look.

💡

Tip: Whatever you choose, run it on bare metal. Avoid running it in a VM or LXC. You will thank yourself later.

ZFS vs MergerFS - What’s Best For a Media Server?

Let’s cut the fluff: you don’t always need ZFS for a media-server-only setup.

ZFS: Enterprise Grade Redundancy

RAID-Z/RAID-Z2, checksums, snapshots, send/receive. Requires serious RAM (1GB per TB is the common recommendation) and prefers ECC memory.

I almost started with ZFS because that’s what the internet said to use. Researched ECC RAM, planned my vdev layout, read the entire FreeBSD handbook section on ZFS. Felt very enterprise. It also had an enterprise price tag.

Then I realized: if a drive dies, I can just re-download everything in a weekend. Why am I treating Bob’s Burgers S04 like a production database?

When ZFS is worth it:

You’re running VMs, databases, things that can’t be redownloaded
You can afford to buy 6 or more identical drives in one purchase (I couldn’t justify this).
You have irreplaceable data (family photos, business files)
You want snapshots and send/receive for backups

For me? 80% of my data was re-downloadable movies and shows. ZFS was overkill. I make backups of the irreplaceable files and keep them in three locations (Local, External HDD, and Cloud).

MergerFS: Flexible, Media Friendly

MergerFS pools drives into /mnt/media regardless of size.

Why it works for media:

Add drives without rebuilding (I started with 3 drives, now at 8)
Any size, any speed, different brands, no “matched set” needed
If a drive dies, you lose only what was on that drive, not the whole pool
Reads are fast, writes go to whichever drive has space (configurable policies)
Works on bare metal Debian with zero virtualization overhead

The catch: No real-time parity. If a drive dies, that data is gone unless you have backups or add parity separately (see SnapRAID below).

Feature	ZFS	MergerFS
Real-time parity	✅ Yes	❌ Not built-in
Flexible drive sizes	❌ No (same-size vdevs)	✅ Yes
File-level recovery	❌ Generally no	✅ Straightforward
Hardware overhead	High (RAM, ECC preferred)	Low (runs on anything)
VM-friendly	⚠️ Possible but problematic	✅ But run it on bare metal anyway
Ideal for media	Overkill	Perfect fit

Verdict:

If your NAS is mostly media you can re-download - go MergerFS
If your NAS hosts business-critical or irreplaceable data - go ZFS

MergerFS + SnapRAID: The Best of Both Worlds

MergerFS gives me flexible pooling. But what about redundancy?

Enter SnapRAID: parity for files that don’t change often (perfect for media).

How it works:

I dedicate 1 drive as a parity drive (the largest drive)
SnapRAID calculates parity across the pool on-demand (I’ll run it nightly via cron)
If a drive dies, I can rebuild from parity
Unlike RAID, parity is calculated when YOU tell it to, not in real-time
If TWO drives die before I sync parity… yeah, I lose some files. But that’s the trade-off for flexibility

I’m adding this to my setup next month because I finally have data I can’t easily redownload (family videos, photos). For movies and TV? I didn’t bother for two years. The cost/benefit wasn’t there.

Why this works on bare metal: SnapRAID needs direct drive access for parity calculation. Running it in a VM means the hypervisor is between your file system and the drives - adding latency, complexity, and potential corruption. On bare metal? It just works.

Hardware Recommendations

It’s gear time. Because yes, you can buy this now. And yes, you can target budget or beast mode depending on how deep your wallet is.

Tier	Specs	Use Case	What I’d Buy Today
Budget	2-4 bays, low-power CPU, basic RAM	Cold storage, archives	Old desktop with 2-4 SATA ports. Intel Pentium or i3, 8GB RAM. Purpose: hold files, serve NFS. Cost: $50-100 used.
Balanced	4-8 bays, decent CPU, 16GB RAM	Streaming + moderate load	This is basically my setup. Rosewill Helium NAS case ($90), Intel G3220 or newer i3 ($50 used), 16GB RAM, LSI HBA in IT mode ($50 used), 8x drives. Quiet, expandable, fits under a desk. Total: ~$300 + drives.
Beast	8+ bays, modern i5/i7, 10GbE NICs	Multi-user, 4K/8K, heavy lift	Rosewill Helium NAS or bigger case, i5-12400 or better, 32GB RAM, 10GbE NIC, quality PSU. Overkill for most, perfect if you’re streaming to 5+ users simultaneously. Cost: $600-800 + drives.
Simple	Synology 4-8 bay NAS	Just want it to work, don’t want to DIY	DS920+, DS1522+, or whatever’s current. You pay more, but it works out of the box. No shame in this. Cost: $400-800 + drives.

Rosewill Helium NAS ATX Mid-Tower Case
The Rosewill Helium NAS ATX mid-tower is a budget-friendly case built with storage in mind. It fits a standard ATX motherboard, has space for 10 3.5" hard drives as well as room for HBAs or SATA expanders. For a DIY NAS this case lots of room for growth without paying server-chassis prices.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Critical hardware note: Whatever you buy, it needs:

Direct SATA connections (no USB)
Enough RAM for your OS + file system cache (8GB minimum, 16GB better)
Quality power supply (drives are expensive, don’t cheap out on PSU)
Network connectivity that matches your needs (2.5GbE or 10GbE if you have heavy traffic)

Network: The Bottleneck Nobody Talks About

1GbE = 125 MB/s theoretical, ~110 MB/s real-world.

That’s fine for one 4K stream (40 Mbps) or even 20 simultaneous 1080p streams. Sounds like plenty, right?

Except you’re also:

Downloading a new TV Series
Running backups to your PBS box (Part 5 of this series)
Scanning new media into Jellyfin
Maybe transcoding if someone’s on a slow client

Now you’re maxing out that 1GbE link. Streams buffer. Your spouse asks if the internet is broken. You check your bandwidth graphs and realize: it’s not the ISP, it’s your internal network.

What I Did

Added a $30 Intel X520-DA1 10GbE NIC to my NAS box (used on eBay) and a $60 SODOLA 8-Port 2.5Gb managed switch.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Result:

NAS has 10GbE NIC (downlinks at 2.5Gb to the switch)
Proxmox has 2.5GbE NIC
Sustained throughput: ~280 MB/s (vs ~110 MB/s on 1GbE)
Multiple 4K streams + torrents + backups = no congestion

Streams never buffer. Backups run 2.5x faster. Torrents don’t fight with Jellyfin for bandwidth.

If you’re building from scratch: Just buy a motherboard with 2.5GbE built in. The Intel i226-V chipset is solid and adds $0 to motherboard cost these days. Many boards in the $100-150 range include it standard.

When to consider 10GbE:

5+ simultaneous users streaming 4K
Heavy backup workloads (multiple TB per day)
You transcode on a separate box and move large files constantly
You’re a data hoarder moving TBs between systems regularly

For most home setups? 2.5GbE is the sweet spot. Cheap, no special cables needed (works on Cat5e), massive improvement over 1GbE.

Intel X520-DA1 10GbE NIC
This 10Gtek network card is designed for use with Intel X520-DA1 routers and features a maximum data rate of 10 Gbps. With one SFP+ port and PCIe x8 interface, this card provides high-speed connectivity for your network. Price: $30 - $40

Ebay

Contains affiliate links. I may earn a commission at no cost to you.

My network setup:

NAS: Intel X520-DA1 10GbE NIC with DAC cable to switch
Switch: SODOLA 8-Port 2.5Gb managed switch
Proxmox: Onboard 2.5GbE
Clients: Mix of 1GbE and 2.5GbE

Total cost: ~$90 for the upgrade. Best $90 I’ve spent on this build.

Storage Layouts That Make Sense

Turning hardware into a predictable, reliable stack.

Directory Structure

Use clear, consistent paths:

/mnt/media/
├── movies/
├── shows/
├── music/
└── books/

Not /media1/stuff, /driveB/movies, /bob-likes-anime/. Keep it simple. Keep it consistent.

Why this matters: when you’re debugging at 3 AM (you won’t be, because bare metal doesn’t have race conditions, but hypothetically), you want obvious paths. When you’re setting up a new container, you want to know exactly where /mnt/media/movies lives.

Separate Temp and Archive

This is critical and most people get it wrong.

Transcode, temp, and download directories: Put these on SSDs or a separate spindle pool that you don’t care about. You do NOT want qBittorrent hammering your archive drives with random writes while incomplete downloads get moved around.
Finished media: Goes to the archive pool (the big slow drives via MergerFS). This is read-mostly workload. Movies get added once, read many times, rarely deleted.

My setup:

NAS Box:
├── 500GB SSD: Debian 13, NFS, SMB, MergerFS and Snapraid (that's it don't over complicate it).
└── 93TB MergerFS pool (Mix of 3, 6, 14, and 24TB Drives): Static Storage only.

Any Docker containers, downloads, or Jellyfin transcodes are on the compute node with fast redundant data storage.

SABnzbd downloads to compute node’s fast storage. When a download completes, Sonarr/Radarr move it to /mnt/media/tv or /mnt/media/movies on the MergerFS pool. The compute node’s storage absorbs all the random write punishment. The spinning drives just handle sequential writes when media is added and sequential reads when streaming.

Mount Strategy

Mount read-only where possible for older content (reduces risk of accidental deletion). My Jellyfin server can only read the media files on the NAS.
Set up rsync or backups to your backup box (Part 5 of this series) so you’re not relying on storage redundancy for your important files.
Run SMART monitoring: smartctl -a /dev/sdX monthly, check for reallocated sectors, pending sectors, or UDMA CRC errors
Schedule pool scrubs if using SnapRAID (I’ll run snapraid sync nightly, snapraid scrub weekly once I set it up)
Test restores: Seriously. Shut down, pull a drive, boot, verify you know how to identify which drive failed and how MergerFS handles it. Learn how recovery works BEFORE you need it at 3 AM.

When your storage setup is done well - you forget it’s there. When it fails - you will be ready.

My Actual MergerFS Config

For reference, here’s what I run on bare metal Debian:

Drive mounts in /etc/fstab:

/dev/disk/by-id/wwn-0x5000c500b531bbcc-part1    /mnt/Pool/Disk1        xfs     defaults        0       0
/dev/disk/by-id/wwn-0x5000c500e4505355-part1    /mnt/Pool/Disk2        xfs     defaults        0       0
/dev/disk/by-id/wwn-0x5000c500e50b9986-part1    /mnt/Pool/Disk3        xfs     defaults        0       0
/dev/disk/by-id/wwn-0x5000c500e82476d9-part1    /mnt/Pool/Disk4        xfs     defaults        0       0
/dev/disk/by-id/wwn-0x5000cca295caac7a-part1    /mnt/Pool/Disk5        xfs     defaults        0       0
/dev/disk/by-id/wwn-0x5000cca2a1dcb6af-part1    /mnt/Pool/Disk6        xfs     defaults        0       0
/dev/disk/by-id/wwn-0x50014ee20d104997-part1    /mnt/Pool/Disk7        xfs     defaults        0       0

MergerFS pool:

/mnt/Pool/Disk*        /media/Storage  fuse.mergerfs   direct_io,defaults,allow_other,dropcacheonclose=true,inodecalc=path-hash,category.create=mfs,minfreespace=50G,fsname=storage      0       0

NFS exports in /etc/exports:

/media/Storage/ 172.27.0.0/24(all_squash,anongid=1001,anonuid=1000,insecure,rw,subtree_check,fsid=0)

That’s it. No GUI. No abstraction layers. Just Linux doing what Linux does best: serving files reliably.

Common Mistakes (That I Made So You Don’t Have To)

Running storage as a VM on your compute host:
- Race conditions, mount order chaos, reboots that break everything. This was my life for six months. Don’t do it.
Running storage in an LXC:
- Even worse than a VM. Filesystem passthrough nightmares, permission issues, SMART monitoring doesn’t work right. Just don’t.
Using USB externals without redundancy:
- One disconnect = data loss. If the data matters, it needs to be on real SATA connected to a real motherboard.
Mixing different drive sizes in a ZFS pool:
- Kills performance, wastes capacity. ZFS wants matched vdevs. (MergerFS doesn’t care. One of many reasons I prefer it for media.)
Ignoring ECC RAM when building ZFS:
- Silent bit flips can corrupt your “perfect” checksummed pool. If you go ZFS, get ECC. Or just use MergerFS and skip the RAM requirements.
Never testing restores:
- You don’t have a backup until you’ve tested the restore. Same goes for RAID/parity rebuilds. Pull a drive while the system is OFF (don’t hot-swap unless you know what you’re doing) and verify you can identify and recover from the failure.
Trusting your setup without monitoring:
- Run SMART checks monthly. Watch your logs. Drives give warnings before they die—if you’re paying attention.
Thinking “I’ll add redundancy later”:
- Later never comes. If the data matters NOW, protect it NOW. I’m guilty of this (took me 2 years to decide on SnapRAID), but at least I knew what I was risking.

The Only Time Storage In A VM Makes Sense

Let me be fair: is there ANY scenario where running storage in a VM is acceptable?

Maybe - MAYBE - if:

You’re running TrueNAS as a VM with direct PCI passthrough of an HBA
It’s THE ONLY VM on a dedicated Proxmox host (no competing VMs/LXCs)
You’ve pinned the VM to specific CPU cores, so it always has resources
You’ve configured Proxmox to boot the storage VM first with significant delays before anything else starts
You’ve tested cold boot scenarios extensively

But even then: what are you gaining? You’ve added a hypervisor layer between your storage and your compute. You’ve introduced complexity, potential for race conditions, and dependency on Proxmox functioning correctly.

The question isn’t “can you make it work?” The question is “why bother?”

My answer: There is no good reason. The “one box does everything” dream is just that a dream. You’re trading $50-100 of old hardware for hours of maintenance and fragility you don’t need.

If you want to run TrueNAS or OpenMediaVault, run them on bare metal. If you want Debian + MergerFS, run it on bare metal. Give storage its own box and let it do its job without interference.

What You Should Do Right Now

If you’re currently running storage in a VM or LXC:

Option 1: Build A New NAS Box (Recommended)

Get cheap hardware: Old desktop, $50-100 on Craigslist/eBay, needs 4+ SATA ports
Install Debian (or your preferred NAS OS—on bare metal)
Set up NFS/SMB shares while your VM is still running
Copy data from VM to new box (rsync, verify with diff/checksums)
Test thoroughly (mount from Proxmox, verify Jellyfin sees everything)
Cut over: Update Proxmox mounts to point to new NAS IP
Shut down the VM forever

Downtime: ~2 hours for final cutover. Peace of mind: priceless.

Option 2: Repurpose Your Proxmox Host

If you only have one box:

Back up your containers/VMs (you should be doing this anyway)
Wipe Proxmox
Install Debian as NAS on the bare metal
Buy a second box for Proxmox (can be cheaper since it’s just compute)
Rebuild your compute stack on the new Proxmox host
Mount from the NAS

Yes, this requires buying hardware. But you’re separating concerns the right way. Storage on one box, compute on another. This is how it should be.

Option 3: Stay In VM Hell

Continue debugging mount failures, systemd dependencies, and race conditions. Spend 3 hours every few weeks troubleshooting why reboots break everything. Wonder why your spouse hates your “hobby.”

I don’t recommend this option.

Final Thoughts

I run 93TB of media on bare metal Debian with MergerFS. Eight drives of different sizes, XFS file systems, pooled with MergerFS. No parity yet (adding SnapRAID next month). 2.5GbE network via 10GbE NIC to SODOLA switch. NFS shares to Proxmox. SMB shares to Windows clients.

Hardware:

Intel G3220 (old, low-power, sufficient)
Gigabyte GA-Z87X-D3H motherboard
16GB DDR3 RAM
LSI HBA in IT mode (direct drive access, no RAID controller nonsense)
Intel X520-DA1 10GbE NIC
Rosewill Helium NAS case (holds 10 drives, quiet, fits under a desk)

The box boots in 90 seconds. Serves files to two Proxmox hosts and a dozen containers. I haven’t touched it in months except to check SMART data.

Total cost: ~$2,000 over three years (includes drives, case, and network gear).

I haven’t had a mount failure in six months. I reboot my compute nodes whenever I want. Proxmox updates don’t scare me. Power outages resolve themselves. My storage just… works.

If your media library matters, and if you’re reading this, it does - give it its own box. Separate storage from compute. Pick an OS (I chose Debian + MergerFS, you might prefer OpenMediaVault or Unraid). Learn it. Build it right. Run it on bare metal.

You’ll thank yourself at 3 AM when the power comes back and everything just comes back online in the right order. Or better yet - you’ll sleep through it because there’s nothing to debug.

Stop running storage in VMs. Stop fighting race conditions. Stop spending weekends debugging mount failures.

Build it right. Run it on bare metal. Forget it exists.

Best Homelab Router Setup (2025): Stop Letting Your ISP Kill Your Stack

Thu, 30 Oct 2025 07:25:02 -0600

Consumer routers try to be everything: modem, router, switch, Wi-Fi, DNS, sometimes even a media server. When any piece fails, everything fails. The Wi-Fi radios cook themselves. Firmware updates brick the UI. NAT tables fill and kill your connections. Meanwhile, vulnerabilities sit unpatched for months.

I learned this the hard way..

My journey to a proper router started with a failed consumer device.
Then evolved into “I can just add a dual port NIC to the server and run my router in a VM”.
It started brilliantly but, it quickly turned into a twice-weekly nightmare.

💭 TL;DR

Your ISP router can't do VLANs, logging, or real security. A proper router box ($150-$800) running OPNsense gives you network segmentation, intrusion detection, full traffic visibility, and actual control. I've run this setup for 8+ years across multiple hardware generations. Setup time: one weekend to get working, 2-3 weekends to get truly secure.

The All-in-One Trap

I was running my entire homelab on a single Proxmox server: NAS, media server, download clients, home automation, everything. And because I was already virtualizing everything else, why not the router too?

It seemed elegant. One box, total control, efficient resource usage.

Then reality hit.

“Why is the internet out again?”

It was a Tuesday night. My wife was trying to stream something. I was in my office, staring at an LXC container that refused to stop, forcing me to reboot the entire Proxmox host. Again.

“Sorry, it should be back on in a few minutes. I had to reboot the server again.”

This happened once or twice a week. Sometimes it was NFS issues that wouldn’t resolve without a full reboot. Sometimes hardware failures. Sometimes it was just me testing something and broke it in unexpected ways. Each time, the entire house lost internet.

Five minutes of downtime doesn’t sound like much. But when it happens regularly, it stops being “a brief inconvenience” and starts being “why do we have internet problems all the time?”

The breaking point came when a power supply died at 9 AM on a Friday. The internet was down for four hours while I left work to drive to Best Buy for a replacement part. Not ideal when your wife works from home and needs reliable connectivity.

Before That: The Consumer Router Carousel

But let’s back up. Before I virtualized my router, I was doing what everyone does: buying consumer all-in-one routers and hoping they’d last.

For about 15 years, I cycled through them. Linksys. Netgear Nighthawks. ASUS routers. It didn’t matter which brand—they all developed issues after 2-3 years. Random reboots. WAN ports that just stopped working. WiFi that became progressively more unreliable until it wasn’t reliable at all.

Toward the end of each router’s life, I’d be rebooting it daily just to keep things working.

The pattern was always the same:

Buy new router ($120-300)
Works great for 18 months
Starts having “quirks”
Quirks become daily problems
Replace and repeat

Over 15 years, I probably spent $1,500+ on routers that became e-waste. And that’s not counting the time spent troubleshooting, rebooting, and dealing with random failures.

The Solution: Separation

The answer was obvious in hindsight: stop trying to make one device do everything.

I started with an old computer running OPNsense. It wasn’t pretty, it wasn’t efficient, but it worked. More importantly, it kept working when I rebooted my Proxmox host.

I ran that setup for about six years. The old computer hummed along, doing its one job well, all while I learned what a proper router could actually do.

About two years ago, I upgraded to a Protectli Vault Pro VP2420 for better power efficiency and added a “managed” switch (SODOLA 8-Port 2.5Gb). The principle remained the same, just more refined.

Give each job a proper box:

Router: Dedicated hardware running OPNsense
Storage: Separate NAS that stays up 24/7
Compute: Proxmox host for everything else

I’ll never forget the first time I rebooted my compute node after the separation. I hit the command, waited for the host to go down, and then… nothing happened. The internet stayed up. My wife kept streaming. Nobody called my name.

It was amazing.

What Actually Changed When I Switched

Before (Consumer/Virtualized Router):

Visibility: I could see connected devices and some basic stats. That’s it.

Security: A checkbox labeled “firewall enabled.” No logs, no alerts, no real control. When I checked my Jellyfin logs one day, I discovered someone in Romania had been hammering my server, trying to brute force the default username. My old router never told me this was happening.

Performance: 4K streaming while SABnzbd maxed out my download connection meant random buffering and frustrated family members.

Segmentation: Everything on one network. My Jellyfin server could see my IoT lightbulbs. My download containers could access my NAS directly. Zero isolation.

Uptime: Hostage to whatever I was doing on my Proxmox host. Every experiment, every update, every hardware issue meant the whole house went offline.

After (Dedicated OPNsense Box):

Visibility: Every connection, every blocked attempt, every DNS query. I see exactly what my network is doing.

Security: Five VLANs with explicit allow rules. IDS/IPS running Suricata with Emerging Threats rules. I see attempted port scans and exploit attempts weekly that my old setup never noticed. That Romanian brute force attempt? Now I’d see it in real-time and could block the entire country if needed. (All other countries are now blocked from everything I’m running)

Performance: QoS rules mean Jellyfin never stutters, even when SABnzbd maxes out the connection. Downloads automatically throttle when someone starts streaming. No manual intervention needed.

Segmentation:

10.0.1.x: Trusted devices (laptop, phone)
10.0.2.x: Media stack (Jellyfin, Sonarr, Radarr)
10.0.3.x: IoT devices (cameras, lights)
10.0.4.x: Guest WiFi (isolated)
10.0.5.x: Management interfaces

My IoT devices literally cannot see my NAS. The firewall says “Hell no”.

Uptime: Router runs independently. I can reboot, upgrade, or completely rebuild my compute node without anyone noticing.

The difference is night and day. I went from hoping my network was secure to knowing it is. I went from apologizing for internet outages to working on my servers whenever I need to.

Why Your Current Router is Failing You

What “Advanced Security” Actually Means

Consumer router claims: “Advanced Security Features!”
Reality: Scanning for obvious malware from 2015. Maybe.

Real security means IDS/IPS with updated rulesets, traffic analysis, and actual logging. Your $120 router isn’t doing that.

I didn’t realize how blind I was until I enabled Suricata on OPNsense. Every week I see:

Port scans from random IPs
Exploit attempts targeting common vulnerabilities
IoT devices calling home to suspicious destinations
Brute force attempts on exposed services

My consumer router saw none of this. It was all happening, every day, and I had no idea.

The Single Point of Failure Problem

Your consumer router tries to be:

Router + Firewall + WiFi + Switch + DHCP + DNS + VPN + USB file server

When any piece fails, everything fails. When you need to reboot, everything goes down.

A proper network has separate components:

Router box: Routing, firewall, DHCP, DNS
Switch: Distributes connections, handles VLANs
Access points: Just WiFi

When the AP reboots, your wired devices keep working. When you’re tinkering with your Proxmox host, your family doesn’t notice.

This isn’t theoretical. After eight years of running separated infrastructure, I’ve had zero network-wide outages that weren’t ISP-related. With consumer routers, I had them weekly.

What You’re Actually Exposing

Without proper segmentation:

IoT device gets compromised → Attacker accesses your entire network
With VLANs: They’re trapped in the IoT sandbox

Download client compromised → Direct path to all your files
With VLANs: Container can only talk to specific services

Smart device has vulnerability → Entry point to everything
With VLANs: Isolated and contained

Real example: I tried to tighten security rules on my IoT VLAN once. Made them too restrictive and all my devices lost internet access. No problem. I restored my OPNsense backup from 15 minutes earlier and everything was fine. Try doing that with a consumer router.

The Features That Actually Matter

1. VLAN Support (Network Segmentation)

Create multiple isolated networks on the same hardware. If one thing gets compromised, it can’t spread.

Real example: My media stack runs in VLAN 2 (10.0.2.x). Firewall rules allow internet access for downloading and trusted device access for streaming. Everything else is denied. If a container gets compromised, the damage is contained to that VLAN.

I thought about my VLAN structure for a long time before implementing it. Two years later, I wouldn’t change anything about how it’s set up.

2. Intrusion Detection/Prevention (IDS/IPS)

Your router inspects every packet for known attacks, malware, and suspicious behavior.

I didn’t enable Suricata from day one. I added it after getting comfortable with the basics. The learning curve was real. Lots of forum posts and Reddit threads to understand what I was seeing. But it wasn’t too bad, and now it runs automatically.

What I see every week:

Blocked port scans from random IPs
Exploit attempts targeting known vulnerabilities
Malware callbacks from IoT devices
Geographic attacks I can block at the firewall level

My old consumer router saw none of this. It was all happening, I just didn’t know about it.

3. Real Firewall Rules + Full Logging

Define exactly what’s allowed. See every decision the firewall makes.

My media VLAN rules:

Allow: Internet access (ports 80, 443)
Allow: Internal service communication
Allow: Trusted devices → media services
Allow: NAS access (NFS)
Deny: Everything else (log it)

When something breaks, I check the logs and see exactly what’s being denied. No guessing. No mystery reboots. Just clear information about what happened and why.

4. Local DNS + DHCP Control

Static IPs for all services. Custom DNS entries. Full control.

Instead of remembering 10.0.2.15:8096, I just go to jellyfin.home. All my services have friendly names. Static DHCP means each device always gets the same IP every time. This is critical for firewall rules that actually work.

5. Traffic Shaping + QoS

Prioritize certain traffic. Set bandwidth limits per device.

I didn’t set this up immediately. I added QoS after SABnzbd kept maxing out my 150Mbps download connection and causing buffering on Jellyfin streams.

My current setup (tailored to my needs):

Priority 1: Streaming (Jellyfin, Plex)
Priority 2: YouTube and video
Priority 3: Gaming
Priority 4: Web browsing
Priority 5: Bulk downloads (capped at 80% of available bandwidth)

Now downloads automatically throttle when someone starts streaming. No buffering, no complaints, no manual intervention. It just works.

Router Hardware Options

Note on recommendations: I’ve personally used all the hardware in the Budget and Balanced builds over the years. The Beast build represents what I’d upgrade to if I had the time and budget. It is based on research and community feedback, not hands-on experience.

Budget Build (~$200 Total)

Router Box: $80-170

Used off-lease SFF computers are the best value for starting out. I ran OPNsense on an old desktop computer for six years before upgrading.

Dell Wyse 5070 Extended (J5005)
This is the budget-friendly, low-power OPNsense box that “just works”. Add an Intel i350-T2, give it 8–16 GB of RAM, and you’ve got a quiet, reliable home router with room for VLANs, WireGuard, and moderate IDS.
Price: $80 - $170
Personal note: This is comparable to what I started with. Old hardware running OPNsense for years without issues.

Contains affiliate links. I may earn a commission at no cost to you.

Ebay

Network Card: $30-50

Used Intel NICs are reliable and well-supported in OPNsense and PFsense.

Intel i350-T2
The low-profile Intel i350-T2 drops right into the Wyse 5070 Extended’s PCIe slot and gives you two rock-solid 1 GbE ports with mature FreeBSD drivers, perfect for OPNsense.
Price: $30 - $50

Contains affiliate links. I may earn a commission at no cost to you.

Ebay

Alternative: New Budget Device

Don’t want to deal with used gear? Here’s an affordable new option:

AOOSTAR N1 PRO Intel N150
This affordable, energy-efficient single-board computer is perfect as a low budget router with its dual 2.5Gb network ports and enough processing power to support an IDS.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Switch: $60-90

You need a managed switch to handle VLANs properly.

TP-Link TL-SG116E
Is a 16-port, fanless Gigabit “Easy Smart” switch with a metal shell, web GUI, and essentials like 802.1Q VLANs, trunks, and QoS. It’s a great budget match for an OPNsense router build: quiet, low-power, cheap, and gives you the VLAN segmentation and uplink tagging you need without paying managed-switch tax.
Personal note: I used this class of switch for years before upgrading to 2.5GbE.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Dedicated Wireless Access Point (WAP): $60-80

Having a dedicated WAP can really improve the Wi-Fi signal in your house. You can place it in the optimal location with just an ethernet cable.

TP-Link EAP225
Is a ceiling-mount, PoE-powered, dual-band 802.11ac with a Gigabit uplink, and simple Omada controller management. It honors 802.1Q VLANs for clean SSID-to-network mapping (Main/IoT/Guest), and delivers fast, reliable Wi-Fi.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

What this setup can handle:

Gigabit routing with IDS/IPS
5-6 VLANs
Up to 50 devices
Basic VPN

Who this is for: 95% of home users with gigabit internet or slower.

Balanced Build (~$500 Total)

This is what I currently run. After six years on budget hardware, I upgraded to this configuration two years ago for better power efficiency and multi-gig speeds.

Router Box: $320-500

Protectli Vault Pro VP2420-4 Port
A fanless mini-appliance with a 4-core Intel J6412, 4× 2.5GbE Intel i225 ports, AES-NI. It’s a strong mid-tier OPNsense base that stays quiet and sips power while handling gigabit-plus routing, as well as fast VPN access.
Personal note: This is exactly what I’m running. Two years in, zero hardware issues. It’s silent, efficient, and handles everything I throw at it.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Switch: $90

SODOLA 8-Port 2.5Gb Web Managed Switch
Provides eight 2.5GbE ports, a quiet fanless metal chassis, and a simple web UI with essentials like 802.1Q VLANs, QoS, and link aggregation. It fits a mid-tier router build by unlocking multi-gig LAN speeds for NAS and desktops while keeping segmentation clean and power draw low.
Personal note: I installed this when I upgraded to the Protectli. VLANs were straightforward to set up, and the 2.5GbE speeds make a real difference for NAS transfers.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Wireless Access Points

I run four TP-Link Deco units in a mesh configuration. Mostly I use them as dumb APs, but the controller software is useful for one thing: forcing specific devices to specific APs. Some devices are too aggressive about switching APs, which caused buffering during video playback. Pinning them to one AP solved it.

For new buyers, I’d recommend proper ceiling-mount APs instead:

TP-Link Omada WiFi 7 - Dual Band
A PoE ceiling-mount WiFi 7 access point with a 2.5 GbE uplink, Omada controller support, and VLAN-aware SSIDs for clean network segmentation. It fits a mid-tier router build by delivering fast, reliable wireless, simple central management, and a clear upgrade path without blowing the budget.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

What this setup can handle:

Multi-gig speeds (2.5GbE)
Heavy IDS/IPS
VPN at line speed
50+ devices

Who this is for: People who want room to grow and don’t want to upgrade again in 2-3 years.

Beast Build (~$1,200 Total)

Full disclosure: I haven’t personally used this hardware. This represents what I’d upgrade to if I had the budget and needed more performance. Based on community feedback and research, not hands-on experience.

Router Box: $600-700

MINISFORUM MS-01 Mini Workstation
A compact workstation with a high-core-count Intel CPU, dual 10 GbE SFP+ ports, dual 2.5 GbE, NVMe storage, and room to scale. It is ideal for a top-tier OPNsense build because it can push multi-gig routing, run IDS/IPS and high-speed VPN without breaking a sweat and still leave room for future upgrades.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Switch: $360

SODOLA 24 Port 2.5Gb PoE Switch
This switch packs dense multi-gig PoE for APs, cameras, and IoT while keeping management simple with VLANs, and QoS. It’s a strong top-tier fit because your OPNsense box can push multi-gig uplinks and this switch distributes that speed across the whole network without noisy rack gear.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Access Point: $200

TP-Link Omada WiFi 7 - Tri-Band
Brings 2.4/5/6 GHz and Multi-Link Operation for large capacity, and low latency. It fits a top-tier OPNsense build with a multi-gig PoE uplink, clean SSID-to-VLAN mapping, Omada controller features like fast roaming and band steering, and headroom for dense homes or busy offices.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

What this setup can handle:

10GbE at line speed
Extremely complex rules
Multiple simultaneous VPN connections
100+ devices
Future-proof for years

OPNsense vs pfSense: Which Should You Choose?

Choose OPNsense if:

You’re new and want a cleaner interface
You want built-in IDS/IPS
You prefer frequent updates
All features are included without licensing

Choose pfSense if:

You want the most mature platform
You prioritize stability over features
You need the largest community
Don’t mind a more corporate feel

My recommendation: Start with OPNsense. The interface is friendlier while being just as powerful. I’ve run it for eight years across multiple hardware generations without major issues.

Either choice is infinitely better than a consumer router.

Your First Weekend with OPNsense

Let me be honest about timelines. My original draft said “48 hours” but that’s optimistic. Here’s what actually happened when I set mine up.

Hour 1-2: Basic Installation

Installation:

Download OPNsense ISO, flash to USB
Boot router box, install to internal drive
Reboot, remove USB

This part is straightforward. If you’ve installed Linux before, this will feel familiar.

Hour 2-4: Initial Configuration

Getting Internet Working:

Connect WAN to modem, LAN to computer
Access web interface at 192.168.1.1
Run setup wizard: Set password, configure WAN/LAN, set timezone
Update to latest version
Configure DNS and test internet

Expect this to take longer than you think. My first attempt, I had to reboot the modem twice before the WAN interface pulled an IP. Normal stuff, but it eats time.

Weekend 2-3: VLANs

Creating Your First VLAN:

VLANs are where it gets tricky. I spent time wrapping my head around the concept before implementation paid off.

Start with IoT if you have IoT devices (and at this point most of us do). It’s the easiest to isolate and test:

Create VLAN on your switch (VLAN ID: 3)
Create VLAN interface in OPNsense (Interfaces → VLAN)
Assign and configure the interface (10.0.3.1/24)
Enable DHCP for the VLAN
Create firewall rules:
- Allow: IoT → Internet (ports 80, 443, 53)
- Allow: IoT → DNS Access to your DNS server
- Block: IoT → All other RFC1918 private networks
Test: Connect device, verify it works but can’t reach other VLANs

The first VLAN took me several hours. The second took one hour. By the fifth, it was fifteen minutes.

Common VLAN Mistakes I Made:

Forgetting to tag the trunk port on the switch - Spent 30 minutes troubleshooting why devices couldn’t get IPs before realizing the switch wasn’t passing VLAN tags.
Creating rules on the wrong interface - Made perfect firewall rules on the WAN interface instead of the VLAN interface. They did nothing.
Blocking DNS accidentally - Blocked RFC1918 addresses but forgot that my router (which provides DNS) is on 10.0.1.1. IoT devices couldn’t resolve anything.

Week 3-4: IDS/IPS

I didn’t enable Suricata immediately. Get comfortable with basic routing and VLANs first.

When I added IDS/IPS:

Services → Intrusion Detection → Administration
Enable IDS
Download Emerging Threats ruleset
Start in IDS mode (alerts only, no blocking)
Watch alerts for a week
Tune rules to reduce false positives
Switch to IPS mode (active blocking)

The learning curve was real. Lots of alerts I didn’t understand. Lots of forum threads explaining what “ET POLICY” rules meant. But after a few weeks, it clicked.

💡

Tip: Start with IDS mode only. Don’t enable blocking until you understand what you’re seeing. I almost blocked my entire media VLAN because I didn’t understand a legitimate traffic pattern Suricata flagged.

Week 4-6: QoS and Polish

I added QoS when SABnzbd kept ruining movie night.

Downloads would max out my 150Mbps connection, and Jellyfin streams would buffer. Annoying for me, unacceptable for my wife.

Setting up traffic shaping:

Firewall → Shaper → Settings
Create pipes for download/upload
Create queues for different traffic types
Assign priorities
Test with actual usage

My current priorities (tailored to 150/30 Mbps connection):

Queue 1 (Highest): Jellyfin streaming, Plex
Queue 2: YouTube, video platforms
Queue 3: Gaming traffic
Queue 4: Web browsing
Queue 5 (Lowest): SABnzbd, torrents (capped at 120Mbps / 80%)

Now downloads run in the background without impacting anything else. No manual throttling needed.

Current State: Set and Forget

After the initial setup period, I barely touch OPNsense.

Weekly routine:

Check for updates (takes 2 minutes)
Review IDS/IPS alerts (5 minutes)
Check logs if something seems weird (rarely needed)

Monthly:

Review firewall rules to see if anything needs adjustment (usually doesn’t)
Download config backup

That’s it. The router just works. No daily reboots. No random failures. No “why is the internet down?” conversations.

In two years with the Protectli, I’ve had zero hardware failures. Compare that to 15 years of consumer routers dying every 2-3 years.

Common Problems and Fixes

Can’t Access Internet After Setup

Symptoms: OPNsense installed, but no internet access

Check:

WAN interface has IP address (Interfaces → Overview)
Gateway shows as online (System → Gateways → Single)
DNS servers configured (System → Settings → General)
Try pinging 8.8.8.8 from Diagnostics → Ping

Fix: Usually the modem needs a reboot. Power cycle it, wait 2 minutes, check again.

VLANs Not Working

Symptoms: Device on VLAN can’t get IP or access internet

Check:

VLAN created on switch with correct ID
Trunk port configured between router and switch
VLAN interface assigned in OPNsense
DHCP enabled for VLAN
Firewall rules allow traffic

Fix: 90% of the time it’s switch configuration. Verify VLAN tagging is correct.

Locked Yourself Out

Symptoms: Changed firewall rules, now can’t access web interface

Fix:

Connect directly to LAN port
Access 192.168.1.1 (default LAN IP)
If that doesn’t work: Boot to recovery mode, reset to last config
Last resort: Reinstall and restore from backup (you made backups, right?)

This is why you download config backups regularly.

Specific Mistake I Made: IoT Security Lockdown

What I tried: Tightened security rules on IoT VLAN to block more traffic

What broke: All IoT devices lost internet access completely

What I learned: I was too aggressive blocking outbound traffic. Smart devices need to call home for updates and cloud features. You can restrict them, but not completely isolate them.

How I recovered: Restored OPNsense backup from 15 minutes earlier. Back to working state in 2 minutes.

Lesson: Always download a config backup before making major changes. Test changes incrementally. Have a rollback plan.

Common Mistakes to Avoid

Over-Complicating Day One

Start simple. Get basic routing working before adding anything else.

My recommended progression:

Weekend 1: Install OPNsense, get internet working
Weekend 2-3: Add one VLAN, test thoroughly
Weekend 4: Add remaining VLANs
Week 3-4: Enable IDS/IPS in monitoring mode
Week 5-6: Add QoS if needed
Ongoing: Tune and optimize

💡

Tip: Don’t try to do everything at once. I thought about my VLAN structure for weeks before implementing it. That planning paid off, I haven’t changed anything about how VLANs are organized in two years.

Not Documenting

Keep notes on:

What each VLAN is for
Why specific firewall rules exist
What each static IP is assigned to
Changes you make and why

Future you will thank you. I have a simple Obsidian note:

VLAN 2 (10.0.2.x) - Media Stack
  - Jellyfin, Sonarr, Radarr, SABnzbd
  - Allows: Internet (80, 443), NAS access, Trusted devices
  - Blocks: IoT VLAN, Guest VLAN

Rule: Allow trusted → Media (8096)
  Why: Access Jellyfin from phones/laptops
  Created: 2023-02-15

Simple, but invaluable when troubleshooting at 11 PM.

Not Testing Firewall Rules

After creating block rules, actually test them. Don’t assume they work.

How I test:

Create rule to block IoT → NAS
From IoT device, try to ping NAS IP
Check firewall logs to confirm block

If the rule doesn’t show up in logs, it’s not working. Figure it out and fix it now, not when you have a security incident.

No Config Backups

Download your config regularly. Hardware can fail. Updates can go wrong. Accidents happen.

My backup routine:

After any major change: Download config immediately
Weekly: Download fresh backup (takes 30 seconds)
Store backups in three places: NAS, cloud, USB drive

I’ve restored from backup twice:

When I locked myself out with aggressive firewall rules
When I tried an OPNsense update that didn’t play nice with my hardware (rolled back, waited for next version)

Both times, I was back up in minutes instead of hours of reconfiguration.

Ignoring IDS/IPS Alerts

Review alerts weekly. This is your early warning system.

What I check every week:

New alert types I haven’t seen before
Repeated alerts from same source (might need blocking)
Internal devices generating alerts (compromised?)
Geographic patterns (lots of traffic from one country?)

Takes 5 minutes.

Integration with Your Four-Box Stack

This is why we separate the router from everything else.

Network Topology

[Modem] → [Router/Firewall] → [Managed Switch]
                                 ├→ [NAS] (VLAN 2)
                                 ├→ [Compute Box] (VLAN 2)
                                 ├→ [Access Points] (Multiple VLANs)
                                 └→ [Other Devices] (Various VLANs)

Boot Order Matters

Router → Storage → Compute

Why this order:

Router boots first: Network is available for everything else
Storage boots second: NAS is ready when compute needs it
Compute boots last: Services start when dependencies are ready

How to set delays: You might be able to set delays in BIOS/UEFI for each box depending on your hardware:

Router: Auto-start immediately (0 second delay)
Storage: 30-second delay after power on
Compute: 60-second delay after power on

Real-world benefit: Power outage happens. Everything comes back automatically in the right order. No manual intervention needed.

Why Separation Matters (Again)

I’ve lived both sides of this.

With virtualized router (2 years):

Rebooting compute = entire house offline
Hardware failure = no internet until fixed
Testing new containers = risk to network stability
Update that goes wrong = everything down

With separated router (4 years total, 2 with current hardware):

Reboot compute whenever needed = nobody notices
NAS drive failure = internet stays up while I fix it
Container experiment goes wrong = network unaffected
Proxmox update goes sideways = restore snapshot, internet never dropped

The peace of mind is worth every penny.

When to Ask for Help

You will get stuck. Everyone does. Here’s where to go.

Official Resources

OPNsense Documentation: https://docs.opnsense.org/
Start here. Covers installation, basic config, features, and troubleshooting.

OPNsense Forum: https://forum.opnsense.org/
Active community. Search before posting—someone has probably had your exact problem.

Community Resources

Reddit:

r/OPNsenseFirewall - Dedicated to OPNsense specifically
r/homelab - Broader homelab topics, lots of OPNsense users
r/selfhosted - Media server and self-hosting focus

The OPNsense Foundation: Building a Bulletproof Homelab Firewall (Part 1)
Looking for a comprehensive OPNsense setup? Check out this detailed installation and configuration guide from corelab.tech. This two-part series covers everything from initial setup to advanced configuration, providing a complete walkthrough for getting OPNsense running properly.

View Article

How to Ask for Help Effectively

When posting for help, include:

What you’re trying to do: “Setting up VLAN for IoT devices”
What you’ve tried: “Created VLAN 3 on switch and OPNsense, enabled DHCP”
What’s happening: “Devices get IP but can’t access internet”
Relevant logs: Screenshots or text of firewall logs
Firewall rules: Screenshots of rules for that interface

Bad post: “My VLANs don’t work, help!”

Good post: “IoT VLAN devices get DHCP but can’t reach internet. Created VLAN 3, enabled DHCP on 10.0.3.1/24, firewall rules allow ports 80/443 outbound. Logs show blocked packets to 8.8.8.8. Screenshots attached.”

The good post gets answered quickly. The bad post gets ignored or gets “need more information” responses.

The Bottom Line

After 15 years of consumer routers and 6 years running OPNsense, I’ll never go back.

What you give up:

One-box convenience
“It just works” (initially)

What you gain:

Network segmentation that contains breaches
Real intrusion detection that shows you threats
Full traffic visibility, you know what’s happening
Actual control over your network
Reliability that doesn’t degrade over time
Independence from your compute infrastructure

Is it more work? Yes, initially. The first few weekends require learning and configuration.

Is it worth it? Absolutely.

You’re building infrastructure worth thousands of dollars. Protecting it with a $120 consumer router that randomly reboots is like putting a $20 padlock on a bank vault.

The peace of mind alone is worth it. No more “why is the internet down?” conversations. No more daily reboots. No more wondering if your network is secure.

You’ll know it’s secure because you built it that way.

Real Numbers: Cost Over Time

Let me show you the actual economics.

Consumer router approach (what I did for 15 years):

New router every 2.5 years: $150 average
15 years = 6 routers = $900
Plus time troubleshooting, rebooting, replacing
Security: Hope and prayer

Dedicated router approach (what I’m doing now):

Budget build: $200 initial investment
Expected lifespan: 5+ years (I’m at 8+ years across two hardware generations)
Electricity: ~15W vs 30-50W consumer router (actually saves money)
Security: Real, verifiable, logged

Even if you replaced the budget build every 5 years, you’d spend $200 every 5 years ($40/year) versus $150 every 2.5 years ($60/year).

You save money while getting massively better security and reliability.

My current Protectli cost $400. Over 5 years, that’s $80/year. Still cheaper than consumer routers, and I expect it to last longer than 5 years based on how the previous hardware held up.

What’s Next

You’ve got your router sorted. Your network is segmented and secure. You can work on your compute infrastructure without taking down the internet.

In Part 3, we build the vault: A proper NAS that won’t lose your data when drives fail. We’ll talk about storage options like MergerFS + SnapRaid, ZFS, and off the shelf options, proper backup strategies, and why your data deserves more respect than a single external hard drive.

Read Part 3: Your Storage Deserves Its Own Box

Quick Reference: OPNsense Commands

Keep this handy for common tasks:

Reboot: System → Power → Reboot
Apply firewall changes: Firewall → Rules → Apply Changes (the orange banner)
Check blocked traffic: Firewall → Log Files → Live View
See active connections: Firewall → Diagnostics → States Dump
Check DHCP leases: Services → DHCPv4 → Leases
IDS/IPS alerts: Services → Intrusion Detection → Alerts
Backup config: System → Configuration → Backups → Download configuration
Test connectivity: Diagnostics → Ping (or Diagnostics → Traceroute)
Check interface status: Interfaces → Overview
View system logs: System → Log Files → General

Media Server Hardware Guide (2025): The 4-Box Setup That Just Works

Wed, 29 Oct 2025 07:25:02 -0600

Everyone starts with the dream: one box to rule them all. Media apps, storage, downloads, and yes, even routing if you’re feeling extra ambitious.

Then reality hits. Reboot time becomes a nightmare. LXCs start before storage mounts. Apps can’t find their configs. Nothing works unless you babysit the boot order like it’s a toddler who just discovered scissors.

The fix?
Four boxes.
Clear roles.
Real uptime.

Ask me how I know.

Spoiler: It involves a VM NFS Server, Jellyfin LXC, and a very angry Sunday afternoon where I almost threw my server out the window.

Why I Ditched My VM NAS and Went Bare-Metal

💭 TL;DR

A stable home media server needs four dedicated machines: one for routing ($150-$500), one for storage ($400-$1900), one to run your apps ($200-$1400), and one for backups (150-400). Total investment: $900-$4200. Expected build time: 2-4 weekends. The payoff: 99% uptime instead of the 80% you're getting now from your all-in-one box that needs constant nurturing.

Who This Guide Is For

You’re the right person for this if:

You’re running everything on a single machine, and it’s becoming a headache
You’ve experienced the “nothing works after a reboot” phenomenon
You’re ready to invest $900-$4,200 and a few weekends for a reliable setup
You want to learn Proxmox, networking, and proper homelab architecture
You’re tired of your family asking why the streaming server is down again

You might want something else if:

You just want to watch a few movies and don’t care about uptime (get a Synology and call it done)
You have zero interest in learning Linux or networking basics
Your budget is under $900 total (stick with a single good machine for now)
You need this working by next weekend (this is a learning journey, not a race)

Skills you’ll need (or learn along the way):

Basic Linux command line comfort (you can navigate directories and edit files)
Willingness to read documentation when things break (and they will)
Basic networking concepts (what’s an IP address, what’s a subnet)
Patience for the learning curve (expect some frustration, especially around Proxmox LXCs)

Don’t worry if you’re not an expert. I wasn’t either. You’ll learn by doing, and I’ll point you to resources when you need them.

The Real ROI: What This Actually Costs You

Let’s talk money. Because yes, you’re about to spend $900-$4,200 on hardware. That sounds like a lot until you do the math on what you’re already spending.

The Streaming Service Tax

Here’s what you’re probably paying right now:

Service	Monthly Cost
Netflix (Standard)	$17.99
Disney+ & Hulu	$19.99
Max (HBO)	$18.49
Prime Video	$8.99
Apple TV+	$12.99
Peacock	$10.99
Paramount+	$13.99
Starz	$4.99
Crunchyroll	$7.99
TOTAL	$116.41/month

That’s $1,396.92 per year. Every year. For-ev-er.

And it’s getting worse. Remember when Netflix was $7.99? Yeah, so do I.

Don’t have streaming services? Cable on average is about $100.00/month too.

Have streaming services and cable? Wow.. This guide can help you the most.

The Break-Even Math

Budget build ($900):
You break even in 8 months. After that, you’re saving over $1,400/year.

Mid-range build ($1,900):
Break even in 16 months. Then it’s pure savings.

Dream build ($4,200):
Break even in 36 months, but you’ve built something that’ll last 5-9 years.

But Wait, There’s More

The math above assumes you cancel everything. But realistically, you’ll probably keep 1-2 services (I keep Prime Video because I like to have something available if in the rare event my Jellyfin server goes down).
Even if you only cancel 6 out of 9 services, you’re saving $80+/month. That’s $960/year.

Plus you get:

Content you actually want to watch (not algorithmic slop)
No more “sorry, that’s leaving the platform in 3 days”
No more “this show is on Peacock now, not Netflix”
No more paying for multiple services just to watch one show
Complete control over quality (no streaming compression)
Offline access (because internet outages happen)

The Hidden Costs They Don’t Tell You

Streaming services love to fragment. That show you’re watching? Season 1-3 are on Netflix. Season 4 moved to Paramount+. The spinoff is Max-exclusive. The movie that inspired it all is on Disney+.

You end up subscribing to four services just to watch one franchise. Or you play subscription roulette, canceling and re-subscribing monthly (and praying you remember to cancel before they charge you again).

With your own server? You watch what you want, when you want, without playing platform musical chairs.

The Power Bill Reality Check

“But what about electricity?”

Fair. Let’s do that math too:

Average 4-box stack: ~130W idle, ~220W under load
Running 24/7 at $0.12/kWh: ~$12-16/month
So your actual monthly cost: $12-16 in power

You’re still saving $80-90/month vs. streaming services. That’s $960-$1,080/year in your pocket.

What About Content Acquisition?

Look, I’m not going to tell you how to get your “Linux ISOs”. But let’s just say that if you’re already paying for content through other means (totally legal Blu-ray ripping, of course), you’re not adding costs. You’re just organizing what you already own.

And if you’ve got a library card? Many libraries offer free streaming through Hoopla, Kanopy, or similar services. Rip, organize, and keep forever. All legal, all free.

I have several guides on all of this here are a few:

The Intangible Benefits

This isn’t just about money. It’s about:

Not having shows you’re watching get canceled mid-season
Not dealing with ads (even on “ad-free” tiers that still show promos)
Not having your smart TV spy on your viewing habits
Not being at the mercy of licensing deals and regional restrictions
Actually owning your media instead of renting it monthly

The bottom line: Even the dream build pays for itself in 3 years. After that, you’re saving $1,400/year while having a better experience, more control, and media that’s actually yours.

That’s not a cost. That’s an investment that keeps paying dividends.

SECTION 1: Why One Box Isn’t Enough

Let’s start with the classic mistake: cramming everything (Jellyfin, Sonarr, Radarr, qBittorrent, SABnzbd, storage, Docker, and maybe even OPNsense if you’re really ambitious) onto that old desktop collecting dust in your closet.

It works.
Until it doesn’t.

Here’s what goes wrong:

One reboot = full outage.
Your apps don’t just go offline. They could come back in the wrong order. Jellyfin can’t see your media because NFS hasn’t mounted yet. Sonarr can’t write downloads because the share isn’t ready. That boot-time race between your LXC containers and your storage mounts? Nobody wins. Especially not you.

Performance becomes a bottleneck.
You’re trying to transcode a 4K stream while ZFS is scrubbing, torrents/nzbs are verifying, and your CPU is melting down. Everything competes for the same I/O, RAM, and CPU cores. There’s no isolation. Just a noisy soup of services fighting for resources.

Security is non-existent.
Mixing your media stack with your router or storage means one compromised container could break your entire network or corrupt your storage. Ever had Jellyfin accidentally nuke a mounted drive path? I have.

Troubleshooting becomes impossible.
Is it Jellyfin’s fault? A bad NFS mount? A network issue? You don’t know, because everything’s tangled together. Diagnosing one problem means taking down everything else to test it.

You can’t upgrade or experiment safely.
Want to try that new transcoding setup? Too bad. You’re scared to touch anything because a mistake means your entire network goes down. You’re paralyzed, stuck with a setup you hate because changing it is too risky.

My Breaking Point

I ran everything on one computer for years. It worked. Mostly. Until the power supply died.

The server went silent. And because I ran OPNsense, Jellyfin, and my NAS all on the same computer I had no internet and no access to my media.

While my partner asked increasingly pointed questions about when the internet will be back up.

Four hours and a trip to BestBuy later, I got it back up and running.

That’s when I have learned: building a modular homelab media server isn’t just for fun. It’s the only way to achieve real uptime, better performance, and the ability to fix one thing without breaking everything else.

SECTION 2: The Four-Box Philosophy

Here’s the core idea: separate traffic, storage, compute, and backup into four dedicated machines.

Each machine does one job. Does it well. Stays stable. And doesn’t bring down the others when it needs maintenance.

The Stack:

Box 1: Router ($150-$500)
Controls all traffic, handles DNS, manages VLANs, runs your firewall. This is the gatekeeper.

Box 2: Storage ($400-$1900)
Holds all your media, provides redundancy, serves files to everything else. This is your vault.

Box 3: Compute ($200-$1400)
Runs all your apps: Jellyfin, Sonarr, Radarr, and any new software you want to try. This is the chaos layer where Virtual Machines and containers change, break, and get rebuilt.

Box 4: Backup ($150-$400)
Backup your compute node’s LXCs and VMs. Something breaks after a change just roll-back to the last working backup. This is your insurance policy.

Why This Works:

Modularity = Sanity.
Reboot compute without touching storage. Upgrade your NAS without breaking Jellyfin. Swap routers without tearing down your entire stack. When one piece fails, the others keep running.

Clear Failure Domains.
Something breaks? You know exactly where to look. Service down? Check compute. Files missing? Check storage. Network problems? Check the router. No more digging through monolithic logs trying to find which piece is the problem.

Easy Scaling.
Need more storage? Add drives to the NAS. Need more CPU power? Upgrade the compute box. Want faster networking? Upgrade the router. You’re not locked into some Frankenstein all-in-one that requires replacing everything to improve one thing.

Safe Experimentation.
Want to try Tdarr? Spin up an LXC. Want to test a new Jellyfin build? Clone your container. Breaking something on the compute box doesn’t take down your network or risk your data.

SECTION 3: Box 1 – The Router (Your Gatekeeper)

Your router is the traffic cop of your entire media stack. If it sucks, everything downstream suffers.

And yes, your ISP’s all-in-one Wi-Fi “router” absolutely sucks.

Why a Dedicated Router Matters:

You need control, not guesswork.

Static IPs for all your services so they don’t randomly change
VLANs to isolate your download clients from the rest of your network
Firewall rules to keep risky devices in their own sandbox
DNS that resolves jellyfin.home instead of forcing you to remember IPs

You might get some of that from a consumer “gaming” router with racing stripes. You will get it all from a real box running OPNsense or pfSense.

Security starts here.
A proper firewall lets you isolate containers, restrict traffic by IP, and run reverse proxies safely. You can actually see what’s happening through logs and alerts. You’re not flying blind hoping nothing bad gets through.

Your media traffic stays fast.
4K Jellyfin streams shouldn’t fight with torrent downloads and game updates for bandwidth. Smart routing and QoS means your streams stay smooth even when everything else is maxed out.

Network isolation becomes possible.
Keep your kids’ devices off the same subnet as your torrent client. Put Home Assistant on a separate VLAN with no access to your NAS. Isolate your IoT lightbulbs from anything that matters. This is how you build defense in depth.

What You’ll Actually Do With It:

Set up static DHCP reservations for every device in your stack
Create VLANs for different trust levels (trusted, media, IoT, guest)
Configure firewall rules to control what can talk to what
Set up a reverse proxy (Nginx Proxy Manager or Traefik) for clean URLs
Monitor traffic to see what’s hogging bandwidth

A proper router for your home server setup isn’t just about speed. It’s about control. And it’s the first box that makes the rest of your stack possible.

Coming in Part 2: I’ll show you exactly which routers to buy, from the $150 AOOSTAR N1 PRO that punches above its weight to the $500+ “final boss” build that handles 10Gbps like it’s nothing.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

SECTION 4: Box 2 – Storage (Your Vault)

Your media has to live somewhere. And no, your download’s folder on a single SSD isn’t going to cut it when you’re storing terabytes of movies and TV shows.

This is where the NAS comes in. It holds everything, keeps it safe, and makes sure it’s still there tomorrow when you wake up.

Why Storage Deserves Its Own Box:

You need redundancy.
Hard drives fail. It’s not if, it’s when. (Ask me about my dead 14TB drive that took 9TB of unwatched shows with it.) A proper NAS setup whether its ZFS, SnapRAID, Unraid, or mirrored drives, gives you fault tolerance. You lose a drive without losing your media. Your compute server shouldn’t be the one keeping data alive. That’s not its job.

You need speed and consistency.
Streaming 4K, transcoding, downloading, and seeding all at once? You need fast sequential reads and smart caching. A NAS optimized for this workload handles it better than random drives thrown into your compute box.

Everything needs to find files reliably.
When storage is its own box, it boots first, mounts clean, and stays available. Your LXCs don’t wonder if /mnt/media is ready. They just connect via NFS or SMB and work. No more boot-order mysteries or race conditions.

You need upgrade flexibility.
Rebuilding your Jellyfin container? The NAS doesn’t care. Upgrading your compute box? Your media stays untouched. Separating storage from compute means you can break, upgrade, or rebuild services without risking your files.

What You’ll Actually Do With It:

Set up RAID or ZFS pools for redundancy
Configure NFS or SMB shares for your media libraries
Set up automated scrubs to catch bit rot early
Monitor drive health with SMART data
Plan your backup strategy (yes, RAID is not a backup)

The Boot Order Secret:

Here’s the key: Router boots first. Storage boots second. Compute boots third.

This order matters. When storage is ready before compute starts, your LXCs never race against mount points. Everything just works. This alone eliminates 90% of the “why isn’t Jellyfin seeing my files” problems.

A dedicated NAS for your media server turns chaos into reliability. It’s not just extra drives—it’s peace of mind that your data will be there tomorrow.

Coming in Part 3: The actual NAS builds, from budget SnapRAID setups using old hardware to dream ZFS rigs that’ll make you feel like you work at a data center.

Seagate IronWolf Pro 16 TB
Seagate’s IronWolf HDDs are perfect for a NAS. They are engineered to run 24/7 for years. They also include a 5-year warranty.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

SECTION 5: Box 3 – Compute (Your Workhorse)

This is the fun box. The one that runs everything: Jellyfin, Sonarr, Radarr, Tdarr, Bazarr, Lidarr, and whatever new -arr appears next week.

It’s where things happen. But it only works because the other boxes are doing their jobs.

Why Compute Needs Its Own Home:

It’s where the mess lives.
App updates. LXC templates. Docker networks. Transcoding jobs. This is the chaotic, ever-changing layer of your stack. You want it isolated so you can blow things up, reboot, or rebuild without touching storage or breaking your network.

You get proper service isolation.
Run Jellyfin in one LXC and qBittorrent in another. Experiment with Bazarr or Prowlarr without wrecking your stable setup. Proxmox makes this easy whether you’re using full VMs or lean LXCs.

You have actual resource control.
Assign specific RAM, CPU cores, and disk I/O to each container. Want Tdarr to use every core you’ve got overnight but stay quiet during the day? Done. Want to make sure qBittorrent can’t steal resources from Jellyfin during movie night? Easy. Good luck getting that kind of control on a janky all-in-one setup.

It’s built to change.
Want GPU passthrough for transcoding? Add it. Need more RAM? Upgrade just this box. This is the only part of your stack that should change regularly, so build it to take hits and keep going.

Pets vs Cattle: Why This Changes Everything

Here’s a concept from DevOps that’ll change how you think about your services:

Pets are servers you name, nurture, and baby. When they get sick, you stay up all night nursing them back to health. You’re terrified to reboot them because something might not come back right. You’ve spent hours configuring them just so, and the thought of rebuilding makes you break out in a cold sweat.

Cattle are servers you number, not name. If one gets sick, you cull it and spin up a replacement. They’re built from templates, configured automatically, and completely disposable. Lose one? Who cares. You’ve got backups and can rebuild it in minutes.

Your all-in-one box? That’s a pet. You’re scared to touch it. Every update is a gamble. You’ve probably got configs and tweaks you can’t even remember making. If it dies, you’re spending days rebuilding from memory and hoping you didn’t forget anything critical.

This four-box setup? It lets you treat services as cattle.

Here’s how:

Storage is separate = data is safe.
Your media, configs, and databases live on the NAS. When you rebuild a container, all your important data is still there. You’re not risking your files every time you experiment.

Proxmox makes containers disposable.
Spin up an LXC in 2 minutes. Test something. Hate it? Delete it. No drama. Want to try a different Jellyfin version? Clone your container, test it, keep what works.

Backups make everything replaceable.
With Proxmox Backup Server (coming in Part 5), you can restore any container to any point in time with one click. Accidentally nuke your Sonarr config? Restore yesterday’s backup. Takes 3 minutes.

Real-world example from my stack:

I wanted to test Jellyfin 10.11.0 (Major changes in this update), but I was running 10.10.7 in production. Old me (one-box setup) would’ve been too scared to upgrade. What if it breaks? What if I can’t roll back?

New me (three-box setup):

Snapshot my Jellyfin LXC (30 seconds)
Clone it to a test container (2 minutes)
Upgrade the test version, break things, learn stuff
Decide the new version wasn’t ready for Ubuntu yet
Delete the test container, keep running production
Total risk to my family’s movie night: zero

This is the mentality shift that makes homelabbing fun instead of terrifying. You stop being afraid to experiment because nothing you do can truly break things. Your data is safe on the NAS. Your configs are backed up. Your containers are cattle.

When your Nginx Proxy Manager container gets weird? Nuke it. Restore from last night’s backup. Six minutes later you’re back online, and you didn’t even break a sweat.

That’s the power of separation. Your compute box becomes a playground instead of a house of cards.

What You’ll Actually Do With It:

Install Proxmox VE as your hypervisor
Create LXC containers for each service (Jellyfin, AudioBookshelf, PiHole, etc.)
Create VMs for specific Docker stacks (Arr Suite, Immich, etc.)
Mount your NFS shares from the storage box
Set up GPU passthrough for hardware transcoding
Configure automated container backups
Learn to love (and occasionally hate) Proxmox’s web interface

The Learning Curve:

Proxmox has a reputation. It’s powerful but not exactly hand-holdy. You will:

Screw up your first few LXCs (everyone does)
Accidentally delete something important (keep backups)
Spend an hour Googling why NFS mounts aren’t working (permissions, always permissions)
Eventually figure it out and feel like a genius

This is normal. This is the path. Embrace it.

A proper Proxmox media server isn’t just powerful. It’s resilient. And with the right storage and network behind it, you can finally stop fixing things and start watching stuff.

Coming in Part 4: The actual Proxmox builds, from repurposed office PCs to custom rigs, plus the LXC templates and configurations that actually work.

Intel® Core™ i5-12500 12th Generation Desktop Processor This CPU is ideal for Proxmox homelabs, providing strong single-thread performance and efficient virtualization—perfect for experimenting with LXC containers.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

SECTION 6: How They All Work Together

This isn’t just three random boxes sitting on a shelf. It’s a system where each component has a clear job and makes the others better.

The Flow:

Router boots first.
It brings up the network, handles DHCP, starts DNS. Everything else depends on this foundation. It’s the traffic cop and bouncer rolled into one.

Storage boots second.
With the network ready, your NAS comes online, mounts its drives, starts serving files via NFS/SMB. Now the vault is open and ready.

Compute boots third.
With networking and storage available, Proxmox fires up, LXCs start in order, apps connect to their storage mounts, and everything just works. No race conditions. No mysteries. Just reliable boots.

When Something Breaks:

Router problem? Network is down, but storage and compute are fine. Swap in a backup router (or fix the issue), restore config, back online.

Storage problem? Media streaming stops, but your network still works. You can troubleshoot, check drives, restore from backup. Apps keep running (even if they can’t access files).

Compute problem? Services go down, but your network and data are safe. Reboot it. Restore a container from backup. Rebuild from scratch if needed. Your files and network never blinked.

This is the magic of separation. Problems stay contained. Fixes don’t cascade. You’re not gambling with your entire setup every time something hiccups.

SECTION 7: The Fourth Box - Backups

You’ve got your router. Your storage. Your compute. Feels solid, right?

Until something breaks. Then it’s panic mode, unless you have Box 4: Backup Server.

Proxmox Backup Server – The Box That Saves You

If you’re running VMs or LXCs, you need backups that actually work. Not rsync scripts you never test. Not drive clones you made once in 2023. Real, restorable, tested backups.

What PBS does:

Automated daily backups of all your containers and VMs
Deduplication so you can keep weeks of snapshots without filling drives
Versioned backups you can browse by date
One-click restores directly from Proxmox’s interface
Verification to make sure backups actually work

Real-world save:
I once destroyed the wrong LXC in Proxmox (RIP Nginx Proxy Manager). PBS had me back online in 7 minutes. Without it? I’d have spent hours rebuilding configs from memory and old screenshots.

Is This Required?

Technically? No. You can run without it.

Practically? If your Jellyfin container died tomorrow, could you restore it in under 10 minutes? If not, you need this.

The Budget Reality:

You can run PBS on:

A $150 used mini PC with a 2TB drive
Your NAS if it has extra resources (though I prefer separation)
Even a Raspberry Pi for smaller setups

This is cheap insurance. Way cheaper than rebuilding your entire stack from scratch at 2AM on a work night.

Coming in Part 5: Setting up Proxmox Backup Server, automating backups, and actually testing your restores, so you’re not learning how backups work during a crisis.

TEAMGROUP T-Force Vulcan Z 2TB This is the SSD I use for my Proxmox Backup Server storage. I backup 6 VMs and 12 LXCs, and I’m only at 11% capacity. At this rate I’ll fill it in 3 years. PBS’ deduplication is amazing.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Common Questions

➤ Can I start with just 2 boxes?

Yes. Start with compute + storage, use your existing router. Or start with router + compute, use attached storage temporarily. The point is separation, not perfection. You can grow into the full stack.

➤ What if I already have a Synology?

Perfect. That’s your storage box. You’re already halfway there. Focus on getting a dedicated router and compute box, connect them to your Synology, and you’ve got the stack.

➤ Do I really need to learn Proxmox?

Not technically. You could run Docker on bare metal. But Proxmox gives you isolation, snapshots, easy backups, and the ability to run multiple services without them stepping on each other. The learning curve pays off.

➤ What about power consumption?

Fair question. Three boxes use more power than one. My stack pulls about 100-150W total idle. That’s $10-15/month. The uptime and sanity are worth it, but if you’re power-sensitive, choose efficient hardware (upcoming in the build guides).

➤ Can I use old hardware for this?

Absolutely. Some of the best home servers are built from old office PCs. The next posts will cover budget builds using used hardware alongside new builds for those who want to buy fresh.

What About the Easy Button?

“Can’t I just buy a Synology and run everything there?”

You can. And for some people, that’s the right answer. If you:

Don’t want to learn Linux or networking
Just want it to work out of the box
Don’t mind being locked into Synology’s ecosystem
Are okay with limited customization

Then yes, get a Synology DS925+ or similar, install Jellyfin/Plex, and call it done.

Synology 4-Bay DiskStation DS925+ (Diskless)
Want an easy button? Here you go. The Synology DS925+ can be an OK all in one box. It has enough storage and processing power to run your media services. It will however lack the power to go beyond basic needs.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

But you lose flexibility.

You can’t easily run multiple isolated services.
You can’t experiment without risk.
You can’t scale components independently.
And when it breaks, you’re at Synology’s mercy for support.

This guide is for people who want more control, are willing to learn, and understand that power comes with responsibility (and occasional Googling at 11PM).

Your Growth Path

Phase 1: Get it working

Build all three boxes
Get basic services running (Jellyfin, Sonarr, Radarr)
Verify everything boots reliably

Phase 2: Stabilize and monitor

Add Proxmox Backup Server
Set up proper monitoring (Uptime Kuma, Grafana)
Document your setup (seriously, do this)

Phase 3: Optimize and expand

Add GPU for hardware transcoding
Upgrade to 10GbE networking between boxes
Add more storage as your library grows
Experiment with new services in isolated LXCs

Phase 4: Advanced features

VPN for remote access
Automated media management (Recyclarr, Tdarr)
Advanced monitoring and alerting
Offsite backup replication

You don’t need to do all of this at once. Build the foundation, then grow into it.

The next four posts break down each box in detail: what to buy, what to avoid, and budget vs. dream builds.

Role	Purpose	💰 Budget Range
Router	Traffic control, DNS, VLANs, firewall	$150-$500
Storage	Reliable media storage with redundancy	$400-$1900
Compute	Runs all your apps and services	$200-$1400
Backup	Saves you from disaster	$150-$400

Each box has different needs, different trade-offs, and yes, different price tags. But here’s the thing: you don’t need the dream build to get started. A $900 budget stack works. A $4,200 dream stack works better. Both work way better than cramming everything onto one box and hoping for the best.

Part 2 drops next week: The Router. I’ll show you exactly which hardware to buy, from the $150 AOOSTAR N1 PRO that punches above its weight to the $500+ “final boss” build that handles 10Gbps like it’s nothing. Plus: OPNsense installation, VLAN setup, and the firewall rules that actually matter.

Want to be ready? Start thinking about:

Your budget for each component
What old hardware you might already have
Whether you want to buy used or new
How much redundancy you actually need

And most importantly: what you want to stop babysitting, so you can finally just watch your media in peace.

Mastering UID/GID Mapping in Proxmox LXC Containers

Mon, 20 Oct 2025 07:03:02 -0600

Mastering UID/GID Mapping in Proxmox LXC Containers

If you’ve ever shared files between your Proxmox host and an LXC container and wondered why permissions look “off” or why bind mounts throw permission errors, you’ve already bumped into UID/GID mapping. It’s one of those behind-the-scenes mechanisms that keeps your containers safe and sane, but it can also be the source of confusing file ownership problems.

Understanding UID (User ID) and GID (Group ID) mapping is crucial for anyone running unprivileged containers on Proxmox. It’s what prevents a container’s root from being actual root on the host. It’s also the key to properly mapping shared directories and keeping your security in place.

Here’s the thing: UID/GID mapping sounds intimidating, but once you understand the basic concept, it becomes a powerful tool rather than a mysterious source of frustration. We’ll walk through how it works in Proxmox LXCs, how to customize it when needed, and how to fix the common headaches it causes, especially for media server setups like Jellyfin.

Understanding this mapping helps you avoid the common trap of switching to privileged containers, which sacrifices security for convenience.

💭 TL;DR

Proxmox isolates unprivileged LXC containers by mapping their user and group IDs to high-numbered counterparts on the host, starting at 100000. This security feature prevents container root users from escalating to host root. You can customize these mappings by editing `/etc/pve/lxc/.conf` and adjusting `/etc/subuid` and `/etc/subgid`. Doing so allows seamless file sharing and predictable permissions when bind mounting directories inside containers.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Why UID/GID Mapping Matters

User and group IDs in Linux define ownership and permissions. UID 0 is root, UID 1000 might be your first host user, and so on. Normally, these IDs are global across a single OS instance, but containers complicate that picture. Without remapping, the “root” user inside a container would also be UID 0 on the host. If someone managed to escape that container, they’d have full system privileges.

To solve this, Proxmox defaults to unprivileged containers, where the container’s UID/GID space is remapped to a non-privileged range on the host. Think of it as giving each container its own private numbering system that translates to harmless IDs on the host side.

Visualizing the Mapping

Here’s what happens with default mapping:

Container Namespace          Host System
┌────────────────────┐      ┌──────────────────┐
│ UID 0 (root)       │ ───> │ UID 100000       │
│ UID 1 (daemon)     │ ───> │ UID 100001       │
│ UID 1000 (user)    │ ───> │ UID 101000       │
│ UID 65535 (nobody) │ ───> │ UID 165535       │
└────────────────────┘      └──────────────────┘

With custom mapping for media server access:

Container Namespace          Host System
┌────────────────────┐      ┌──────────────────┐
│ UID 0 (root)       │ ───> │ UID 100000       │
│ UID 999            │ ───> │ UID 100999       │
│ UID 1000 (user)    │ ───> │ UID 1000         │ ← Direct map!
│ UID 1001           │ ───> │ UID 101001       │
└────────────────────┘      └──────────────────┘

Why 100000 as the Starting Point?

Proxmox chose 100000 as the default offset for good reasons:

System UIDs (0-999): Reserved for system services and the root user
User UIDs (1000-60000): Normal user accounts on most Linux systems
Container offset (100000+): Far enough from everything else to avoid conflicts

This ensures that even if you have 99 regular users on your host (UID 1000-1099), their IDs will never collide with container-mapped IDs.

Privileged vs Unprivileged: What You Need to Know

Unprivileged Containers (unprivileged: 1 - Default):

UID/GID mapping is enforced by the kernel
Container root = UID 100000 on host (harmless)
Recommended for 99% of use cases including media servers
Security isolation is maintained even if container is compromised

Privileged Containers (unprivileged: 0):

NO UID/GID mapping
Container root = actual root on host
Major security risk: Container escape = full host compromise
Rarely needed for media servers, avoid unless absolutely necessary

For Jellyfin, Plex, and similar media servers, you should always use unprivileged containers with proper UID mapping. The performance is identical and security is much better.

Understanding the Default Mapping

When you create a new unprivileged LXC container in Proxmox, it automatically sets up UID/GID mappings to keep your container isolated from the host system.

Check your container’s configuration file:

cat /etc/pve/lxc/101.conf

You’ll see something like:

arch: amd64
cores: 2
hostname: jellyfin
memory: 2048
rootfs: local-lvm:vm-101-disk-0,size=8G
unprivileged: 1

That unprivileged: 1 line triggers automatic UID/GID offset mapping defined in /etc/subuid and /etc/subgid on the host.

The Default Mapping Files

Check your host’s subordinate ID files:

cat /etc/subuid
cat /etc/subgid

You’ll see:

root:100000:65536

This means:

Container UID 0 → Host UID 100000
Container UID 1 → Host UID 100001
Container UID 1000 → Host UID 101000
Container UID 65535 → Host UID 165535

This is why your media files show weird ownership! When your Jellyfin container (running as a user inside) creates or accesses files, they appear on the host owned by UIDs in the 100000+ range instead of your normal user account.

MINISFORUM MS-A2 With serious I/O and flexible storage, this mini-workstation is an excellent homelab node for advanced LXC container setups, allowing you to experiment with lxc.idmap and /etc/subgid in a high-performance, space-saving package.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Prerequisites

Before configuring UID/GID mapping, ensure:

You’re running Proxmox VE 7.0 or later
Container is stopped (or not yet created)
You know your host user’s UID (run id on host)
You have root access to Proxmox host
Media files exist on host with known ownership

Step-by-Step: Setting Up UID/GID Mapping for Media Servers

Here’s the practical guide for getting Jellyfin (or Plex, Emby, etc.) working with your media library.

Step 1: Identify Your Host Media Directory Ownership

First, check who owns your media files on the host:

ls -ln /media/movies
ls -ln /media/tv

You’ll see output like:

drwxr-xr-x 10 1000 1000 4096 Oct 20 10:30 /media/movies

The 1000 1000 shows UID and GID. This is typically your primary user account. Remember this number, you’ll need it later.

Step 2: Stop Your Container

If container is already running:

pct stop 101

Skip this step if you’re configuring a new container that hasn’t started yet

Step 3: Edit the Container Configuration

Open the container’s config file:

nano /etc/pve/lxc/101.conf

Add these lines at the end:

lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535
# Our mapping covers exactly 65,536 IDs (0-65535):
# Line 1: 1000 IDs (container 0-999)
# Line 2: 1 ID (container 1000)
# Line 3: 64535 IDs (container 1001-65535)
# Total: 1000 + 1 + 64535 = 65,536 ✓

What this does:

Maps container UIDs 0-999 to host UIDs 100000-100999 (keeps container root isolated)
Maps container UID 1000 directly to host UID 1000 (your user)
Maps container GID 1000 directly to host GID 1000 (your user’s group)
Resumes offset mapping at UID 1001 → host UID 101001 (100000 base + 1001 offset), maintaining security isolation for all remaining users

Save and exit (Ctrl+X, Y, Enter).

Step 4: Add Bind Mounts for Your Media

Add your media directories to the config file (if not already open from Step 3, use nano /etc/pve/lxc/101.conf):

mp0: /media/movies,mp=/media/movies
mp1: /media/tv,mp=/media/tv
mp2: /media/music,mp=/media/music

Or use the command line:

pct set 101 -mp0 /media/movies,mp=/media/movies
pct set 101 -mp1 /media/tv,mp=/media/tv

Step 5: Verify Subordinate UID Files

Check that your host has the necessary UID range:

cat /etc/subuid
cat /etc/subgid

You should see at least:

root:100000:65536

Now edit both files and add this line at the top:

# In /etc/subuid:
root:1000:1

# In /etc/subgid:
root:1000:1

What this means:

Allows the root user (who runs LXC) to map a single ID (1000) directly through to the container
Change 1000 to match your host user’s UID/GID (find it with id command)

Step 6: Start and Configure Container

pct start 101

Enter the container:

pct enter 101

Create or modify the user to match your host UID:

# Check if jellyfin user already exists
id jellyfin 2>/dev/null

# If user doesn't exist yet, create it:
useradd -u 1000 -m jellyfin

# If user already exists with wrong UID, modify it:
usermod -u 1000 jellyfin
usermod -g 1000 jellyfin  # Also update primary group

Step 7: Verify Permissions

Test that Jellyfin can access your media:

su - jellyfin -s /bin/bash
ls -la /media/movies
touch /media/movies/test.txt

If these commands work without “Permission denied” errors, you’re good!

On the host, verify:

ls -ln /media/movies

Remove the test file:

rm /media/movies/test.txt

Files created by Jellyfin should show UID 1000, matching your host user.

Step 8: Configure Jellyfin Libraries

Access Jellyfin’s web interface (usually http://container-ip:8096) and add your media libraries pointing to:

/media/movies
/media/tv
/media/music

Jellyfin should now scan and access everything without permission issues.

Common Media Server Patterns

Pattern 1: Single User Media Library (Most Common)

Use case: All media owned by one user (UID 1000)

lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535
mp0: /media,mp=/media

Pattern 2: Multiple Media Users

Use case: Media owned by different users (UID 1000, 1001, 1002)

lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 3
lxc.idmap: g 1000 1000 3
lxc.idmap: u 1003 101003 64533
lxc.idmap: g 1003 101003 64533
mp0: /media,mp=/media

Troubleshooting Media Server Permission Issues

➤ Problem: Jellyfin Can’t See Media Files

Symptoms: Library scan shows no files or “Permission denied” in logs

Solution:

# Check mapping is active
pct exec 101 -- cat /proc/self/uid_map

# Verify file ownership
pct exec 101 -- ls -ln /media/movies

# Check Jellyfin user UID
pct exec 101 -- id jellyfin

# Ensure they match your mapping

➤ Problem: Can’t Write Subtitles or Metadata

Symptoms: Jellyfin complains about read-only filesystem

Solution:

# Verify mount isn't read-only
cat /etc/pve/lxc/101.conf | grep mp0

# Should NOT have 'ro' option
# Correct: mp0: /media,mp=/media
# Wrong: mp0: /media,mp=/media,ro

# Verify write permissions
pct exec 101 -- su - jellyfin -s /bin/bash -c "touch /media/test.txt"

➤ Problem: Transcoding Fails with Permission Errors

Symptoms: Playback works but transcoding fails

Solution:

# Check transcode directory permissions
pct exec 101 -- ls -ln /var/lib/jellyfin/transcodes

# Should be owned by jellyfin user
pct exec 101 -- chown -R jellyfin:jellyfin /var/lib/jellyfin

# If using host directory for transcoding
pct set 101 -mp1 /fast-storage/transcodes,mp=/transcodes

➤ Problem: Files Show as UID 100000 on Host

Symptoms: Host can’t manage files created by Jellyfin

Solution: Your mapping isn’t working. Go back to Step 3 and verify your lxc.idmap configuration, then restart the container.

GMKtec Mini PC Workstation A compact, powerful barebone system that’s perfect for running Proxmox and multiple LXC containers, making it easy for beginners and enthusiasts to test UID/GID mapping configurations in a real-world homelab environment.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Advanced: Running Multiple Media Servers

If you’re running both Jellyfin and Plex, or want separate containers for different media types:

Strategy: Shared Mapping, Separate Containers

Container 101 (Jellyfin):

lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535
mp0: /media,mp=/media,ro

Container 102 (Plex):

lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535
mp0: /media,mp=/media,ro

Both containers can read the same media library. Use ro (read-only) flag to prevent accidental modifications.

Understanding lxc.idmap Syntax

For those who want to customize beyond these common patterns:

lxc.idmap: [u|g] [first_id_in_container] [first_id_on_host] [number_of_ids]

Example breakdown:

lxc.idmap: u 0 100000 1000

u = UID mapping (use g for GID)
0 = Start at container UID 0
100000 = Map to host UID 100000
1000 = Map 1000 consecutive IDs (0-999)

Critical rules:

You must map all 65536 IDs (0-65535)
No gaps allowed
No overlaps within same container
Order matters. Later lines override earlier ones

FAQs

➤ Will UID mapping slow down my media server?

No. UID mapping happens in the kernel with negligible overhead. Your Jellyfin performance will be identical to a privileged container, but much more secure.

➤ Can I use the same mapping for multiple containers?

Yes. All your media-related containers (Jellyfin, Sonarr, Radarr, etc.) can use the same UID mapping pattern. This makes file sharing between them seamless.

➤ What if my media is owned by a different UID?

Adjust the mapping. If your media is owned by UID 1500 instead of 1000, change:

lxc.idmap: u 1500 1500 1
lxc.idmap: g 1500 1500 1

And adjust the other ranges accordingly to ensure you still map all 65536 IDs.

➤ Do I need to map GID separately from UID?

Yes, if your files rely on group permissions. Most media setups work fine mapping both UID and GID the same way (as shown in the examples).

➤ Can I change mapping on an existing Jellyfin container?

Yes, but be prepared to fix file ownership:

Stop container
Modify mapping in config
Start container
Run chown -R jellyfin:jellyfin /var/lib/jellyfin inside container

Your media files on the host should maintain correct ownership since they’re already owned by your user.

➤ Should I ever use a privileged container for Jellyfin?

No. There’s no legitimate performance or functionality reason to run Jellyfin in a privileged container. Proper UID mapping gives you the same capabilities with vastly better security.

Conclusion: Media Servers and UID Mapping

UID/GID mapping is the key to running secure, functional media servers in Proxmox LXC containers. The default isolation protects your host system, while custom mapping gives you seamless access to media libraries.

Your Media Server Checklist

Identify media directory ownership on host (usually UID 1000)
Configure lxc.idmap to map that UID directly
Add bind mounts for media directories
Create or modify media server user to match mapped UID
Test file access from inside container
Verify host sees correct ownership
Configure media server libraries
Run a scan and test playback

Key Takeaways for Media Servers

Use unprivileged containers always. The security benefit is enormous, and the setup is straightforward once you understand UID mapping.

Map your user UID directly. The single-user passthrough pattern (mapping UID 1000 to 1000) handles 90% of media server scenarios.

Document your setup. Write down which UIDs you mapped and why. You’ll thank yourself during troubleshooting or migration.

Test before going live. Verify file access, transcoding, and metadata writing all work before importing your entire library.

The small investment in understanding UID/GID mapping pays off with a secure, maintainable media server setup that just works.

RaspberryPi 4GB This affordable, energy-efficient single-board computer is perfect for beginners wanting to learn about Proxmox LXC containers and UID/GID mappings in a low-risk, hands-on way.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Sources

How to Install and Configure Tdarr for Media Library Optimization

Sun, 12 Oct 2025 05:44:47 -0600

If you’ve ever looked at your media collection and wondered why a 4K movie is eating up 50GB of storage while looking identical to a 10GB version, you’re ready for Tdarr. This powerful automation tool handles the tedious work of transcoding your video files, converting them to more efficient formats without sacrificing quality you’ll actually notice.

Tdarr isn’t just another media converter. It’s a complete workflow system that watches your library, analyzes your files, and automatically optimizes them based on rules you set. Think of it as having a dedicated assistant who never sleeps, constantly working to make your media collection smaller, more compatible, and easier to stream.

In this guide, I’ll walk through setting up Tdarr from scratch. You’ll learn how to install it and configure your first Intel QuickSync transcoding workflow. By the end, you’ll have a basic understanding on how to keep your media library optimized without any ongoing effort from you.

Intel® Core™ i5-12500 12th Generation Desktop Processor The Intel® Core™ i5-12500 offers strong single-thread performance and built-in Quick Sync hardware transcoding, making it an excellent CPU for running Tdarr and handling multiple concurrent transcodes. It’s ideal for DIY homelab builders who want efficient, reliable media processing without needing a discrete GPU. This processor is a great foundation for a Tdarr server.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

If you manage a large media library, you know the drill: storage fills up fast, and manually transcoding files is about as fun as watching paint dry. This is where Tdarr comes in.

Tdarr is a transcoding and media management tool that handles the grunt work for you. Instead of babysitting HandBrake for hours, you set up rules once and let Tdarr automatically process your entire video collection in the background. It can remove unwanted audio tracks, compress, re-encode, and standardize files based on whatever criteria you define. All in the name of saving space. Hard drives have only gotten more expensive so now is the time to try and save space before adding another expensive hard dirve to your server.

The real game-changer? Distributed transcoding. You can spread the workload across multiple machines, turning that old laptop gathering dust into a transcoding workhorse. Set it up once, let it run, and watch terabytes of space magically reappear without sacrificing playable quality. It’s exactly what Plex, Jellyfin, and Emby users have been waiting for.

💡

Tip: You will need to either have a shared cache folder that the server and ALL of the nodes can access or pay for their pro subscription to setup multiple nodes. This is not covered in this post.

This guide covers will only cover installing, configuring, and troubleshooting Tdarr in an unprivileged LXC container. Whether you’re new to transcoding or haven’t touched it since the early HandBrake days, you’ll walk away with a practical setup that saves both time and storage without the usual headaches.

💭 TL;DR

Tdarr automates the tedious job of transcoding and optimizing your media library using flexible, customizable rules. Install it, set up your transcoding preferences through a clean web interface, and optionally scale it across multiple machines for distributed processing. It's particularly valuable for Jellyfin or Plex server owners and anyone looking to reclaim storage space by converting files (like moving from H.264 to H.265) while maintaining quality.

Why LXC Instead of Docker?

You might be wondering why this guide uses LXC containers instead of Docker, especially since most Tdarr tutorials out there are Docker-based. Here’s the reasoning behind this approach:

Direct Hardware Access

LXC containers run closer to the host system than Docker containers. When you’re sharing an iGPU between multiple services (like Jellyfin and Tdarr), LXC makes hardware passthrough significantly more straightforward. You get:

Simpler GPU sharing: The iGPU can be accessed by multiple LXC containers simultaneously without complex device mapping or privileged modes
Native performance: LXC containers have almost zero overhead compared to bare metal, making them ideal for transcoding workloads
Persistent hardware access: The GPU stays available even after container restarts without additional Docker flags or volume mounts

Resource Isolation Without the Overhead

Docker adds multiple layers of abstraction that aren’t necessary for long-running services like Tdarr. LXC gives you:

Lower memory footprint: No Docker daemon consuming resources in the background
Direct systemd integration: Services start and stop like native system services
Filesystem efficiency: No overlay filesystems slowing down video file I/O operations

Better Integration with Proxmox

If you’re running Proxmox (which most homelabbers are), LXC is first-class:

Native Proxmox management: Create, clone, and backup containers through the web UI
Snapshot support: Take instant snapshots before major configuration changes
Built-in monitoring: Resource usage graphs and stats without installing additional tools
No nested virtualization issues: Docker-in-VM can be problematic; LXC just works

When Docker Makes More Sense

Docker isn’t wrong—it’s just optimized for different use cases:

Portability: If you need to move Tdarr between different hosts frequently, Docker’s image format makes this trivial
Quick testing: Spinning up and destroying Docker containers is faster for experimentation
No Proxmox: If you’re running on bare Ubuntu/Debian without Proxmox, Docker is simpler to set up

For a dedicated media server running on Proxmox where you want maximum transcoding performance and are already sharing GPU resources with other services, LXC is the better architectural choice. You get native performance, simpler hardware access, and better integration with your virtualization platform—all while using fewer system resources.

Understanding Tdarr and Why It Matters

Before we start spinning up containers and tweaking codec settings, let’s get clear on what Tdarr actually does. And more importantly, what it doesn’t do.

What Is Tdarr?

Tdarr is a conditional transcoding application. It looks at each video file in your library, runs it through a set of rules you define (like “Is this still using H.264?” or “Is the bitrate ridiculously high?”), and then decides whether to transcode it, leave it alone, or skip it entirely.

Picture Tdarr as a quality control inspector on an assembly line. Each file gets examined, processed if needed, and passed along based on the standards you’ve set. Behind the scenes, it leverages proven tools like FFmpeg and HandBrake to do the heavy lifting, so you get reliable performance and industry-standard compression without having to become a command-line wizard.

Why Use Tdarr?

Here’s why I swear by Tdarr:

Storage Efficiency: Convert those space-hogging H.264 or MPEG-2 files to modern H.265 (HEVC) and watch your storage usage drop by up to 50% without sacrificing watchable quality.
Uniform Playability: Standardize your codecs and container formats so everything plays smoothly across Plex, Jellyfin, smart TVs, and mobile apps. No more “this format is not supported” messages.
Set-and-Forget Automation: Configure your preferences once, and Tdarr handles the monitoring, processing, and updating automatically. Your media library maintains itself.
Scalability: Add multiple worker nodes for distributed transcoding when you need to process hundreds or thousands of files without waiting weeks.

If you’ve ever watched Jellyfin refuse to play an unsupported codec, or wondered why your server storage is maxed out despite regular cleanup, Tdarr solves both problems for the long haul.

Seagate Barracuda 24TB Internal Hard Drive A large-capacity hard drive like the Seagate Barracuda 24TB is crucial for storing your growing media library and transcoded files managed by Tdarr. Its reliability and size make it perfect for bulk storage in a homelab or media server environment. This drive ensures you have plenty of space for all your media needs.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Step 1: Installing Tdarr via Unprivileged LXC

Why an LXC? Because I’m sharing my iGPU with Jellyfin who is also installed in an LXC.

My Jellyfin guide:
Jellyfin + Intel QuickSync in Unprivileged LXC - The Complete Guide

Prerequisites Checklist

Before starting, ensure you have:

Proxmox VE with an unprivileged LXC running Debian 13
Intel CPU with QuickSync (12th gen or newer recommended)
Basic command-line familiarity
Network access to your LXC container
Media files stored on your Proxmox host with known paths
At least 8GB RAM allocated to the LXC

Add the Debian Non-Free Component

sudo nano /etc/apt/sources.list.d/debian.sources

On the components line add non-free to the end.

Types: deb
URIs: http://deb.debian.org/debian
Suites: trixie trixie-updates
Components: contrib main non-free
Signed-By: /usr/share/keyrings/debian-archive-keyring.gp

Add a new source for MKVToolNix

Pull the gpg key:

wget -O /etc/apt/keyrings/gpg-pub-moritzbunkus.gpg https://mkvtoolnix.download/gpg-pub-moritzbunkus.gpg

Create a new source File:

sudo nano /etc/apt/sources.list.d/mkvtoolnix.sources

Paste this:

Types: deb
URIs: https://mkvtoolnix.download/debian/
Suites: trixie
Components: main
Signed-By: /etc/apt/keyrings/gpg-pub-moritzbunkus.gpg

Install HandBrake, ffmpeg, MKVtoolNix and other required tools

sudo apt update && sudo apt install -y sudo curl unzip ca-certificates gnupg wget vainfo libva2 intel-media-va-driver-non-free libva-drm2 libva2 pciutils handbrake-cli ffmpeg mkvtoolnix

💡

Tip: I install ffmpeg and handbrake outside of Tdarr because I find it is easier to maintain.

Add Users and Groups

Create your media group that has read and write access to your media files. I use media with a gid of 1001 for mine make sure to use yours if it is different.

sudo addgroup --gid 1001 media

Create the Tdarr User:

sudo useradd -r -m -d /opt/tdarr -s /usr/sbin/nologin tdarr

Add the video, render and media groups to the Tdarr user:

sudo usermod -aG render,video,media tdarr

Reset the group membership without logging out:

sudo loginctl enable-linger tdarr 2>/dev/null || true

Step 2: LXC Config Changes

Stop the container. Add these lines to your /etc/pve/lxc/CT#.conf

# Bind mounts your media to the LXC
mp0: /media/Storage/Movies,mp=/media/Movies
mp1: /media/Storage/Shows,mp=/media/Shows
# Maps permissions to the host
lxc.idmap: u 0 100000 65536
lxc.idmap: g 0 100000 992
lxc.idmap: g 992 104 1 # 992 is the LXC's Render GID and 104 is the Host's
lxc.idmap: g 993 100994 7
lxc.idmap: g 1001 1001 1 # 1001 is both the LXC's and Host's GID for my media group
lxc.idmap: g 1002 101002 64534
# Passthrough the iGPU
lxc.mount.entry: /dev/dri/ dev/dri/ none bind,optional,create=dir
lxc.cgroup2.devices.allow: c 226:* rwm

Here is my Host’s /etc/subgid file:

root:1000:1
root:1001:1
root:100000:65536
# Render Group
root:104:1
# Media Group
root:1001:1

These lines need to be in here to properly map the GIDs for permissions to work properly. Restart the container.

💡

Tip: Understanding ID Mapping - These lxc.idmap lines map user and group IDs between your LXC container and the Proxmox host. This allows the tdarr user inside the container to access your media files and the GPU on the host. The numbers (992, 1001, etc.) must match your specific system. If you’re unfamiliar with LXC ID mapping, check out Unprivileged LXC containers first.

Step 3: Install Tdarr

Now we are ready to install Tdarr

Navigate to /opt/tdarr:

cd /opt/tdarr

Pull the Tdarr install script:

wget https://storage.tdarr.io/versions/2.17.01/linux_x64/Tdarr_Updater.zip

Unzip the install package:

unzip Tdarr_Updater.zip

Create two additional directories for Tdarr’s temporary files and cache:

mkdir temp cache

Make the script executable:

sudo chmod +x Tdarr_Updater

Run the installer:

sudo ./Tdarr_Updater

💡

Tip: Run groups tdarr and verify you see: tdarr video render media

Inital Tdarr Run

Initial Run of Tdarr_Server:

/opt/tdarr/Tdarr_Server/Tdarr_Server

Let this run for a minute or so. Errors are fine for now. We are just creating the JSON config file.

Initial run of Tdarr_Node:

/opt/tdarr/Tdarr_Node/Tdarr_Node

Again errors are fine.

Now set the owner for the Tdarr folders:

sudo chown -R tdarr:tdarr /opt/tdarr/

Tdarr Server JSON Config

You now have a basic config file for the server. We need to set the serverIP, handbrakePath, and ffmpegPath

nano /opt/tdarr/configs/Tdarr_Server_Config.json

After modifying, it should look something like this:

{
  "serverPort": "8266",
  "webUIPort": "8265",
  "serverIP": "172.27.0.14",
  "serverBindIP": false,
  "serverDualStack": false,
  "handbrakePath": "/usr/bin/HandBrakeCLI",
  "ffmpegPath": "/usr/bin/ffmpeg",
  "logLevel": "INFO",
  "mkvpropeditPath": "",
  "ccextractorPath": "",
  "openBrowser": true,
  "cronPluginUpdate": "",
  "auth": false,
  "authSecretKey": "tsec_NotARealKey",
  "maxLogSizeMB": 10,
  "seededApiKey": ""
}

Tdarr Node JSON Config

open the basic config file. We need to set serverURL, ServerIP, handbrakePath, ffmpegPath, and mkvpropeditPath

nano /opt/tdarr/configs/Tdarr_Node_Config.json

After modifying, it should look something like this:

{
  "nodeName": "jaded-joey",
  "serverURL": "http://172.27.0.14:8266",
  "serverIP": "172.27.0.14",
  "serverPort": "8266",
  "handbrakePath": "/usr/bin/HandBrakeCLI",
  "ffmpegPath": "/usr/bin/ffmpeg",
  "mkvpropeditPath": "/usr/bin/mkvpropedit",
  "pathTranslators": [
    {
      "server": "",
      "node": ""
    }
  ],
  "nodeType": "mapped",
  "unmappedNodeCache": "/opt/tdarr/unmappedNodeCache",
  "logLevel": "INFO",
  "priority": -1,
  "cronPluginUpdate": "",
  "apiKey": "",
  "maxLogSizeMB": 10,
  "pollInterval": 2000,
  "startPaused": false
}

Create Tdarr Services

To make sure it starts automatically we need to create two services. One for the server and one for the node.

Server

sudo nano /etc/systemd/system/tdarr-server.service

Paste this:

[Unit]
Description=Tdarr Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=tdarr
Group=tdarr
WorkingDirectory=/opt/tdarr/Tdarr_Server
Environment=TDARR_DATA=/opt/tdarr/configs
Environment=TDARR_LOGS=/opt/tdarr/logs
ExecStart=/opt/tdarr/Tdarr_Server/Tdarr_Server
Restart=on-failure
# Resource limits (tune as desired)
CPUAccounting=true
MemoryAccounting=true
CPUQuota=100%
MemoryMax=2G

[Install]
WantedBy=multi-user.target

Node

sudo nano /etc/systemd/system/tdarr-node.service

Paste this (Make sure to change the TDARR_SERVER_HOST to your IP):

[Unit]
Description=Tdarr Node
After=tdarr-server.service
Wants=tdarr-server.service

[Service]
Type=simple
User=tdarr
Group=tdarr
WorkingDirectory=/opt/tdarr/Tdarr_Node
Environment=TDARR_NODE_NAME=tdarr-node-01
Environment=TDARR_SERVER_HOST=172.27.0.14
Environment=TDARR_FFMPEG=/usr/bin/ffmpeg
Environment=TDARR_LOGS=/opt/tdarr/logs
Environment=TDARR_TEMP=/opt/tdarr/temp
Environment=TDARR_CACHE=/opt/tdarr/cache
ExecStart=/opt/tdarr/Tdarr_Node/Tdarr_Node
Restart=on-failure
# Resource limits (tune as desired)
CPUAccounting=true
MemoryAccounting=true
CPUQuota=150%
MemoryMax=6G
IOSchedulingClass=best-effort
IOSchedulingPriority=7

[Install]
WantedBy=multi-user.target

Enable and Start the new Services

sudo systemctl daemon-reload
sudo systemctl enable tdarr-server
sudo systemctl start tdarr-server
sudo systemctl enable tdarr-node
sudo systemctl start tdarr-node

Check the status of the services to make sure they are running:

Server

sudo systemctl status tdarr-server

Should look like this:

* tdarr-server.service - Tdarr Server
     Loaded: loaded (/etc/systemd/system/tdarr-server.service; enabled; preset: enabled)
     Active: active (running) since Wed 2025-10-15 11:15:48 MDT; 1 day 20h ago
 Invocation: 5adc45d529564e898b9e51e29917de75
   Main PID: 7535 (Tdarr_Server)
      Tasks: 21 (limit: 76615)
     Memory: 281.5M (max: 2G, available: 1.7G, peak: 2G, swap: 31.6M, swap peak: 38.3M)
        CPU: 42min 13.105s
     CGroup: /system.slice/tdarr-server.service
             |-7535 /opt/tdarr/Tdarr_Server/Tdarr_Server
             `-7541 Tdarr_Server

Node

sudo systemctl status tdarr-node

Should look like this:

* tdarr-node.service - Tdarr Node
     Loaded: loaded (/etc/systemd/system/tdarr-node.service; enabled; preset: enabled)
     Active: active (running) since Wed 2025-10-15 11:44:19 MDT; 1 day 20h ago
 Invocation: 40a1033a1c984181a6f4c4c399398d4b
   Main PID: 8673 (Tdarr_Node)
      Tasks: 187 (limit: 76615)
     Memory: 2.7G (max: 6G, available: 3.2G, peak: 6G, swap: 11.3M, swap peak: 184.3M)
        CPU: 5h 37min 41.929s
     CGroup: /system.slice/tdarr-node.service

Step 4: Testing QuickSync

Before we go any further we need to make sure QuickSync is working.

Run this quick test

sudo -u tdarr env LIBVA_DRIVER_NAME=iHD \
  vainfo --display drm --device /dev/dri/renderD128 | head -n 60

➤ Expected Results


libva info: VA-API version 1.22.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
Trying display: drm
vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 25.2.3 ()
vainfo: Supported profile and entrypoints
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileNone                   : VAEntrypointStats
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointFEI
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointFEI
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointFEI
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointFEI
      VAProfileHEVCMain               : VAEntrypointEncSliceLP
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointEncSliceLP
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointEncSliceLP
      VAProfileVP9Profile1            : VAEntrypointVLD
      VAProfileVP9Profile1            : VAEntrypointEncSliceLP
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointEncSliceLP
      VAProfileVP9Profile3            : VAEntrypointVLD
      VAProfileVP9Profile3            : VAEntrypointEncSliceLP
      VAProfileHEVCMain12             : VAEntrypointVLD
      VAProfileHEVCMain12             : VAEntrypointEncSlice
      VAProfileHEVCMain422_10         : VAEntrypointVLD
      VAProfileHEVCMain422_10         : VAEntrypointEncSlice
      VAProfileHEVCMain422_12         : VAEntrypointVLD
      VAProfileHEVCMain422_12         : VAEntrypointEncSlice
      VAProfileHEVCMain444            : VAEntrypointVLD
      VAProfileHEVCMain444            : VAEntrypointEncSliceLP
      VAProfileHEVCMain444_10         : VAEntrypointVLD
      VAProfileHEVCMain444_10         : VAEntrypointEncSliceLP
      VAProfileHEVCMain444_12         : VAEntrypointVLD
      VAProfileHEVCSccMain            : VAEntrypointVLD
      VAProfileHEVCSccMain            : VAEntrypointEncSliceLP
      VAProfileHEVCSccMain10          : VAEntrypointVLD
      VAProfileHEVCSccMain10          : VAEntrypointEncSliceLP
      VAProfileHEVCSccMain444         : VAEntrypointVLD
      VAProfileHEVCSccMain444         : VAEntrypointEncSliceLP
      VAProfileAV1Profile0            : VAEntrypointVLD

If you see Driver version: Intel iHD driver for Intel(R) Gen Graphics - 25.2.3 it is working and we can move on to installing Tdarr.

ℹ️

Info: Performance Expectations - With Intel QuickSync enabled, a typical 2-hour 1080p movie (H.264 to H.265) transcodes in 15-30 minutes depending on your CPU generation. Without hardware acceleration, the same file could take 2-4 hours. If transcodes are taking longer than expected, verify QuickSync is actually being used by checking GPU utilization: intel_gpu_top

Step 5: Access the web interface & Initial Configuration Walkthrough

Open your browser and navigate to: http://YourServerIP:8265.
The Tdarr dashboard should greet you, ready for configuration.

If it opens CONGRATULATIONS! you have Tdarr up and running.

⚠️

Warning: Security Consideration - Tdarr’s web interface (port 8265) has no authentication enabled by default in this configuration. If your server is exposed to the internet, either enable authentication in /opt/tdarr/configs/Tdarr_Server_Config.json by setting "auth": true and configuring credentials, or restrict access using your firewall. For local network-only use, this isn’t a concern.

When you first access Tdarr, you’ll see the main dashboard with several tabs across the top. Here’s what to do first:

Verify Your Node is Connected

Look for the Nodes section on the main page
You should see your node listed (named something like “jaded-joey”)
Click on the node name to see detailed stats

If your node isn’t showing up:

Double-check the node service is running: sudo systemctl status tdarr-node
Verify the serverIP matches in both JSON configs
Check the logs: sudo journalctl -u tdarr-node -f

This is what it should look like:

Configure Hardware Acceleration

Before adding libraries, make sure Tdarr knows to use QuickSync:

Click on your node in the Nodes tab
Scroll down to Transcode Options
Under Hardware Encoding, select “Any (nvenc,qsv,vaapi)”
Save the changes

This ensures Tdarr uses your iGPU instead of hammering your CPU.

ASRock Intel ARC A380 Challenger The ASRock Intel ARC A380 Challenger provides modern hardware transcoding support (AV1/HEVC/H.264), which is essential for efficient and fast media processing in Tdarr. Offloading transcoding tasks from your CPU, it ensures smooth operation and maximizes your server’s performance. It’s a cost-effective way to boost your Tdarr setup for self-hosted media servers.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Step 6: Getting Comfortable With Tdarr

Now for the fun part: Tdarr’s web dashboard is your command center for everything media transcoding. The interface is refreshingly straightforward, organized into four main sections that actually make sense:

Libraries: Tell Tdarr which folders to watch and process
Transcode Settings: Set up your conversion rules and choose plugins
Nodes: Monitor your transcoding workers (yes, you can run multiple)
Logs: Watch the real-time activity feed and catch any hiccups

Setting Up Your First Library

Time to point Tdarr at your media collection. This is where those bind mount mappings from earlier pay off:

In the sidebar, click Libraries → Add Library.
Give it a descriptive name like “Movies” or “TV Shows” (you’ll thank yourself later).
Set the folder path to match what you mapped in your LXC (like /media/Movies).
Set the library type to “Video.”
Click Save.

Tdarr immediately starts scanning that directory, cataloging every video file it finds. Depending on your collection size, this initial scan might take a few minutes, but you’ll see the progress in real time through the logs.

Step 7: Defining Transcoding Rules

Here’s where Tdarr gets interesting. Rules are the brain of your operation: they decide which files get processed and how. Think of them as your personal media assistant that never sleeps.

Creating Conditional Rules

Every rule follows a simple IF → THEN logic. If a file meets certain conditions, Tdarr takes a specific action. For example:

Condition: File codec is H.264
Action: Transcode to H.265

Setting this up is straightforward:

Navigate to the Plugins & Settings menu.
Add a new plugin chain for your library.
Select relevant plugins (e.g., “Transcode using FFmpeg to H.265”).
Adjust plugin parameters like bitrate or CRF (Constant Rate Factor) for quality control.
Add pre-check plugins like “Skip file if already H.265” to avoid unnecessary work.

Once configured, Tdarr automatically queues any file that doesn’t meet your requirements for conversion. No more manual checking or guesswork.

Choosing the Right Codec and Container

Your codec and container choices should match where you actually watch your content. There’s no point optimizing for mobile if you’re streaming to a 65-inch TV.

Playback Environment	Recommended Codec	Container	Notes
Plex / Jellyfin	H.265 (HEVC)	MKV or MP4	Widely supported, efficient
Direct-to-TV	H.264 (AVC)	MP4	Safest, but larger size
Mobile	H.265	MP4	Excellent compression
Archival Storage	H.265 + 10-bit	MKV	High quality, smaller storage

For most home server setups, H.265 MKV hits the sweet spot: great compression, broad compatibility, and future-proof enough that you won’t be doing this again next year.

A Practical Example: H.264 to H.265 Conversion

Let’s walk through setting up a real transcoding rule. This example converts H.264 files to H.265 while maintaining quality:

Navigate to Libraries and select your library
Click Transcode Options → Plugin Stack
In the Pre-Processing section, add:
- Check if file is H264 (this filters which files to process)
In the Transcode section, add:
- Transcode using FFmpeg - H265 QuickSync
Configure the plugin settings:
- CRF: Set to 23 (good balance of quality/size)
- Preset: Use “medium”
- Hardware Acceleration: Enabled
In Post-Processing, add:
- Check file health (validates the transcode worked)
Click Save Plugin Stack

Now Tdarr will automatically:

Scan your library for H.264 files
Transcode them to H.265 using your iGPU
Verify the output is valid
Replace the original file (or keep both, depending on your settings)

Here is what I’m currently using:

Start with one folder to test before applying this to your entire library.

Monitoring Your Transcodes

Once you’ve set up your rules, here’s how to track what’s happening:

Check the Queue:

Go to Transcode → Queue to see pending files
The queue shows how many files are waiting and their estimated completion time

Watch Active Transcodes:

Click the Staging tab to see files currently being processed
You’ll see real-time stats: current FPS, progress percentage, and time remaining

Review Completed Files:

The Transcode → History tab shows finished jobs
Look for the “Healthy” status to confirm successful transcodes
Check the space savings column to see how much storage you’ve reclaimed

💡

Tip: Keep the logs open in a second browser tab (sudo journalctl -u tdarr-node -f in terminal) to catch any errors early.

Step 8: Verifying Output Quality

Here’s the thing about Tdarr: it’ll happily transcode your entire library without questioning whether the results actually look good. Quality control is entirely on you, which means you need to define what “acceptable” means for your setup.

Options for Quality Verification

Visual spot-checking: Grab a few random transcoded videos and watch them side-by-side with the originals. Your eyes are still the best quality detector.
Bitrate inspection: Fire up MediaInfo or similar tools to verify the output bitrate and codec specs match what you configured.
Plugin-based checks: Some community plugins can automate verification by comparing resolution, color depth, or other metrics before marking a transcode as complete.

If your output quality isn’t hitting the mark, start by tweaking your CRF value. Remember: lower CRF means higher quality but larger file sizes. You can also adjust bitrate ceilings if you’re using constant bitrate encoding instead.

The key is finding that sweet spot between file size savings and visual quality that works for your library and viewing habits.

Sparkle Intel Arc B580 Titan A midrange Battlemage card with 12GB GDDR6 and a tri-fan TORN 2.0 cooler that punches hard at 1080p–1440p, plus full-stack media engines (AV1/HEVC/H.264 encode/decode) that make it great for gaming rigs or Plex/Jellyfin transcoding. Outputs include HDMI 2.1 and DP 2.1 with support for up to four displays.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Step 9: Common Pitfalls & How to Avoid Them

Even with the best setup, Tdarr can throw you some curveballs. Here are the mistakes that trip up most people and how to dodge them:

Pitfall	Description	Solution
Missing codecs	FFmpeg plugins fail due to missing libraries	Use official FFmpeg installations
Slow transcoding	Low CPU or using software encoding	Enable hardware acceleration if supported (e.g., Intel Quick Sync, NVIDIA NVENC)
Files not being processed	Rule misconfiguration	Double-check rule logic (“if already H.265” can skip intended files)
Node not connecting	Firewall or wrong IP	Verify `Tdarr_ServerIP` and matching port (8266)
No storage gain	Using generous bitrate	Lower CRF or target bitrate levels in transcoding profile

The “files not being processed” issue deserves special attention. I’ve seen people scratch their heads for hours because they set up a rule that says “skip if already H.265” but then wonder why their H.265 files aren’t getting processed. The rule is doing exactly what you told it to do.

💡

Tip: Test incrementally. Always run Tdarr on a small library first (like your “Short Clips” folder) before letting it loose on terabytes of data.

This isn’t just good advice, it’s essential. Nothing quite compares to watching Tdarr churn through your entire movie collection only to discover you misconfigured something fundamental. Start small, verify everything works, then scale up.

Troubleshooting Tdarr

Even the best Tdarr setup will occasionally throw you a curveball. Here are the most common issues you’ll encounter and how to fix them without losing your sanity:

Problem 1: “Plugin failed” messages

When plugins refuse to cooperate, it’s usually one of these culprits:

Possible causes:

Syntax errors in parameters
Missing dependency
FFmpeg unable to read specific container types

Fix:

Update to the latest Tdarr first. Half the time, someone already fixed your problem.
Double-check plugin settings against the FFmpeg syntax.
Try another plugin (e.g., HandBrake-based instead of FFmpeg).

Problem 2: Transcodes crawling along at glacial speed

Nothing kills enthusiasm like watching a 2-hour movie take 8 hours to transcode.

Possible causes:

Software-only encoding (your CPU is doing all the heavy lifting)
High CRF (quality) or filters causing slowdowns
Storage bottleneck from slow I/O

Fix:

Ensure your hardware acceleration for your iGPU is working.
Test with a higher CRF number or skip extra filters temporarily.

Problem 3: Quality looks terrible

Fix:

Lower your CRF value (e.g., from 28 to 23). Lower numbers mean better quality.
Use two-pass encoding for higher fidelity when quality matters most.
Make sure you’re not transcoding already compressed H.265 files again unnecessarily. That’s like photocopying a photocopy.

FAQs About Tdarr

➤ What is the primary purpose of Tdarr?

Tdarr automates the tedious work of media management by transcoding your files according to rules you set up once and forget about. Think of it as your personal media librarian that standardizes formats, shrinks file sizes, and makes sure everything plays nicely across all your devices [Tdarr Docs].

➤ How does Tdarr handle distributed transcoding?

Tdarr supports multi-node distributed transcoding, which is a fancy way of saying it can use multiple computers at once. Each node connects to your main Tdarr server and grabs jobs from the queue, processing them in parallel. This lets you throw more hardware at big libraries and actually see the transcoding finish before you retire.

➤ Can Tdarr be used with Jellyfin or Plex?

Absolutely. Tdarr and Plex work together like peanut butter and jelly. Use Tdarr to preprocess your entire library, ensuring every video file meets Plex’s supported codec and container requirements. When Plex streams your content, it can serve files directly without burning CPU cycles on real-time transcoding. Your server stays cool, your electricity bill stays reasonable, and your family stops complaining about buffering.

➤ How do I verify the quality of transcoded files?

Here’s the thing: Tdarr doesn’t judge quality for you. It just follows orders. You’ll need to use community verification plugins or do some manual spot-checking by playing back sample files and comparing metadata. A good practice is to transcode a few test files first and make sure you’re happy with the results before unleashing Tdarr on your entire collection.

➤ What are common transcoding options?

The most popular move is converting H.264 to H.265 (also called HEVC). This typically cuts file sizes by 30-50% while keeping the visual quality nearly identical. Other useful rules include converting audio tracks from DTS to AAC for better device compatibility, especially if you have mobile devices or streaming sticks that get picky about audio formats.

Conclusion

Tdarr is one of those rare tools that, once set up, silently makes your digital life better. By combining automation, compression efficiency, and extensibility, it turns the painful, time-consuming process of media re-encoding into a set-it-and-forget-it workflow.

For media server owners, especially those running Plex or Jellyfin, Tdarr doesn’t just save time: it saves terabytes. Whether you want to reclaim disk space, reduce network stress, or enjoy smoother playback across all devices, Tdarr’s rules-based automation and distributed transcoding give you a scalable, future-proof solution.

If you’ve been putting off optimizing your library because transcoding sounds like a weekend-killing chore, try Tdarr through an LXC this weekend. You’ll be amazed how much cleaner and lighter your media setup feels by Monday.

Next Steps

Explore Tdarr’s official documentation for advanced plugin scripting.
Consider integrating hardware acceleration for maximum speed.
Dive into creating complex workflows to manage your media.
Join the Tdarr community forum to exchange plugin recipes and troubleshooting tips.

The Complete Guide to Securing SSH on Your Server

Wed, 17 Sep 2025 11:15:50 -0600

If you manage a Linux server, chances are you use SSH to connect. Attackers are aware of this as well. As soon as port 22 is open to the internet, bots will start trying to break in with brute-force login attempts. I have seen servers get thousands of these attempts just hours after going online.

Weak passwords, outdated cryptography, or careless configurations can transform these attempts from a nuisance to a nightmare. Data breaches, ransomware, or your server becoming a launching pad for other attacks are all real possibilities when your SSH security falls short.

This is why securing SSH should be a top priority, not something you put off. It is one of the most important first steps in making any server safer. The best part is that with just a few configuration changes, you can greatly reduce your risk and make it very hard for attackers to get in.

By the end of this guide, you will be ready to apply these steps and secure your SSH setup right away. Take action on each recommendation as you read to strengthen your server’s defenses.

💭 TL;DR

Ditch password authentication for SSH keys, lock down root access, tighten your SSH configuration, set proper file permissions, deploy tools like Fail2ban for brute-force protection, and keep an eye on your logs. If SSH must be internet-facing, layer on additional protection with VPNs.

Protectli FW6C/FW6D This fanless firewall appliance is designed for pfSense and OPNsense, providing strong SSH security for homelabs or media servers exposed to the internet. With Intel NICs and hardware AES-NI, it delivers fast, secure routing and supports robust firewall rules, meeting SSH security best practices. It is recommended for anyone looking to secure remote access.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Step 1: Generate a Secure SSH Key Pair

Password authentication over SSH is like leaving your house key under the doormat. Sure, it works, but every bot on the internet is happy to spend all day guessing your password. Key-based authentication, on the other hand, is practically unbreakable when you use modern algorithms.

To setup key-based authentication, you will need to create the keys. This works on Linux and Windows.

Run this on your client machine to create the key pair:

ssh-keygen -t ed25519

The ed25519 algorithm generates keys that are both smaller and more secure than the older RSA standard. If you’re stuck on an older system that doesn’t support ed25519, fall back to this:

ssh-keygen -t rsa -b 4096

This command creates two files: a private key (which you guard with your life) and a public key (which you can share freely). By default, both keys land in your repesctive .ssh folder (~/.ssh/ on Linux and C:\Users\UserName\.ssh on windows).

💡

Tip: Always set a passphrase on your private key. It’s your last line of defense if someone gets physical access to your laptop or workstation.

Step 2: Deploy Your Public Key to the Server

Now you need to tell the server to trust your public key.

Automatic method (the easy way):

ssh-copy-id user@server_address

This command does all the heavy lifting for you. It copies your public key and adds it to the right place on the server.

Manual method (when you want control):

Copy the contents of your ~/.ssh/id_ed25519.pub file
Append it to the server’s ~/.ssh/authorized_keys file

Here’s the thing: your first login will still need your password because the server hasn’t seen your key yet. But once this setup is complete, you can disable password authentication entirely. After this, your server will be more secure, and you’ll never have to remember another password for SSH access.

MINISFORUM MS-A2 With powerful networking (dual 10GbE SFP+ and dual 2.5GbE), this mini-workstation is perfect for running secure SSH servers and experimenting with advanced SSH configurations in a homelab environment. Its flexible storage and high performance make it a great platform for learning and implementing SSH key authentication and best practices. Ideal for both beginners and advanced users looking to build powerful servers in a compact unit.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Step 3: Secure the SSH Configuration

The real power of SSH security lies in its configuration file at /etc/ssh/sshd_config. This is where you harden your SSH entry point, raising the bar high enough that attackers will abandon their efforts and seek softer targets instead.

Open it with:

sudo nano /etc/ssh/sshd_config

Here are the most important changes that harden your SSH setup:

Disable password authentication
This kills brute force attacks dead in their tracks.

PasswordAuthentication no

⚠️

Warning: Test your key-based login in a separate terminal session before making this change. Getting locked out of your own server is embarrassing and fixable, but requires console access.

Disable root login
Never let root log in directly through SSH. Log in as your regular user and escalate with sudo when needed.

PermitRootLogin no

Change the SSH port (optional)
Moving off port 22 cuts down on automated bot noise, though it won’t stop a determined attacker.

Port 2222

If you change this, remember to update your firewall rules accordingly.

Enforce modern encryption
Force SSH to use strong ciphers and message authentication codes, preventing fallback to weaker algorithms.

Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256,hmac-sha2-512

Restrict user access
Limit SSH access to specific users or groups instead of allowing everyone:

AllowUsers youruser

After making these changes, restart the SSH service to apply them:

sudo systemctl restart ssh

Your SSH configuration is now significantly more secure than the defaults. These settings create multiple layers of protection that work together to prevent unauthorized access.

Step 4: Set Correct File Permissions

SSH has strong opinions about file permissions, and it’s not shy about letting you know when they are wrong. If your .ssh directory or files are too permissive, SSH will flat-out refuse to use them. Think of it as SSH’s way of protecting you from yourself.

Here are the correct permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys

Breaking this down:

700 on the .ssh directory means only you can read, write, or enter it
600 on private keys means only you can read or write them
644 on the public key allows others to read it (which is fine, it’s public after all)
600 on authorized_keys keeps it private to your account

If you’re getting “bad owner or permissions on .ssh/config” errors, these permission settings will almost certainly fix the problem. SSH is particular about security, but once you get the permissions right, it’ll work reliably.

RaspberryPi 4GB The Raspberry Pi 4GB is an affordable, low-power option for learning and practicing SSH hardening techniques in a real-world environment. It’s perfect for beginners who want to set up secure remote access, experiment with public/private key authentication, and test firewall rules before deploying them on larger servers. Its versatility makes it a staple for any homelab enthusiast focused on security.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Step 5: Harden Network Access

Congratulations! Your SSH service is now using keys and more secure settings. But if attackers can reach it from anywhere on the internet, you still need more barriers. Think of it like having a great lock on your front door but leaving avalible for anyone to knock on.

Firewalls
Limit SSH access to specific IPs where possible. This is your first line of defense. Example using UFW (Uncomplicated Firewall):

sudo ufw allow from 203.0.113.10 to any port 2222

VPN or Bastion Host
Place SSH behind a VPN. This will prevent the whole internet from probing all your machines. Only machines that are on the VPN can see the host.

Fail2ban
This tool scans logs and automatically bans IPs showing malicious behavior, like repeated failed login attempts. On Debian/Ubuntu:

sudo apt install fail2ban

Then configure /etc/fail2ban/jail.local for sshd. Even if you’ve disabled passwords, Fail2ban still helps block port scanning noise and keeps your logs cleaner. It’s like having a bouncer who remembers troublemakers and won’t let them back in.

➤ A good Fail2Ban Starting Config for SSHD

[DEFAULT]
# Whitelist: your trusted networks and admin IPs that should never be banned.
# Replace the placeholders with your real IPs/subnets.
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24 10.0.0.0/24

# How long to ban an offender (and enable incremental bans).
bantime = 1h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1w

# How far back to count failures, and how many failures trigger a ban.
findtime = 10m
maxretry = 5

# Use the systemd journal for log parsing.
backend = systemd

# Use nftables if your distro uses it. Fall back to iptables if needed.
banaction = nftables-multiport

# -----------------------------------
# SSH JAIL
# -----------------------------------
[sshd]
enabled = true
filter  = sshd

# If you changed the SSH port, reflect it here (e.g., port = 2222).
port    = ssh

# Mode “aggressive” catches more patterns (invalid users, many auth noise cases).
# Requires fail2ban 0.11+ with newer sshd filter.
mode    = aggressive

Config Breakdown

[DEFAULT] block: Sets global behavior all jails inherit.
- ignoreip keeps your admin workstation/VPN/LAN from getting locked out during fat-finger moments.
- bantime, findtime, and maxretry control the ban policy. Here: 5 bad tries within 10 minutes → ban. A 1-hour ban is long enough to stop bots but short enough to forgive honest mistakes.
- bantime.increment = true (+ factor, maxtime) makes repeat offenders stay banned longer (1h → 2h → 4h … up to 1 week). This crushes persistent botnets without you micromanaging lists.
- backend = systemd reads from the journal instead of plain log files. It’s resilient to log rotation, works well on Debian/Ubuntu, and behaves nicely in containers/VMs.
- banaction = nftables-multiport uses nftables rules to block offenders. If your host still uses iptables, switch to iptables-multiport.
[sshd] jail: The actual protection for SSH.
- enabled = true turns it on.
- filter = sshd tells Fail2ban which regex set to use. It recognizes failed logins, invalid users, etc.
- port = ssh binds bans to your SSH port. If you run SSH on a non-standard port, change it (e.g., 2222).
- mode = aggressive expands matches to catch more brute-force patterns and “invalid user” noise attackers use to enumerate accounts.

Step 6: Test and Verify

Now comes the moment of truth. Before you close that original SSH session (your safety net), let’s make sure everything actually works:

Open a new terminal window and test logging in with your key.
Confirm you can’t log in as root.
Confirm password login is refused.
Check logs with:
```
sudo tail -f /var/log/auth.log
```

This is where patience pays off. Only after confirming everything works should you close your original session. If something breaks, you’ll still have that old session open to fix it. Trust me, there’s nothing quite like the sinking feeling of being locked out of your own server because you skipped this step.

Step 7: Ongoing Monitoring and Auditing

SSH hardening isn’t a one-and-done deal. Think of it like home security: you don’t install locks and never check them again. Attackers adapt their methods, which means your defenses need regular attention too.

Here’s what to keep an eye on:

Review logs regularly (/var/log/auth.log or journalctl -u ssh). Look for failed login attempts, especially repeated ones from the same IP addresses.
Audit authorized keys at least monthly. Remove old keys, particularly when team members leave or change roles. Stale keys are like forgotten spare house keys under the doormat.
Check for anomalies like new user accounts you didn’t create or SSH configuration changes you didn’t make. These could signal that someone’s already gotten in.
System Updates keep the server patch and updated. SSH is patch frequently.

Set a calendar reminder to do this monthly. It takes maybe 10 minutes, but catching problems early beats dealing with a breach later.

Troubleshooting Common SSH Problems

Even experienced admins lock themselves out occasionally. Here are the most common ways things go sideways and how to fix them:

Locked out after disabling passwords
This classic mistake happens when your SSH key wasn’t copied correctly before you disabled password authentication. You’ll need to access your server through your hosting provider’s web console or rescue environment, then re-enable PasswordAuthentication yes in your SSH config until you get your keys working properly.
Wrong file permissions
If you see errors like “bad owner or permissions on .ssh/config”, your SSH files are readable by other users, which SSH considers a security risk. Reset the permissions as shown in Step 4 above.
Forgot to update firewall when changing port
Changed your SSH port to Port 2222 but forgot to open that port in your firewall? Your connection will just hang there, looking like a network issue. Always update your firewall rules before changing SSH ports, not after.
Trying to allow root login with keys
Even with “key-only” authentication, allowing direct root login creates unnecessary risk. If someone compromises your key, they have immediate root access. Stick with PermitRootLogin no and use sudo instead.
VPN misconfiguration
If you’re routing SSH through a VPN, test your access thoroughly in a non-production environment first. This setup adds complexity that can leave you stranded if misconfigured.

ASROCK Mini-Desktop Computer This compact barebone system is ideal for running lightweight VMs or containers, allowing you to isolate and secure SSH services as recommended in the guide. Its support for modern Intel CPUs and flexible storage options make it a practical choice for building a secure, dedicated SSH gateway or jump box. Perfect for DIYers who want a tidy, efficient, and secure homelab setup.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

FAQs: Secure SSH in Practice

➤ How do I generate a secure SSH key pair?

Use ssh-keygen -t ed25519 for modern systems. If you’re stuck with older infrastructure, fall back to ssh-keygen -t rsa -b 4096. The Ed25519 algorithm is faster, more secure, and generates smaller keys, but RSA with 4096 bits still does the job when needed.

➤ Why does SSH complain about bad owner or permissions?

SSH is picky about file permissions because it has to be. Your .ssh directory needs 700 permissions (owner read/write/execute only), private keys need 600 (owner read/write only), and public keys need 644 (owner read/write, others read). SSH refuses to work with loose permissions because anyone who can read your private key can impersonate you.

➤ How do I change the SSH port safely?

Edit /etc/ssh/sshd_config and set Port 2222 (or whatever port you prefer). Here’s the critical part: update your firewall rules to allow the new port before restarting SSH. Otherwise, you’ll lock yourself out and need console access to fix it. Test the new port works before closing your current session.

➤ What are the most important `sshd_config` settings?

Start with these four: PasswordAuthentication no (forces key-based auth), PermitRootLogin no (eliminates the highest-value target), strong Ciphers and MACs (modern crypto only), and AllowUsers or AllowGroups (whitelist who can even attempt to connect). These settings alone will block most automated attacks.

➤ Is it safe to allow root login with SSH keys?

Best practice is no, even with keys. Root access means game over if compromised, so why make it a direct target? Create a regular user account, give it sudo privileges, and SSH in as that user instead. It’s one extra step that eliminates the most obvious attack vector.

➤ Should I still use RSA keys?

Use Ed25519 when possible since it’s more secure and performs better. RSA with 4096 bits is still acceptable for systems that don’t support Ed25519, but avoid anything smaller than 2048 bits. If you’re generating new keys today, go with Ed25519 unless you have a specific reason not to.

➤ What extra steps if SSH must face the internet?

Layer your defenses: restrict access by IP address when possible, install Fail2ban to block brute force attempts, consider putting SSH behind a VPN or bastion host, and monitor your logs religiously. The internet is full of bots scanning for SSH servers, so assume you’re being probed constantly.

➤ How do I set up Fail2ban for SSH?

Install Fail2ban through your package manager, then enable the sshd jail in /etc/fail2ban/jail.local. The default settings work well for most setups: they’ll ban IPs after a few failed attempts and gradually increase ban times for repeat offenders. Just make sure you whitelist your own IP addresses first.

➤ What ciphers and MACs should I use?

Stick with modern algorithms like aes256-ctr for encryption and hmac-sha2-256 for message authentication. Avoid anything with “md5” or “sha1” in the name, and definitely skip older ciphers like 3DES or Blowfish. When in doubt, let SSH negotiate the strongest common algorithm between client and server.

➤ How do I recover access if I'm locked out?

Use your hosting provider’s console access or rescue system to get back in. Fix whatever broke in /etc/ssh/sshd_config, restart the SSH service, and test from another session before logging out. This is why you always test configuration changes before closing your current SSH session.

Conclusion

If you take one thing from this guide, it’s this: SSH security depends less on any one trick and more on layers of defense. Keys instead of passwords, no root logins, careful configuration, restrictive firewalls, monitoring, and automation all stack together to drastically lower your risk.

Set aside a little time to secure SSH right after deploying any new server. It will save you headaches down the line, whether you’re running a personal project or a company’s production infrastructure. Trust me, dealing with a compromised server is far worse than spending 30 minutes hardening SSH upfront.

Next steps you can explore:

Automating SSH hardening with configuration management tools like Ansible.
Adding multi-factor authentication for SSH.

Your SSH server should no longer feel like a liability. It should feel like a fortress that you actually trust to keep the bad guys out.

Other Sources

How to Upgrade Debian 12 to 13 in Proxmox LXC Without CREDENTIALS Errors

Sun, 14 Sep 2025 07:41:22 -0600

Are you running Debian 12 (Bookworm) in an LXC container on Proxmox and want to upgrade to 13 (Trixie)? This should be straightforward, right? Well, if you’ve landed here, you’ve probably discovered that systemd has other plans.

The issue is that systemd 256+ introduces stricter credential handling that doesn’t play nicely with unprivileged LXC containers. When you try to upgrade, you’ll hit the dreaded 243/CREDENTIALS error that stops the upgrade dead in its tracks.

Here’s how to work around it and upgrade your Debian LXC to Trixie without pulling your hair out.

💭 TL;DR

Debian 13's systemd 256+ enables credential plumbing by default, which sounds fancy until you realize it breaks unprivileged LXC containers with cryptic `243/CREDENTIALS` errors. The workaround is straightforward: install Debian's `lxc.generator` before upgrading to Trixie, let systemd reload its configuration, complete the upgrade, then remove the generator. It's a temporary bridge that keeps your services running while systemd figures out it's living in a container.

Upgrading Debian containers inside Proxmox VE should be boring. Boring is why you are running Debian. Change your apt sources, run the upgrade, reboot, and get on with your life. At least, that’s what the Reddit threads kept telling me when Debian 13 “Trixie” dropped. But if you’re running unprivileged and unnested LXCs on Proxmox 9, you already know that’s not how it goes. The result instead? A blinking cursor, status=243/CREDENTIALS failures, and crawling through logs that don’t want to work.

This post is for anyone who cares about security, runs their LXCs unprivileged, and doesn’t want to flip on “nesting” just to upgrade to Trixie. I’ll explain why the 243/CREDENTIALS error happens, what breaks when you don’t fix it, and the Proxmox-tested method to survive the upgrade strictly within safe, unprivileged boundaries.

I’ve been elbow-deep in these breakages myself, and this guide distills hours of trial and error into a path that works. Whether you’re upgrading Debian 12 to 13 or troubleshooting existing lxc templates Proxmox setups, you’ll walk away with a container that boots cleanly and stays secure.

MINISFORUM MS-A2 A premium mini-workstation engineered for demanding homelab environments. The MS-A2 excels at running Proxmox 9 with multiple concurrent LXC containers, making it perfect for advanced Debian testing and migration workflows. Robust networking capabilities and extensive storage options provide the foundation needed for complex systemd troubleshooting and enterprise-grade container management.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Why Upgrading Debian 12 to 13 Breaks on Proxmox 9

When you upgrade Debian 12 to 13 (Bookworm to Trixie), the culprit hiding in the shadows is systemd 256+. This release enabled unit credentials (LoadCredential and ImportCredential) by default, which sounds harmless enough.

On bare metal or regular VMs, it works perfectly. But inside Proxmox LXCs, especially unprivileged containers, this feature crashes headfirst into the container’s limited namespace access. Here’s the breakdown:

systemd-sysctl (the service that applies kernel parameters) tries to load credentials
LXC blocks the namespace operation because the container doesn’t have permission
systemd throws a status=243/CREDENTIALS error and gives up
Other core services cascade into failure, from udev triggers to login shells

Most likely upgrade error:

Job for systemd-sysctl.service failed because the control process exited with error code.
See "systemctl status systemd-sysctl.service" and "journalctl -xeu systemd-sysctl.service" for details.
Processing trigger

systemctl status systemd-sysctl.service:

x systemd-sysctl.service - Apply Kernel Variables
     Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static)
     Active: failed (Result: exit-code) since Sun 2025-09-14 05:59:21 MDT; 48s ago
   Duration: 2h 59min 12.451s
 Invocation: 63213f2f7514402f8cedd10155c7d065
       Docs: man:systemd-sysctl.service(8)
             man:sysctl.d(5)
    Process: 17806 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=243/CREDENTIALS)
   Main PID: 17806 (code=exited, status=243/CREDENTIALS)
   Mem peak: 1.7M
        CPU: 5ms

What that error actually means

Essentially, systemd is trying to pass secrets inside a container that has no infrastructure for handling them. Your services never start, the container hangs during boot, and debugging becomes a headache since half the logging system is broken too.

243/CREDENTIALS = “failed to set up the unit’s credentials”.

Why Not Nesting or Privileged?

You could enable nesting or switch the container to privileged mode. Both approaches sidestep the 243/CREDENTIALS error, and Reddit is packed with people who took this route. But here’s why that’s not ideal:

Nesting weakens container boundaries by giving writable access to /proc and /sys that containers shouldn’t touch. If you care about minimizing attack surface, this defeats the purpose.
Privileged LXCs strip away the UID mapping isolation that protects your host from container escape attempts. You’re trading security for convenience.

If you want to keep your containers properly isolated and secure, the correct approach is fixing systemd’s behavior, not compromising your security model.

What breaks if you don’t fix it

If you try to upgrade to Debian 13 (Trixie) without handling the systemd changes first, your LXC container becomes just a flashing cursor:

The container won’t boot at all. It just hangs there, mocking your weekend plans.
Critical systemd units like systemd-sysctl, udev-trigger, and terminal login will fail consistently.
journald may crash, which means you lose the diagnostic logs you desperately need to figure out what went wrong.

ASROCK Mini-Desktop Computer The DeskMini B760 delivers full-scale performance in a remarkably compact form factor. Built for serious virtualization workloads, it handles Proxmox deployments and LXC container orchestration with ease. Fast storage support and modern Intel CPU compatibility ensure reliable performance for complex homelab projects and containerization experiments.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

The Fix: lxc.generator for Proxmox LXC Templates

Debian includes a small but clever utility called lxc.generator (part of the distrobuilder package) that solves this problem. It runs early in the systemd boot sequence and automatically patches unit files to make them container-friendly Debian Sources. Here’s what it does:

Detects when the system is running inside an LXC container or an unprivileged environment
Strips problematic flags like LoadCredential= and ImportCredential= that cause the 243/CREDENTIALS errors
Relaxes security hardening settings that don’t work properly in containers
Masks services that would otherwise crash during container startup

The beauty of lxc.generator is that it creates temporary drop-in files in /run/systemd/... rather than permanently modifying anything on disk. This means your system stays clean, and once you complete a proper upgrade and reboot, you can safely remove the generator without leaving any traces behind

⚠️

Warning: Tested on Proxmox VE 9.x with unprivileged, unnested Debian LXCs. It should also help in LXD or Incus, but I have not tested there.

1) Patch each Debian 12 container before upgrading

Before we upgrade Debian 12 to 13, we need to install a small fix that prevents systemd from breaking during the transition. Enter your Debian 12 (Bookworm) LXC container and run:

sudo mkdir -p /etc/systemd/system-generators
curl -fsSL https://sources.debian.org/data/main/d/distrobuilder/3.2-2/distrobuilder/lxc.generator \
  | sudo tee /etc/systemd/system-generators/lxc >/dev/null
sudo chmod 0755 /etc/systemd/system-generators/lxc
sudo systemctl daemon-reload

💡

Tip: The generator tells systemd to disable the credential features that cause the 243/CREDENTIALS error. Think of it as a temporary patch that keeps things running smoothly during and after the upgrade.

2) Upgrade to Debian 13 (Trixie)

Still inside your LXC container:

# Make sure Bookworm up to date
sudo apt update && sudo apt upgrade -y

# Update sources to Trixie
sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sudo apt update

# Upgrade across versions
sudo apt dist-upgrade -y

# Clean up junk
sudo apt autoremove -y
sudo apt autoclean -y

# Modernize apt format (optional but recommended)
sudo apt modernize-sources || true

# Reload systemd configs and reboot
sudo systemctl daemon-reload
sudo reboot

3) Verify

The upgrade process will take a few minutes depending on your container’s size and network speed. When the container comes back online, verify the upgrade worked:

cat /etc/os-release

You should see something like:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.1

If you see “trixie” in the output, congratulations! Your upgrade to Debian 13 was successful.

4) Optional Clean-up

Once you’ve confirmed everything runs smoothly on Trixie, you can remove the distrobuilder file:

sudo rm -f /etc/systemd/system-generators/lxc

Intel® Core™ i5-12500 12th Generation Desktop Processor This 12th Gen Intel CPU combines exceptional performance with energy efficiency, making it ideal for Proxmox virtualization and LXC container management. Whether you’re orchestrating complex Debian migrations or building a responsive homelab environment, the i5-12500 delivers the processing power needed for seamless Linux operations and system upgrades.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Alternative Options: Pick Your Poison

Option	Security	Effort	Side effects	Use when…
Use `lxc.generator` (this post)	High	Low	Temporary file you remove post-upgrade	You want unprivileged + unnested to stay that way
Enable nesting	Lower	Low	Wider write access into `/proc` and `/sys`	You must run workloads that need it and accept risk
Flip to privileged LXC	Lowest	Medium	UID mapping changes, more blast radius	You need kernel options that won’t work unprivileged
Migrate to VM	High	High	Overhead and resource cost	You want zero container weirdness

The lxc.generator approach gives you the cleanest path forward. It sidesteps the 243/CREDENTIALS error without compromising your container’s security model or requiring you to rethink your entire setup.

FAQs

➤ What does `status=243/CREDENTIALS` mean, exactly?

It’s a systemd error code that translates to “failed to setup credentials.” Starting with systemd 256, the system expects to mount sensitive files like API tokens into service units through tmpfs-backed namespaces. The problem? Unprivileged LXC containers don’t have the kernel options to support this feature, so services that rely on it fail to start.

➤ Could I just enable nesting and forget about it?

You could, but you’d be trading security for convenience. Nesting weakens your LXC sandbox by exposing more of the host’s /proc and /sys filesystems to the container. Unless you specifically need Docker-in-LXC or other heavy containerized workloads, keep nesting disabled and use the generator approach instead.

➤ Is `lxc.generator` safe to leave on long-term?

Absolutely. The generator only creates ephemeral systemd drop-in files and won’t interfere with your system’s normal operation. That said, since its main purpose is helping with the transition to newer systemd versions, many administrators remove it once they’ve verified everything works properly after the upgrade.

➤ Can I use this on LXD instead of Proxmox?

In theory, yes. The lxc.generator is designed to work with LXC containers, not just Proxmox. However, the specific steps in this guide have only been tested on Proxmox VE 9 with unprivileged containers. If you’re running a different platform, the concepts should apply, but proceed carefully and test thoroughly.

➤ Do I need to replace my `sources.list` with deb822 format?

Not required. Your existing old-style sources will continue working just fine. However, Debian is encouraging the switch to the newer deb822 format, and if you want to modernize, you can run apt modernize-sources to handle the conversion automatically.

Conclusion

Upgrading an unprivileged Debian container on Proxmox shouldn’t require a vocabulary lesson in creative profanity. The culprit here is systemd’s new credential defaults in version 256+, and the surgical fix is lxc.generator. Install it, reload your container config, upgrade Debian 12 to 13 (Trixie), reboot, then remove the generator. That’s it.

You keep your security posture intact: no container nesting, no privileged LXCs, no compromises. You get your shiny new Debian 13 system, and the 243/CREDENTIALS error becomes a distant memory.

The takeaway from this particular adventure: LXC template upgrades only look straightforward until systemd decides to change the rules mid-game. Understanding why the upgrade breaks and applying a targeted fix beats both the security risks of privileged containers and the headache of rebuilding from scratch.

Now go enjoy whatever you’re running on that freshly upgraded server. You’ve earned it.

RaspberryPi 4GB An affordable, energy-efficient platform perfect for homelab experimentation and learning. The Pi 4GB excels at running lightweight LXC containers and testing Debian upgrades in a safe environment. Its low power consumption and compact design make it an ideal sandbox for exploring systemd configurations and container deployments before implementing changes on production systems.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Sources

NFS vs SMB for Media Servers: Which Protocol Should You Use?

Thu, 11 Sep 2025 06:54:35 -0600

I used to think choosing between NFS and SMB was like picking between Coke and Pepsi: a purely personal preference with no real consequences. I was wrong. If you’re running a Linux media server and care about performance, compatibility, and sane file permissions, the protocol you choose will define your entire experience. Pick wrong, and you’ll spend weekends debugging permission errors instead of watching movies or shows.

This guide cuts through the mythology and gives you a practical decision framework for NFS vs SMB. I’ll show you where each protocol shines, how to set them up on a Linux server, what settings actually matter, and how to avoid the gotchas that regularly bite folks. Whether you’re running a mixed-OS environment or just trying to access your Unraid shares from Windows, this one’s for you.

NFS vs SMB: What Each Protocol Does

Network File System (NFS) is the native file-sharing protocol for Unix and Linux systems. It makes remote folders appear as local directories, with tight integration into the Linux kernel. It’s how Linux prefers to share files across a network.

Server Message Block (SMB) is Windows’ native file-sharing protocol. Linux systems access SMB shares through Samba, while macOS speaks SMB natively. SMB packs more features and integrates deeply with Windows authentication and permissions.

Feature	NFS	SMB
Best for	Linux-to-Linux	Mixed OS / Windows
Default on	Linux/Unix	Windows
Encryption	NFSv4 + Kerberos	SMB3 built-in
Performance (small files, Linux)	Faster	Slower
Performance (large files)	Similar	Similar
Windows support	Poor	Native
Docker/container use	Common	Less common
Setup complexity	Simple (Linux)	Moderate

Why this matters for your media server:

Your media server constantly reads metadata, generates thumbnails, and streams video files. The protocol you choose directly impacts how fast library scans complete, how quickly your media player interface loads, and whether file permissions stay manageable or slowly drive you insane.

Your clients’ operating systems drive the decision. Running a Linux media server accessed only by other Linux machines? NFS typically performs better. Mixed environments with Windows, macOS, and Linux clients? SMB is the sane choice.

Both protocols can be properly secured on a trusted LAN, but their default configurations and hardening approaches vary significantly. Poor defaults have real consequences. SMBv1 vulnerabilities enabled major malware outbreaks. Misconfigured NFS exports can expose your data to anyone on the network. Neither protocol forgives carelessness.

UGREEN NASync DXP4800 Plus 4-Bay Desktop NAS
Four bays, an Intel N100, and a 2.5GbE port. Supports both NFS and SMB out of the box, so you can actually test what you’re reading about here instead of just theorizing. A solid entry point if you don’t already have a NAS to experiment with.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

NFS or SMB: Which Protocol Should You Use?

All clients are Linux, Unix, or Android TV?

Pick NFS. It’s fast, mature, and simple for Linux-to-Linux communication. You’ll avoid the worst of the permission headaches, provided you manage your UIDs and GIDs correctly. (More on that later.)

Windows or macOS clients in the mix?

Pick SMB. It’s native on Windows, works smoothly on macOS, and Samba on Linux is robust. If specific Linux-only apps benefit from NFS, you can add it alongside SMB, but let SMB be the default.

Security and centralized authentication matter?

SMB3 with modern authentication and encryption is the more straightforward path, especially in Windows and Samba environments. NFSv4 with Kerberos can be equally secure, but the setup complexity is significantly higher. If you’re not doing Kerberos, restrict NFS to trusted subnets and use strong firewall rules.

Running Unraid or another NAS?

Unraid and most NAS platforms support both protocols. Use SMB for Windows clients, NFS for Linux clients or Docker containers. Don’t expose either protocol to the internet. Ever.

💡

Tip: Both protocols are fast enough for streaming large media files. The performance gap shows up when your media manager scans thousands of tiny images and NFO files. Linux clients usually chew through those faster over NFS, while Windows clients do better with SMB thanks to client stack optimizations.

NFS vs SMB Pros and Cons

NFS: Strengths and Weaknesses

Pros:

Fast on Linux. Lower protocol overhead and native kernel modules give NFS an edge when dealing with many small file operations in Linux-only environments. For a Linux media server streaming content to other Linux clients and managing large collections, this matters.

Simple integration. NFS is part of the Linux ecosystem. Mounts, fstab, systemd units, and permissions all make sense if you track your UIDs and GIDs. No wrestling with foreign concepts.

Stateless heritage. Classic NFSv3 is largely stateless, which can simplify some failure recoveries.

Cons:

Security by default is weaker. Older NFS versions lack encryption and rely on client-side UID/GID trust. NFSv4 improves this and supports Kerberos, but few home labs set that up correctly. Most people live with the risk and lock things down with firewall rules. Know that you’re making that trade-off.

Windows support is painful. Windows can mount NFS, but the built-in client is inconsistent across editions and awkward to configure. If you need to access shares from Windows regularly, save yourself the grief and use SMB.

Focused feature set. NFS does file and directory sharing well. That’s it. Don’t come looking for the broader Windows ecosystem features that SMB provides.

Best fit: Linux media servers and clients, Docker workloads, Kubernetes, and Linux-only NAS access.

SMB: Strengths and Weaknesses

Pros:

Cross-platform. Native on Windows, solid on macOS and Linux via Samba. For mixed-OS homes and offices, SMB just works. That’s not praise you hand out lightly in this industry.

Modern security. SMB3 supports strong authentication and optional encryption, integrates with Active Directory, and includes features like signing and multichannel. When configured properly, it’s solid.

Feature-rich. Beyond files, SMB supports printers and deep Access Control List (ACL) capabilities that align with Windows permission models. If you have a Windows background, the permissions will feel familiar.

Cons:

More overhead. Often slower than NFS in Linux-to-Linux scenarios with many small files, though SMB3 performance can be excellent with Windows clients. The extra features come at a cost.

More knobs to misconfigure. Samba has a lot of options, and it’s easy to botch permissions or lose performance with certain security defaults. The flexibility is both a blessing and a trap.

❌

Danger: SMBv1 is insecure and was exploited in major malware outbreaks like WannaCry. Disable it everywhere. No exceptions, no excuses, no “but my old printer needs it.” If a device only speaks SMBv1, that device has a retirement date, and it’s today.

Best fit: Mixed OS environments, Windows clients, or macOS systems.

Preparing Your Linux Server or NAS

Whether you’re running a bare Linux server, Unraid, Synology, TrueNAS, or another NAS platform, the setup approach stays consistent. Sort this out before you touch a config file:

Figure out which shares will be accessed by which clients. Use SMB for Windows and macOS connections. Use NFS for Linux apps and clients. Avoid exporting the same path through both protocols unless you understand the consequences for permissions and extended attributes (and you probably don’t yet, which is fine). Keep both protocols scoped to your trusted LAN. Never port-forward 445 or 2049 from your router to the internet.

⚠️

Warning: That last point is worth repeating: exposing file share ports to the internet is begging for trouble. Your media server doesn’t need to be the next cautionary tale in network security forums. People will screenshot your misconfiguration and post it for laughs.

On Unraid specifically:

SMB comes enabled by default, making Windows access straightforward. You can enable NFS per share for Linux clients and containers. Mapping Windows drives to SMB shares is point-and-click simple. Accessing NFS shares from Windows, on the other hand, requires client-side tools and sometimes Windows Enterprise features. For most home setups, SMB handles Windows clients just fine. Don’t add an unnecessary headache.

On Synology DSM:

Synology supports both NFS and SMB through its Control Panel. SMB is enabled by default. To enable NFS, go to Control Panel > File Services > NFS and check “Enable NFS service.” You can then set NFS permissions per shared folder under the folder’s edit settings. Synology makes this relatively painless, but pay attention to the squash settings and allowed IP ranges. The defaults are conservative, which is the right instinct, but they’ll block access if you don’t explicitly allow your client subnets.

On TrueNAS (SCALE and CORE):

TrueNAS supports both protocols through its web UI. Create a dataset first, then configure SMB or NFS sharing on top of it. For Jellyfin or Plex running in a TrueNAS container or jail, NFS is the common choice for mounting media storage. Be aware that TrueNAS SCALE uses Linux under the hood while TrueNAS CORE uses FreeBSD, which can affect how NFS permissions behave. If you’re running apps on TrueNAS SCALE, pointing them at an NFS share from a separate dataset avoids the host path permission headaches that catch a lot of people.

Setting Up SMB on a Linux Server (Samba)

Getting SMB running on Linux is straightforward once you know the steps. Here’s how to set up a proper media share that Windows, macOS, and other Linux machines can all access without drama.

Follow my SMB installation and Configuration Guide

Read

Security Notes: Use SMBv3 or higher wherever possible. Disable SMBv1 entirely. If you’ve read this far, and it’s still enabled on your network, go fix that now. I’ll wait.

The linked configuration guide creates a secure, authenticated share that works reliably across different operating systems. Your Linux media server will play nicely with Windows clients without the permission headaches that sometimes plague mixed environments.

MINISFORUM MS-A2 Dual 2.5GbE with a 10GbE option, a Ryzen CPU, and triple NVMe slots in a box smaller than most routers. If you want a Proxmox host that can run NFS and SMB servers in VMs or containers without breaking a sweat, this is the kind of hardware that makes it trivial.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Setting Up NFS on a Linux Server

Getting NFS running on your Linux media server is straightforward once you know the steps. Here’s how to get it configured properly:

Follow my NFS installation and Configuration Guide

Read

For those who want the quick version, here’s what mounting an NFS share from a Linux client looks like in practice:

# One-time manual mount to test the connection
sudo mount -t nfs4 192.168.1.100:/mnt/media /mnt/nfs/media

# Persistent mount via /etc/fstab (survives reboots)
# Add this line:
192.168.1.100:/mnt/media  /mnt/nfs/media  nfs4  rw,noatime,rsize=1048576,wsize=1048576  0  0

Replace the IP and paths with your own. Test the manual mount first. If that works, add the fstab entry. If the manual mount fails, don’t bother with fstab until you’ve sorted out the underlying issue. Debugging a boot hang caused by a bad NFS mount in fstab is a miserable experience. Ask me how I know. If you’re worried about boot hangs, add the nofail option, so the system boots even if the NFS server is unreachable.

NFS and SMB Security Best Practices

Here’s the thing about network file sharing: convenience and security pull in opposite directions. But a few smart choices upfront will save you from becoming internet famous for all the wrong reasons.

Keep it local. SMB and NFS belong on your trusted LAN only. Never expose ports 445 (SMB) or 2049 (NFS) to the internet. Block them at your router and firewall. This isn’t paranoia. This is basic hygiene.

SMB security essentials:

Disable SMBv1 entirely. It’s ancient, vulnerable, and has no place in modern networks. Use SMBv2 or SMBv3. Enable strong authentication and SMB encryption where your data sensitivity justifies the CPU overhead. Yes, encryption costs performance, but that’s a trade-off worth making for sensitive content. If you need centralized user management, integrate with existing directory services rather than managing local accounts one by one.

NFS security essentials:

Stick with NFSv4 over older versions. Restrict exports by IP or subnet. Use root_squash to prevent compromised clients from running wild with root privileges. Deploy host-based firewalls to allow only known clients. Defense in depth matters because single points of failure are single points of regret.

The backup reality check: Neither SMB nor NFS will save you from accidental deletion or ransomware. Keep offline or versioned backups of your important data. This is not optional. Your future self will thank you, or your current self will learn the hard way.

NFS and SMB Performance Tuning

Getting good performance from network shares isn’t rocket science, but a few targeted tweaks can make a noticeable difference. Here’s what actually moves the needle:

NFS:

For large sequential reads (streaming movies), the default settings are usually fine. For many small files, look at actimeo (attribute cache timing) and consider noatime to reduce metadata writes. Use NFSv4.2 when available. It cuts down on port sprawl and handles flaky network connections better. You can bump up rsize/wsize (try rsize=1048576,wsize=1048576 as a starting point), but test with your specific NIC and switch setup. Bigger buffers aren’t always better buffers.

SMB:

Enable SMB multichannel on capable clients and servers. It bonds multiple NICs or network paths for better throughput and fault tolerance. Stick with SMB version 3.x or higher.

Both protocols:

Jumbo frames (MTU 9000) can help, but only if every single network hop supports the same MTU. Miss one switch or router, and you’ll actually make things worse. Always test with tools like robocopy (Windows), fio, or dd to measure before and after. A simple sequential read test with fio looks like this:

fio --name=seqread --rw=read --bs=1M --size=1G --numjobs=1 --filename=/mnt/yourshare/testfile

Change one variable at a time. Otherwise you’ll never know what helped and what hurt.

NFS vs SMB Speed: What the Benchmarks Actually Show

People love to argue about NFS vs SMB performance in the abstract. Here’s what the numbers actually look like in real homelab conditions.

For sequential reads and writes (streaming a movie, copying a large file), NFS and SMB perform within a few percent of each other on a modern gigabit or 2.5GbE link. Both protocols will saturate a 1GbE connection without breaking a sweat. You’re not going to notice a difference when playing a 30GB Blu-ray remux over either protocol.

The gap opens up with small files. When your media manager scans a library of thousands of NFO files, poster images, and subtitle files, NFS on Linux clients can be 25-30% faster than SMB for random read operations. This is where NFS’s lower protocol overhead and kernel-level integration actually matter. If your Jellyfin library scan takes 20 minutes over SMB, it might take 14 over NFS. That adds up when you’re managing a large collection.

SMB claws back some ground on random writes, where it’s sometimes faster depending on the server and client configuration. And on Windows clients, SMB’s native stack optimizations mean it frequently outperforms NFS, which is running through a clunkier client implementation on that platform.

The takeaway: don’t pick a protocol based on speed alone. Pick based on your client OS, then tune for speed within that choice.

Seagate Barracuda 24TB Internal Hard Drive
Protocol benchmarks don’t mean much against a handful of test files. You need a real media library to see the difference. 24TB gives you enough room to fill a NAS and actually stress-test your NFS or SMB configuration with thousands of files, not a synthetic toy workload.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Common NFS and SMB Pitfalls

Mixing NFS and SMB on the same share:
This is a deep topic, but the short version: Windows ACLs and POSIX permissions are like oil and water. Samba stores NT ACLs as extended attributes, but NFS clients may not preserve them. If you must mix protocols on the same data, separate your write paths or designate one protocol for writes and keep the other read-only.

UID/GID mismatches on NFS:
Keep your user and group IDs consistent across all Linux clients. Use centralized identity management (LDAP/SSSD) or carefully align your /etc/passwd entries. For a quick check, run id username on both client and server and make sure the numbers match. Debugging permission issues caused by mismatched IDs is not how you want to spend your weekend.

Assuming “NFS is insecure” or “SMB is slow”:
These are lazy generalizations. NFSv4 with Kerberos is robust. SMB3 on modern stacks is both fast and secure. The real performance and security outcomes depend on your configuration and client mix, not the protocol name on the tin.

Turning on async writes blindly on NFS:
Async writes (async in /etc/exports) can boost speed, but at the cost of data safety during crashes. If the server goes down mid-write, you can lose data. Understand the trade-off before flipping that switch.

Exposing shares directly to the internet:
This is how you get pwned. Use VPNs for remote access. Never use direct port forwards for file shares. Not “probably don’t.” Don’t.

Example Scenarios: What To Choose

Here’s how to pick the right protocol based on your actual setup:

All Linux home:
Export media via NFSv4, mount on Jellyfin/Plex and your Linux desktop. Keep UIDs aligned across systems. Optionally offer SMB read-only for occasional Windows use. This gives you the performance benefits of NFS where it matters most while keeping a door open for Windows guests.

Windows family PCs, macOS laptop, Linux server NAS:
Use SMB for everyone. Enable NFS only for Linux containers or hosts that specifically benefit from it. Keep permissions in one place through Samba. Fighting permission mismatches across protocols isn’t worth the headache when SMB works fine for the whole house.

Unraid backing multiple Docker apps and a Windows gaming PC:
Give containers NFS or bind mounts for speed. Export the same content over SMB to Windows, but consider separate paths or read-only mounts to avoid permission drift. This hybrid approach lets your containers stay fast while keeping Windows happy. Watch for permission conflicts if both protocols write to the same files. When in doubt, pick one writer.

NFS vs SMB for Docker Containers

If you’re running Plex, Jellyfin, Sonarr, Radarr, or any other media app in Docker, you have three main options for accessing remote storage: NFS mounts, SMB/CIFS mounts, or bind mounts from a path already mounted on the host.

The cleanest approach for most homelabs is to mount the NFS share on the Docker host, then bind-mount that path into your containers. This keeps the NFS configuration in one place (the host’s /etc/fstab) and lets every container access the same media library without each one needing its own network mount logic. Here’s what that looks like:

# On the Docker host, mount the NFS share
192.168.1.100:/mnt/media  /mnt/nfs/media  nfs4  rw,noatime,nofail  0  0

# In docker-compose.yml, bind-mount it into the container
volumes:
  - /mnt/nfs/media:/media

You can mount SMB/CIFS shares into Docker containers using a CIFS volume driver or by mounting on the host first, but NFS is generally the better fit here. It avoids the SMB authentication layer, has less overhead for the constant small-file reads that media apps love to do, and plays nicer with Linux permissions inside containers. If your NAS is a Synology, TrueNAS, or Unraid box, enable NFS for these container workloads even if the rest of your house uses SMB.

One warning: make sure the NFS share is mounted before Docker starts your containers. If the mount isn’t ready and your container writes to what it thinks is the media directory, those writes land on the host’s local filesystem instead. You’ll spend an hour wondering why your files disappeared. Use nofail and x-systemd.automount in your fstab, or set up a systemd dependency so Docker waits for the mount.

NFS vs SMB for Proxmox

Proxmox users face this question constantly, especially when adding NAS storage as a datastore for VMs, containers, or ISO images. Proxmox supports both NFS and SMB/CIFS as storage backends, configurable directly from the Datacenter > Storage menu in the web UI.

For most Proxmox homelabs, NFS is the better default. Proxmox runs Linux under the hood, NFS is a first-class citizen, and the integration is straightforward. Add your NAS as an NFS datastore, point it at the export path, and Proxmox handles the rest. VM disk images, container templates, backups, and ISOs can all live on NFS storage without issue.

SMB/CIFS storage is also supported in Proxmox, but it’s more commonly used when the storage backend is a Windows server or when NFS isn’t available. If your NAS supports both, pick NFS for Proxmox and save SMB for your Windows and macOS clients.

One Proxmox-specific gotcha: if you’re passing NFS-mounted storage into an LXC container (not a VM), pay attention to UID/GID mapping. Unprivileged containers remap UIDs by default, which means UID 1000 inside the container becomes UID 101000 on the host and on the NFS share. Either use privileged containers for media workloads, manually map the UIDs in the container config, or accept that permissions will fight you until you sort it out.

Troubleshooting NFS and SMB Connections

When things go sideways (and they will), here’s how to get back on track.

Connection refused or cannot mount:
Check if your services are actually running: systemctl status smbd nmbd for SMB, or systemctl status nfs-server for NFS. Verify firewall rules. SMB needs TCP 445, NFSv4 needs TCP 2049. If you’re stuck with NFSv3, rpcbind and mountd may need additional ports opened. Double-check your server IP and share names. Yes, typos happen to all of us.

Permission denied:
For SMB, verify the user exists in both Linux and Samba (pdbedit -L lists Samba users), check smbpasswd, and validate share-level access controls. For NFS, UID/GID mismatches are the usual suspect. Align user IDs between systems or configure idmapd for NFSv4. Also make sure your export options aren’t accidentally set to ro (read-only) when you meant rw.

Slow file transfers:
Check what protocol version you’re actually using. Force vers=3.0 for SMB or vers=4.2 for NFS and test again. Disable Wi-Fi power saving on clients and test over wired connections. For SMB, experiment with multichannel, signing, or encryption settings to understand the performance trade-offs. Don’t disable security features on untrusted networks. For NFS, try different rsize/wsize values and check for duplicate mounts or DNS slowness.

Windows cannot access NFS:
The Client for NFS feature might be missing or unsupported in your Windows edition (Home edition doesn’t have it). Stick with SMB for Windows clients and save NFS for Linux systems.

Media server doesn’t see new files immediately:
For SMB, Samba uses change notifications, but some applications still cache directory listings. Try a manual library refresh or verify your app is watching the correct path. For NFS, attribute caching can delay file visibility. Adjust actimeo=0 for immediate visibility, but expect a performance hit. Find the balance that works for your scan frequency.

Library scans crawl along:
For many small files, NFS on Linux clients often outperforms SMB. Consider running your media scanner on a Linux machine over NFS, even if end users stream via SMB.

FAQs:

➤ What is the difference between NFS and SMB for a home media server?

NFS is Linux’s native file sharing protocol and excels at Linux-to-Linux performance with minimal overhead. SMB is Windows’ native protocol and works best in mixed OS environments, offering strong security features and broad client support. If your media server runs Linux but you have Windows clients, SMB is usually the safer bet.

➤ Does Unraid support NFS and SMB shares?

Yes, Unraid supports both protocols out of the box. SMB is enabled by default for Windows compatibility, while NFS is commonly used for Linux clients and Docker containers. You can enable either or both, depending on your needs.

➤ How do I access an NAS or Unraid share from Windows?

Use SMB. In Windows Explorer, type \\unraid-hostname\sharename in the address bar or map it as a network drive. While Windows 10 Pro and Enterprise can mount NFS shares, SMB is the path of least resistance for most home users.

➤ Which is faster for Plex or Jellyfin: NFS or SMB?

For Linux media servers scanning thousands of small files (like movie thumbnails), NFS typically wins due to lower protocol overhead. Windows clients often see better performance with SMB3. When streaming large video files, both protocols are plenty fast. Compatibility matters more than raw speed at that point.

➤ Is NFS secure enough for my home network?

NFS can be secure on a trusted home network when properly configured with export restrictions and firewall rules. For enhanced security, consider upgrading to NFSv4 with Kerberos authentication, though this significantly increases setup complexity. Most importantly, never expose NFS directly to the internet. Always use a VPN for remote access.

➤ How do I set up NFS shares on Unraid?

Enable NFS in Unraid’s settings, configure per-share export rules, and specify allowed client IPs or subnets. Mount from Linux clients using mount -t nfs server:/export /mnt. The key is getting the export permissions right the first time.

➤ Can I use both NFS and SMB on the same Unraid share?

Technically yes. But you’re asking for trouble. Permission conflicts and extended attribute mismatches can cause real headaches. If you must use both, consider making one protocol read-only or carefully separating write operations between protocols.

➤ Why am I getting permission denied when mounting an NFS share?

Usually, it’s UID/GID mismatches between your client and server, or restrictive export rules. Ensure user IDs align across your Linux systems and double-check /etc/exports for correct options and allowed subnets. This is the most common NFS stumbling block.

➤ How do I enable SMB3 encryption on my server?

In your Samba configuration, set smb encrypt = required or desired globally or per-share. Keep in mind that encryption adds CPU overhead. Test performance impacts on your hardware before committing.

➤ What are the risks of exposing SMB or NFS to the internet?

High risk. Don’t do it. SMBv1 was exploited in major ransomware outbreaks like WannaCry. Even modern SMB and NFS implementations are frequent attack targets. Use a VPN for remote access and never port-forward 445 or 2049 from your router.

➤ How do I fix slow file transfers over SMB or NFS?

Start with the basics: verify you’re using modern protocol versions, test with wired connections, and benchmark one change at a time. For NFS, tune rsize and wsize parameters. For SMB, enable multichannel if your hardware supports it.

➤ Should I use NFSv3 or NFSv4 for my media server?

Go with NFSv4 unless you have a specific reason not to. It simplifies port management, provides better file locking, and supports Kerberos security. Only stick with NFSv3 if you’re dealing with legacy systems that genuinely can’t handle v4.

➤ How do I map Linux users to Windows users for file access?

With SMB, configure Samba’s idmap backends and maintain consistent POSIX ACLs for cross-platform access. The Samba docs on idmap are dense but worth reading. Getting this right once saves you from ongoing permission fights.

➤ Should I use NFS or SMB for Docker containers?

NFS is generally the better choice for Docker containers on Linux. Mount the NFS share on the Docker host, then bind-mount the path into your containers. This avoids SMB’s authentication overhead and plays nicer with Linux permissions inside containers. Make sure the NFS mount is ready before Docker starts your containers, or you’ll write to the local filesystem by mistake.

➤ Should I use NFS or SMB with Proxmox?

NFS is the more natural fit for Proxmox since it runs Linux. Add your NAS as an NFS datastore through the Proxmox web UI under Datacenter > Storage. It works well for VM disk images, container templates, backups, and ISOs. Use SMB/CIFS in Proxmox only if your storage backend is a Windows server or NFS isn’t available.

➤ Does Synology support NFS and SMB?

Yes. Synology DSM supports both protocols. SMB is enabled by default. Enable NFS through Control Panel > File Services > NFS, then set NFS permissions per shared folder. Most Synology users run SMB for desktop clients and NFS for Linux servers, Docker hosts, or Proxmox datastores.

➤ NFS or SMB for TrueNAS media storage?

TrueNAS supports both. For media apps like Plex or Jellyfin running in TrueNAS containers or jails, NFS is the common choice. Create a dataset, configure NFS sharing on it, and point your media app at the NFS mount. Be aware that TrueNAS SCALE (Linux-based) and TrueNAS CORE (FreeBSD-based) handle NFS permissions slightly differently.

Conclusion: Make the Choice That Fits Your Clients and Your Risk

The decision comes down to matching your protocol to your environment and accepting the trade-offs.

If your world is Linux, NFS is the pragmatic, fast, and simple default. It speaks the same language as your filesystem and won’t fight you on permissions.

If you have Windows or macOS clients, SMB is the native choice that works. SMB3 brings solid security without requiring a PhD in Kerberos configuration.

You can run both protocols, but don’t blindly export the same writeable path over both unless you understand how permissions and metadata will clash. That way lies madness and mysterious “permission denied” errors at 2 AM.

Lock it down. Keep shares on your LAN, disable SMBv1 (seriously, it’s 2025), prefer NFSv4, and consider Kerberos or SMB encryption where your threat model demands it.

Next steps:

Pick one protocol per client type and start simple. Don’t overcomplicate your first setup. Benchmark your scans and streams to establish a baseline. Layer on security and performance tuning only after you have a stable foundation.

Whether you’re running a Linux media server or trying to access an Unraid share from Windows, the protocol choice matters less than understanding what you’re choosing and why. Your media server will feel faster, safer, and more predictable when you stop treating network protocols like a coin flip and start matching them to your actual needs.

TP-Link 2.5GB PCIe Network Card (TX201)
Hard to compare NFS and SMB performance when your NIC is the bottleneck. This 2.5GbE PCIe card is cheap, works out of the box on most Linux distros and Windows, and gets your gigabit ceiling out of the way, so you can see what the protocols are actually doing.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

How to Install Docker on Debian for GPU Passthrough and Transcoding

Wed, 27 Aug 2025 10:03:58 -0600

You want buttery-smooth 4K → 1080p hardware transcoding, and the quiet satisfaction of watching your CPU lounge around at 10% while your GPU does the heavy lifting. So you “quickly” pass your GPU into a Docker container… and Jellyfin stares back at you with the enthusiasm of a DMV clerk. The CPU is maxed out. Jellyfin logs throwing a tantrum about “no such device /dev/dri/renderD128.”

Welcome to the club. Population: everyone who has ever tried this.

I once burned a perfectly good Friday night (116 minutes, to be precise) wrestling with what Docker’s documentation cheerfully calls “simple” GPU passthrough. Drivers? Rock solid. Docker daemon? Restarted three times (because why stop at two?). YAML file? Formatted with the precision of a Swiss watchmaker. The actual problem? Linux permissions had decided my container wasn’t ‘special’ enough for the render group’s exclusive party.

After a scenic tour through udev rules, cgroup mysteries, and two spectacularly wrong Reddit threads that shall remain nameless, the GPU finally woke up. Frame times plummeted from “slideshow” to “silk.” My CPU went back to its regularly scheduled napping. And I made myself a solemn promise to document this mess before my brain forgot all the crucial details.

This is that documentation, the step-by-step guide I desperately needed that night. You’ll get the exact Docker Compose configuration, the permissions that actually matter, and a heads-up about the gotchas that love to bite newcomers. Whether you’re running NVIDIA, Intel integrated graphics, or AMD, by the end of this, you’ll have hardware-accelerated transcoding humming along in Docker containers, without the 1 AM debugging session.

💭 TL;DR

Think Docker will magically use your GPU? Cute. NVIDIA needs --gpus, Intel/AMD need /dev/dri, and you need to join the right groups. Otherwise, enjoy watching your CPU sweat bullets.

ASRock Intel ARC A380 Challenger The Arc A380 isn’t for gaming—it’s for obliterating video streams. With support for H.264, HEVC, and full AV1 hardware encode/decode, it crushes 20+ 1080p streams or 6–8 HDR tone-mapped 4Ks without breaking a sweat. Drop it in your media server, give Jellyfin direct VA-API access, and watch your CPU finally cool off for a bit.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Why GPU Passthrough Matters

High-quality video transcoding taxes CPUs heavily. Hardware acceleration using GPU features (NVIDIA NVENC, Intel VAAPI/QSV, AMD VCE) speeds this up dramatically, lowering CPU load and noise.

With Docker, you can isolate applications like Jellyfin or Plex in containers while granting them secure, controlled access to the host GPU. This results in smoother streaming, more simultaneous users, quieter fans, and efficient resource use.

Remember, GPU passthrough in Docker differs from VM passthrough. Docker handles device permissions and cgroups, giving containers controlled access to GPUs, and is less complicated than full hardware virtualization.

Why GPU Passthrough in Docker on Debian Often Fails (And How to Fix It)

Here’s the thing about GPU passthrough with Docker on Debian or any other Linux distro: it’s conceptually simple but practically finicky. Your GPU lives on the host system, happily managed by kernel drivers. Your Docker container exists in its own isolated environment with its own filesystem and permissions. Making Docker and your GPU talk requires more than just mounting a device file; you need the right permissions, correct device nodes, and sometimes a few udev rules to harmonize everything.

Think of it like lending your car to a friend. Giving keys (mounting the device) isn’t enough; they need insurance coverage (permissions), know where it’s parked (device paths), and understand the quirks (Linux-specific device behaviors).

Common failures include your container seeing the GPU but lacking permission, missing device nodes causing invisibility, or everything working temporarily, then breaking after a reboot due to unstable device paths.

Let’s fix these and get Docker GPU passthrough working reliably.

Need a Linux permissions refresher?
Understanding Linux Permissions

Proper Docker Compose Configuration for GPU Passthrough on Debian

Forget juggling docker run -it commands with complicated flags. Here’s a straightforward Docker Compose setup for GPU passthrough that persists across Debian reboots:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin-hw
    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128  # GPU device access
    group_add:
      - "render"           # Add container user to render group
      - "video"            # Add container user to video group
    environment:
      - JELLYFIN_PublishedServerUrl=http://your-server-ip:8096
    volumes:
      - ./config:/config
      - ./cache:/cache
      - /path/to/media:/media:ro
    ports:
      - "8096:8096"
    restart: unless-stopped

Why this works:

devices: /dev/dri:/dev/dri exposes all GPU device nodes, essential for hardware transcoding.
group_add adds your container user to render and video groups, granting necessary permissions.
restart: unless-stopped ensures resilience on Debian system reboots.

NVIDIA vs Intel/AMD GPU Passthrough on Docker

NVIDIA: Simplified GPU Passthrough

Install the proprietary NVIDIA driver and NVIDIA Container Toolkit on Debian. Use docker run -it --gpus all or Docker Compose device_requests for straightforward passthrough. The NVIDIA Toolkit handles driver mapping and permissions automatically.

This is suitable for Transcoding, AI, or other CUDA workloads

Intel/AMD: Manual Device Mapping

For Intel and AMD on Debian, manually expose /dev/dri into containers, manage permissions carefully, and ensure correct drivers (intel-media-driver, mesa-va-drivers) are installed.

Add container users to render and video groups to avoid permission denied errors. This approach is rock-solid for media transcoding workloads.

Preparing Your Debian Host for Docker GPU Passthrough

Before installing Docker and configuring containers, confirm your GPU works on Debian host:

NVIDIA Setup on Debian

Install NVIDIA proprietary drivers. Verify with nvidia-smi.
Install NVIDIA Container Toolkit:

sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Verify with:

docker run --rm --gpus=all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

Intel iGPU Setup

Confirm i915 kernel driver loaded:

lsmod | grep i915

Check /dev/dri device nodes exist.
Install VA-API drivers:

sudo apt install intel-media-va-driver vainfo

Verify working with vainfo.

Docker and Docker Compose Requirements for GPU Passthrough on Debian

Docker version 20.10+ (check with docker --version)
Docker Compose V2 (docker compose command, not the legacy docker-compose)
Linux kernel with cgroup v2 enabled

NVIDIA users require proper runtime configuration via nvidia-container-toolkit. Intel/AMD users need only proper device mapping and permissions.

Correct GPU Passthrough Configuration with Docker Compose on Debian

⚠️

Warning: I do not use NVIDIA or AMD hardware in my lab. Everything NVIDIA or AMD related in this post is straight from the documention.

NVIDIA Compose Example:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    ports:
      - "8096:8096"
    volumes:
      - /srv/jellyfin/config:/config
      - /srv/media:/media
    restart: unless-stopped
    runtime: nvidia
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

Intel/AMD Compose Example:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128
    user: "1000:1000"  # Adjust to your host user UID:GID
    group_add:
      - "render_gid"    # Replace with actual host render group GID
      - "video_gid"     # Replace with actual host video group GID
    ports:
      - "8096:8096"
    volumes:
      - /srv/jellyfin/config:/config
      - /srv/media:/media
    restart: unless-stopped

Sparkle Intel Arc B580 Titan The Intel Arc B580 is a transcoding powerhouse, with full hardware support for AV1, HEVC, VP9, and H.264 plus 12 GB of VRAM for smooth multi-stream 4K/8K workflows. Its 160 XMX AI engines turbocharge upscaling and media conversions, making it perfect for Plex, Jellyfin, or Docker-based media servers.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Resolving Common GPU Passthrough Issues on Debian with Docker

“no available runtime” or “could not select device driver” indicates missing NVIDIA Container Toolkit.
“no such device /dev/dri/renderD128” means device nodes not mapped or GPU drivers missing.
Permission denied errors usually stem from missing group_add for render and video groups.
Use udev rules to make permissions persistent across reboots.

Verifying GPU Access Inside Your Docker Container

For NVIDIA: Run docker run --rm --gpus=all nvidia/cuda nvidia-smi.
For Intel/AMD: Run docker run --rm --device /dev/dri:/dev/dri jrottenberg/ffmpeg ffmpeg -hwaccels and look for vaapi or qsv.

Real-World Example: Jellyfin GPU Passthrough on Debian

NVIDIA-enabled Jellyfin:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    volumes:
      - /srv/jellyfin/config:/config
      - /srv/media:/media
    ports:
      - "8096:8096"
    restart: unless-stopped
    runtime: nvidia
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

Intel iGPU Jellyfin:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128
    user: "1000:1000"
    group_add:
      - "render_gid"
      - "video_gid"
    volumes:
      - /srv/jellyfin/config:/config
      - /srv/media:/media
    ports:
      - "8096:8096"
    restart: unless-stopped

Final Tips for Installing Docker on Debian and Running GPU Passthrough on Raspberry Pi and Home Servers

Always start by verifying GPU functionality on the host Linux system.
Install Docker on Debian using the official repositories or Docker’s install script.
- My Docker install instructions
Use docker run -it with --gpus for quick NVIDIA GPU container testing.

With these steps, you can enjoy hardware-accelerated transcoding and efficient GPU usage inside Docker containers on Linux.

Other Resources

Happy transcoding with Docker!

Intel NUC 12 Pro (NUC12WSHi5) Compact mini PC for lightweight servers, GPU Passthrough, Docker stacks, and VMs.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

GPU Passthrough with Proxmox: A Practical Guide

Fri, 15 Aug 2025 05:17:37 -0600

So, you want smooth media transcoding in your Jellyfin VM running on Proxmox, and you’ve heard Intel QuickSync is that silver bullet. Or maybe you’re chasing GPU cycles for gaming, but Proxmox’s default CPU emulation just isn’t cutting it. Enter hardware passthrough: a fascinating promise of bare-metal performance wrapped in the warm hug of virtualization.

But here’s the kicker Reddit forgets to mention: halfway in, your server can just black out. Silent, unresponsive, and only revivable through SSH. Think digital coma. Good times.

If you’ve ever wrestled with PCIe passthrough, IOMMU groups, or found yourself frantically Googling “why is my Proxmox host dead after GPU passthrough?” at 2 AM, welcome to the club. The membership fee? A few gray hairs and an extra helping of existential dread. If not, congrats, and read on to keep it that way.

Let’s simplify GPU passthrough in proxmox, break down the gotchas that matter, and get you transcoding with QuickSync (or any GPU) without turning your Proxmox box into a doorstop.

💭 TL;DR

Want blazing-fast media transcodes in your Jellyfin or Plex VM? GPU passthrough lets your VM access your Intel QuickSync or discrete GPU directly—no emulation, no lag. But if you recklessly hand over your only GPU, your Proxmox host might go dark faster than your hopes during a Blue Screen of death. This guide walks you through setup, IOMMU group hell, and how to avoid turning your homelab into a brick.

ASRock Intel ARC A380 Challenger The Arc A380 isn’t for gaming, it’s for obliterating video streams. With support for H.264, HEVC, and full AV1 hardware encode/decode, it crushes 20+ 1080p streams or 6–8 HDR tone-mapped 4Ks without breaking a sweat. Drop it in your media server, give Jellyfin direct VA-API access, and watch your CPU finally cool off for a bit.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

What Is Hardware Passthrough, Really?

Think of your typical VM setup like a hotel stay. Your VM gets a comfortable room (virtualized hardware), but it shares resources with every other guest. Proxmox, our hypervisor, is the hotel manager allocating what you get and when.

Hardware passthrough is like buying out an entire floor, with an express elevator. Instead of your VM politely asking Proxmox for GPU power, you hand over the hardware directly. “This is yours, use it as you like.”

The magic? Your VM’s applications can communicate directly with the hardware, bypassing virtualization overhead. For transcoding, Intel QuickSync runs exactly as it does on bare metal—full.

But here’s the kicker: when you do proxmox pcie passthrough, you’re snatching that hardware away from the host. Was Proxmox using that GPU for the console display? Guess what just went dark?

The IOMMU Groups Reality Check

Let’s talk IOMMU groups, the mystical rules determining what hardware you can actually pass through.

IOMMU (Input-Output Memory Management Unit) groups are like apartment buildings for PCIe devices. Everything in one group shares certain pathways, so you can’t just evict one tenant, you have to pass the whole group to your VM.

Why does this matter? If your GPU shares an IOMMU group with, say, your network card, you can’t just pass through the GPU. It’s all or nothing. This is where most passthrough dreams go to die.

The good news? Most modern systems have sensible group layouts, especially for integrated graphics. Intel’s QuickSync, baked into the CPU, usually plays nice.

Pre-Flight Checklist: What You Actually Need

Before you tear apart a perfectly functional Proxmox setup, check these requirements:

Hardware Requirements:

CPU with Intel QuickSync (think almost any modern Intel CPU)
Motherboard with IOMMU/VT-d (enable in BIOS)
Enough PCIe lanes (if you’re using a discrete GPU)
Backup access to your Proxmox host (SSH, IPMI, or a secondary GPU)

❌

Danger: The Backup Access Point Crucial Detail: Don’t pass through your only graphics output to a VM without an alternative. SSH is great, until something breaks and you need console access. IPMI is king if you have it, and a basic secondary GPU for the host is even better.

Software Prerequisites:

Proxmox VE (obviously)
A guest OS that supports your hardware

Intel® Core™ i5-12500 12th Generation Desktop Processor This 12th-gen i5 packs QuickSync with UHD 770 graphics, enough to power 4K → 1080p transcodes like a champ. You’ll push 10+ simultaneous 1080p streams with near-zero CPU load. Ideal for low-power, headless Proxmox boxes that run hot and quiet. No dGPU? No problem.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Let’s be honest, if you’re here, your CPU is probably choking on media transcoding while you’re dreaming of QuickSync’s magic.

What Is GPU Passthrough and Why Should You Care?

GPU passthrough in proxmox means telling Proxmox to stop hogging your GPU and give it directly to your VM. This gives your VM the keys to the Ferrari while Proxmox walks home. For QuickSync, this means Jellyfin or any media workflow will fly through transcoding.

⚠️

Warning: Once you pass that GPU through, your Proxmox host loses access. If it’s your only GPU, the host display output goes dark. Remote access via SSH (or a serial console) is essential, not optional.

Prerequisites: What You’ll Need Before Diving In

Don’t skip the homework before shuffling hardware assignments:

CPU must support IOMMU:

Intel calls it VT-d
AMD calls it: AMD-Vi
And enable it in the BIOS (often OFF by default).

Motherboard must support IOMMU groups properly:

These groups decide what you can pass through
Some boards group devices nonsensically, making passthrough a pain.

You need remote access (SSH/IPMI):

Without it, losing your display means flying blind.
My SSH Guide

GPU isolation:

The PCIe slot should NOT share an IOMMU group with critical components, or passthrough may not work.

❌

Danger: This is the quickest way to break your server.

Checking IOMMU Groups: The Foundation

Check how your system organizes devices. On your Proxmox host:

find /sys/kernel/iommu_groups/ -type l | sort -V

It should look something like this:

/sys/kernel/iommu_groups/0/devices/0000:00:02.0
/sys/kernel/iommu_groups/1/devices/0000:00:00.0
/sys/kernel/iommu_groups/2/devices/0000:00:06.0
/sys/kernel/iommu_groups/3/devices/0000:00:14.0
/sys/kernel/iommu_groups/3/devices/0000:00:14.2
/sys/kernel/iommu_groups/4/devices/0000:00:15.0
/sys/kernel/iommu_groups/5/devices/0000:00:16.0
/sys/kernel/iommu_groups/6/devices/0000:00:17.0
/sys/kernel/iommu_groups/7/devices/0000:00:1c.0
/sys/kernel/iommu_groups/8/devices/0000:00:1c.2
/sys/kernel/iommu_groups/9/devices/0000:00:1f.0
/sys/kernel/iommu_groups/9/devices/0000:00:1f.3
/sys/kernel/iommu_groups/9/devices/0000:00:1f.4
/sys/kernel/iommu_groups/9/devices/0000:00:1f.5
/sys/kernel/iommu_groups/10/devices/0000:01:00.0
/sys/kernel/iommu_groups/11/devices/0000:02:00.0
/sys/kernel/iommu_groups/12/devices/0000:02:00.1
/sys/kernel/iommu_groups/13/devices/0000:03:00.0

To better ID what these components are run:

lspci -nn

Results:

00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4648] (rev 02)
00:02.0 VGA compatible controller [0300]: Intel Corporation AlderLake-S GT1 [8086:4680] (rev 0c)
00:06.0 PCI bridge [0604]: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #0 [8086:464d] (rev 02)
00:14.0 USB controller [0c03]: Intel Corporation Alder Lake-S PCH USB 3.2 Gen 2x2 XHCI Controller [8086:7ae0] (rev 11)
00:14.2 RAM memory [0500]: Intel Corporation Alder Lake-S PCH Shared SRAM [8086:7aa7] (rev 11)
00:15.0 Serial bus controller [0c80]: Intel Corporation Alder Lake-S PCH Serial IO I2C Controller #0 [8086:7acc] (rev 11)
00:16.0 Communication controller [0780]: Intel Corporation Alder Lake-S PCH HECI Controller #1 [8086:7ae8] (rev 11)
00:17.0 SATA controller [0106]: Intel Corporation Alder Lake-S PCH SATA Controller [AHCI Mode] [8086:7ae2] (rev 11)
00:1c.0 PCI bridge [0604]: Intel Corporation Alder Lake-S PCH PCI Express Root Port #2 [8086:7ab9] (rev 11)
00:1c.2 PCI bridge [0604]: Intel Corporation Alder Lake-S PCH PCI Express Root Port [8086:7aba] (rev 11)
00:1f.0 ISA bridge [0601]: Intel Corporation Z690 Chipset LPC/eSPI Controller [8086:7a84] (rev 11)
00:1f.3 Audio device [0403]: Intel Corporation Alder Lake-S HD Audio Controller [8086:7ad0] (rev 11)
00:1f.4 SMBus [0c05]: Intel Corporation Alder Lake-S PCH SMBus Controller [8086:7aa3] (rev 11)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Alder Lake-S PCH SPI Controller [8086:7aa4] (rev 11)
01:00.0 Non-Volatile memory controller [0108]: Sandisk Corp WD Black SN770 NVMe SSD [15b7:5017] (rev 01)
02:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
02:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 05)

Find your GPU in the output. Ideally, it stands alone or with non-essential devices. If grouped with essentials (USB, network), you might need to pass more than planned or use ACS override patches (advanced territory that I will not be covering).

You can see my GPU on 00:02.0. This is my QuickSync GPU.

Configuring Proxmox for GPU Passthrough

If your hardware checks out, congrats, now on to configuration:

1. Enable IOMMU in Proxmox:

Edit /etc/default/grub and change GRUB_CMDLINE_LINUX_DEFAULT:

nano /etc/default/grub

Intel example:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

AMD example:

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"

Update grub with:

update-grub

2. Load VFIO modules: Add these to /etc/modules:

nano /etc/modules

Paste these in:

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

3. Blacklist host GPU drivers:

For Intel iGPU (QuickSync):

echo "blacklist i915" >> /etc/modprobe.d/blacklist.conf

For NVIDIA:

echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf

For AMD:

echo "blacklist amdgpu" >> /etc/modprobe.d/blacklist.conf

4. Bind GPU to VFIO: Find your GPU’s PCI ID:

lspci -nn | grep -E "VGA|3D|Display"

Then create /etc/modprobe.d/vfio.conf:

nano /etc/modprobe.d/vfio.conf

Paste this (Replace YOUR_GUP_ID with your ID example 00:02.0):

options vfio-pci ids=YOUR_GPU_ID

5. Rebuild initramfs and reboot:

update-initramfs -u

Then reboot

reboot

VM Setup: The Fun Part

In Proxmox UI:

Edit your VM → Hardware → Add PCI Device
Select your GPU (and its audio function, if present)
Check “All Functions” and “Primary GPU” if necessary
For some VMs (Windows), you may need a matching VBIOS/ROM file
Boot VM and install drivers (Linux: intel-media-driver for QuickSync, or the Windows/OS driver you need)

Passing through both graphics and audio functions mimics real hardware. The “All Functions” and “Primary GPU” options help make the transition smooth, especially for picky OSes like Windows.

Intel NUC 12 Pro (NUC12WSHi5) Compact mini PC for lightweight servers, GPU Passthrough, Docker stacks, and VMs.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Troubleshooting: When Things Go Sideways

Proxmox PCIe passthrough feels like wizardry, until it doesn’t. If you get a black screen or your VM crashes, don’t panic:

Double-check driver blacklists: One typo can ruin your weekend
Confirm IOMMU: dmesg | grep IOMMU should show happy messages
Rely on SSH/IPMI over the local console
Check /var/log/syslog and VM logs for PCI errors
Try another PCI slot or disable peripheral devices

If your system is completely unresponsive, comment out VFIO and GPU configurations, rebuild initramfs, and reboot. Most disasters are reversible if you don’t panic.

Gotchas, Caveats, and Advanced Notes

Single-GPU pass-through disables your Proxmox host’s display.
You will lose all video output on the host, and recovery requires remote access or another GPU.

NVIDIA consumer cards may throw tantrums.
Windows “Code 43” errors can appear.
Hyper-V spoofing and other tweaks often help.

QuickSync isn’t always present—verify your CPU model.
Xeon CPUs may lack QuickSync even if they have integrated graphics.
Always check official Intel docs:
Intel Product Details

LXC vs. VM passthrough are different creatures.
LXCs share hardware via device mapping.
VMs demand exclusive, full PCI assignment.

EULA caveats for consumer GPUs in datacenters.
NVIDIA and AMD consumer cards often restrict use in virtualized environments (especially commercial/datacenter).

Common Misconceptions

Myth: Any consumer GPU works.
- Reality: Pro cards (Quadro/Radeon Pro) are better supported.
Myth: Rebooting fixes EVERYTHING.
- Reality: Sometimes you need to completely remove and re-add the GPU or reset the PCIe slot.
Myth: Passthrough is rock-solid once it boots.
- Reality: VM restarts may need extra care (cold boots, PCIe resets).

Recovery, Best Practices, and Sanity Saving

Use multiple GPUs if possible (one for Proxmox, one for your VM).
Always set up SSH or IPMI access before tinkering.
Backup /etc/pve before major changes.
Keep copies of your IOMMU and driver blacklist configs.
If locked out: Boot live USB, chroot, and reverse your changes step-by-step.

For stability:

Match your VM’s drivers to your GPU
Set VM CPU type to host or enable passthrough
Only pass through required PCI devices

Successful GPU passthrough means less troubleshooting, and more transcoding, and/or gaming.

Wrapping Up: Your QuickSync/VM-Turbocharging Journey

GPU passthrough on Proxmox is like taming a clever, unpredictable cat. When it works, your VM doesn’t know it’s virtual anymore, and you’ll watch QuickSync or your RTX card rev through tasks you once thought were impossible. However, when it doesn’t… you’ll become very familiar with the recovery console.

Key Takeaways:

Passthrough gives your VM direct hardware access but your host loses it. Plan accordingly.
Never pass through your last GPU unless you’re ready for a headless server.
IOMMU groups, BIOS settings, and Proxmox module configs must all align.
Backup before making changes.
Know your command line for when things go wrong, it’s your lifeline.

The beauty of proxmox pcie passthrough is in blending virtualization flexibility with true GPU performance. Once you nail it, your gpu passthrough virtual machine setup will deliver transcoding, and gaming power without compromise.

Need more information?

Now go forth and make your hardware dance. Your QuickSync and GPU passthrough adventure in Proxmox awaits!

MINISFORUM MS-A2 A Ryzen-powered beast in a mini PC shell. Dual 2.5GbE, 10GbE option, triple NVMe. Small box, big Proxmox energy.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Master the Basics - SMB Guide for Media Servers

Sat, 09 Aug 2025 05:53:49 -0600

You’ve got files. You’ve got machines. And you’re tired of playing sneakernet with USB sticks like some kind of caveman.

What you want is simple: a shared folder that every device on your network can see. Windows boxes. Macs. That crusty ThinkPad running Ubuntu in the corner. Even your “smart” TV that somehow needs to stream 4K remuxes but can’t figure out basic networking.

Enter Samba. It’s your network’s Swiss Army knife, part bouncer, part bartender, part DJ. And once you set it up right, it just works.

💭 TL;DR

Samba turns your Linux box into a file server that every device on your network can actually use. We'll skip the garbage defaults and build something that streams 4K without stuttering and doesn't require a PhD to troubleshoot.

UGREEN NASync DXP4800 Plus 4-Bay Desktop NAS UGREEN NASync DXP4800, 4-Bay NAS with Intel N100 Quad-Core CPU (Up to 3.4GHz) 8GB DDR5, 2x M.2 PCIe Slots and a 2.5GbE Port (Diskless). This is perfect if you don’t want to DIY your NAS.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

When SMB Is Your Best Friend

SMB shines in these scenarios:

Mixed OS chaos: Windows, macOS, Linux all playing nice together. No more “sorry, your OS isn’t supported.”
Apps that demand SMB: Time Machine backups. Windows Explorer mapping. Kodi libraries. Sonos music folders. They speak SMB or they speak nothing.
User-based security: You decide who gets in and what they can touch. No more “everyone has access to everything” nonsense.
Dumb devices: Your smart TV, IoT gadgets, and network printers don’t know NFS from a hole in the ground. But they know SMB.
Cross-platform development: Same project folder on Windows, Mac, and Linux. No sync conflicts, no version hell.

Skip SMB When…

Linux-only network: NFS is faster, simpler, and doesn’t carry Windows baggage.
Remote access: SSHFS or WebDAV won’t make you cry when you’re connecting over WAN.

Install Samba (Debian/Ubuntu)

Install the samba package:

sudo apt update && sudo apt install samba

That’s it. No package maze, no dependency hell.

Now set the Samba user’s password. This is not optional:

sudo smbpasswd -a yourusername

⚠️

Warning: Why this matters: Samba uses its own password database. Your Linux user exists? Great. But without smbpasswd, you’re locked out. I’ve watched too many people bang their head against “authentication failed” errors because they skipped this step.

Start the services:

sudo systemctl enable --now smbd nmbd

Configuration File That Actually Works

Time to ditch the ancient defaults in /etc/samba/smb.conf. Here’s what you actually need.

`[global]` Settings: With Large File Transfers and Security in Mind

[global]
  workgroup = WORKGROUP
  netbios name = MEDIA-SERVER
  server string = %h server (Samba %v)
  
  # Security that makes sense
  security = user
  map to guest = Bad User
  
  # Force modern protocols
  server min protocol = SMB2
  server max protocol = SMB3
  client min protocol = SMB2
  
  # Encrypt everything
  smb encrypt = required

  # Disable insecure features
  lanman auth = no
  ntlm auth = no

  # Kill anonymous access
  restrict anonymous = 2

  # Network optimizations
  socket options = TCP_NODELAY SO_RCVBUF=131072 SO_SNDBUF=131072

  # File transfer optimization
  use sendfile = yes

  # Async I/O for large files
  aio read size = 16384
  aio write size = 16384

  # Reduce metadata overhead
  strict allocate = yes
  
  # Logging that helps
  log file = /var/log/samba/log.%m
  max log size = 1000
  
  # Stop being a DNS server
  dns proxy = no

Why these settings work:

security = user: Per-user authentication. Not “everyone’s admin” madness.
map to guest = Bad User: Invalid usernames become guest access (if you allow it).
server min/max protocol: Forces SMB2/3, ditches the security nightmare that is SMB1.
dns proxy = no: Samba shouldn’t handle DNS. That’s your DNS server’s job.
smb encrypt = required: All traffic encrypted. No plaintext passwords floating around.
restrict anonymous = 2: Kills guest browsing and anonymous enumeration.
lanman/ntlm auth = no: Forces modern authentication methods.

`[share]` Definition: Where the Magic Happens

[media]
  path = /media/storage
  browseable = yes
  read only = no
  guest ok = no
  valid users = yourusername
  force user = yourusername
  create mask = 0660
  directory mask = 0770

Why this configuration works:

force user/group: Every file gets the same owner. No more permission spaghetti.
create/directory mask: Sane default permissions. Files get 660, directories get 770.
browseable = yes: Shows up in Windows Network Explorer without extra clicking.
guest ok = no: Authentication required. Because security matters.

TP-Link 2.5GB PCIe Network Card (TX201) Plug-and-play 2.5GbE PCIe card that unlocks multi-gig speeds for about $30. Works out of the box with Proxmox, Linux, and Windows. No drama—just faster transfers.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Troubleshooting: Fix the Usual Suspects

Check your configuration:

sudo testparm

Test shares without leaving the server:

smbclient -L localhost -U yourusername

Check Samba’s view of connected users:

sudo smbstatus

Watch logs live:

tail -f /var/log/samba/log.smbd

Flush config changes without a reboot:

sudo systemctl restart smbd nmbd

Common Problems, Fast Fixes

“Access denied” but login works:

Check Linux filesystem permissions
Verify valid users matches actual usernames

Share invisible in Windows:

Add netbios name to [global]
Restart both services: sudo systemctl restart smbd nmbd
Windows sometimes caches old network info. Reboot the client.

Slow transfers:

Enable use sendfile = yes
Check your network. Gigabit wired > WiFi > carrier pigeon
Large files? Enable async I/O settings above

“Mount error: Protocol not supported”:

Client trying to use SMB1
Fix: mount -t cifs //server/share /mnt -o vers=3.0

The Nuclear Option:

When nothing else works: Stop samba:

sudo systemctl stop smbd nmbd

Remove samba’s cache files:

sudo rm /var/cache/samba/*

Start samba

sudo systemctl start smbd nmbd

Real-World Scenarios

Media Server Hub:

Point Jellyfin, Plex, or Kodi at your SMB share. Works across containers, VMs, and bare metal. One library, every device.
Development Folder

Same codebase accessible from your Windows IDE, Mac laptop, and Linux server. No git commits just to move files around.
Backup Target

Time Machine over SMB. Veeam backups. Even rsync via mounted shares. Central storage that everything can hit.
Cheap NAS Alternative

Old PC + big drives + Samba = network storage that doesn’t cost $800.

SMB vs. The Alternatives

Feature	SMB	NFS	SSHFS
Windows native	✅	❌	❌
macOS native	✅	❌	❌
Performance (LAN)	Good	Excellent	Okay
Security over WAN	❌	❌	✅
Setup complexity	Medium	Low	High
Device compatibility	Excellent	Poor	Poor

The verdict:

SMB wins on compatibility.
NFS wins on pure speed.
SSHFS wins on security.

Pick your poison based on what matters most.

The mac Update That Broke Everything

Client calls at 5 PM. “My media server just died.” Nothing changed on his end except a macOS update.

The culprit? Apple dropped SMB1 support. His Samba config was still allowing the old protocol, and macOS decided it wasn’t secure enough anymore.

One line in /etc/samba/smb.conf:

server min protocol = SMB2

Five minutes later, his movie night was back on track.

Lesson learned: Always set your protocol minimums. Let the OS updates come. You’ll be ready.

The Bottom Line

Samba isn’t sexy. It’s not the hot new container orchestration platform. It doesn’t have a JavaScript framework named after it.

But it works. It connects everything to everything else. And once you configure it right, it fades into the background and just does its job.

That’s the best kind of technology.

Your Network, Your Rules

Stop wrestling with cloud sync conflicts and USB cable hell. Set up a proper SMB share. Stream your movies without stuttering. Back up your machines to something you control.

Because when you run your own file server, you’re not just sharing files, you’re taking back control of your data. And that’s worth the thirty minutes it takes to get Samba running right.

Ready to build something that works? Start with the basic config above, test it with one device, then expand from there. Your future self will thank you when everything just connects.

Seagate Barracuda 24TB Internal Hard Drive

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Master the Basics - NFS Guide for Media Servers

Sat, 02 Aug 2025 07:46:39 -0600

You spin up an NFS share and think you’re done. Your media server is humming, files are flowing, everything looks perfect. But here’s what you probably missed: you just gave every client’s root user complete administrative access to your server. That “quick setup” you found online? It basically handed out master keys to anyone on your network.

Don’t panic. We’ve all been there. The good news? Setting up NFS properly isn’t rocket science once you understand what’s actually happening under the hood. Let me walk you through building an NFS setup that’s fast, secure, and won’t make you lose sleep at night.

💭 TL;DR

Use `root_squash` to keep remote root users from becoming your new system admin. Lock down access to specific trusted IPs, not your entire network. Always use `sync` because files sitting in memory aren't actually saved files, they're just hopes. Never touch `no_root_squash` unless you'd literally give that client machine your banking passwords. Get your user IDs sorted across all systems, or use `all_squash` to sidestep the whole mess.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Why NFS Matters for Your Home Lab

Network File System (NFS) is the backbone of most serious home media setups. Unlike Samba (which can be sluggish) or FTP (which is a pain for media apps), NFS gives you near-native filesystem performance across your network. Your Jellyfin server, Sonarr, Radarr, and download clients can all share the same storage seamlessly.

But here’s the catch: NFS was designed back when networks were trusted and security was someone else’s problem. It assumes every client is honest about who they are. Spoiler alert: that’s not how the real world works.

Understanding NFS Security: Why Your Setup Matters

Before we dive into the technical stuff, let’s talk about why NFS security isn’t just paranoid overthinking. When you share a folder via NFS, you’re essentially saying “hey network, here’s some storage you can use.” The problem is that NFS trusts whatever user ID (UID) the client claims to be.

Think about it: if your client machine says “hey, I’m root (UID 0), give me access,” NFS just shrugs and says “sure thing, boss.” That client can now read, write, delete, and modify permissions on anything in your share. Not exactly what you had in mind when you just wanted to stream some movies.

This is where “squashing” comes in. This is NFS’s way of saying “I don’t care who you claim to be, you’re getting mapped to this safe user instead.”

Setting Up the NFS Server

Install NFS server:

sudo apt update && sudo apt install nfs-kernel-server

Create your share directory. For media servers, something like /media/storage:

Create the folder:

sudo mkdir -p /media/storage

Set the ownership of the folder:

sudo chown -R nobody:nogroup /media/storage

Set the permissions on the folder:

sudo chmod 755 /media/storage

💡

Tip: Why nobody:nogroup? This gives us a safe default owner that unprivileged processes can work with.

Configure Your Exports

Open up /etc/exports in your favorite editor and add your share configuration. Here’s where the magic happens:

/media/storage 192.168.1.0/24(rw,sync,no_subtree_check,root_squash)

Let’s break this down:

/srv/media: The directory you’re sharing
192.168.1.0/24: Your network subnet (adjust this to match your actual network)
rw: Read-write access
sync: Wait for writes to complete before responding (more on this later)
no_subtree_check: Skip path validation for better performance
root_squash: Map remote root to nobody user

Apply and Start NFS

sudo exportfs -ra sudo systemctl restart nfs-kernel-server sudo systemctl enable nfs-kernel-server

Note: The -ra flag tells NFS to re-export all shares and apply your new configuration.

NFS Squash Options: Your Security Toolkit

This is where most people get confused, so let’s make it crystal clear.

root_squash: The Sensible Default

/media/storage 192.168.1.100(rw,sync,root_squash)

When you use root_squash, any client claiming to be root (UID 0) gets mapped to the nobody user instead. This means:

Root can’t change file ownership
Root can’t set special permissions
Root can’t access files owned by other users
Your server stays safe from root-level shenanigans

Use this for: Pretty much everything unless you have a specific reason not to.

all_squash: Maximum Security (This is what I use)

/media/storage 192.168.1.100(rw,sync,all_squash,anonuid=1000,anongid=1000)

With all_squash, everyone gets mapped to the anonymous user you specify. This is like having a shared account where nobody can tell who did what.

💡

Tip: Use this for: Public drop folders, backup destinations, or anywhere you want maximum simplicity and security.

no_root_squash: Danger Zone

/media/storage 192.168.1.100(rw,sync,no_root_squash)

This disables squashing entirely. Remote root stays root with full privileges.

❌

Danger: Use this for: Honestly? Almost never in a home setup. Maybe for Proxmox backup storage or if you’re doing system imaging. Just remember: only use this if you’d trust that client with SSH root access to your server.

Option	Who’s Root on Client	Permissions on Server	Best For	Danger Level
`root_squash`	Root becomes `nfsnobody`	Limited, can’t chown/setuid	Multi-user environments	🟢 Low
`all_squash`	Everyone becomes `anonuid`	Everyone writes as same safe user	Guest shares, dropzones	🟡 Medium
`no_root_squash`	Root stays root	Full control	Proxmox backups (maybe)	🔴 High

NFS Client Setup: Connecting the Pieces

Now let’s get your client machines connected properly.

Install Client Tools

sudo apt update && sudo apt install nfs-common

Create Mount Points

sudo mkdir -p /mnt/media

Test Your Connection

Before making anything permanent, test your mount:

sudo mount -t nfs 192.168.1.5:/media/storage /mnt/media

If this works, you should be able to ls /mnt/media and see your shared content.

Make It Permanent

Add this line to /etc/fstab to mount automatically on boot:

192.168.1.5:/media/storage /mnt/media nfs defaults,nfsvers=4,hard,intr 0 0

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Additional Details

The sync vs async Debate: Why Data Integrity Matters

Here’s a crucial decision that affects both performance and safety.

sync: The Safe Choice

With sync, your NFS server waits for each write to actually hit the disk before telling the client “yep, that’s saved.” It’s slower, but your data is actually safe.

async: The Fast and Furious Option

With async, the server says “sure, I’ll save that” and returns immediately, even if the data is still sitting in memory. It’s faster, but if your server crashes, you might lose recent writes.

The verdict: Use sync unless you’re running benchmarks or you enjoy living dangerously. Your media library is worth the small performance hit.

Solving the UID/GID Nightmare

This is where many NFS setups fall apart. Here’s the problem: your Jellyfin server runs as user ID 998 on one machine, but your download client runs as user ID 1001 on another. When they try to access the same files over NFS, permissions explode.

The Manual Approach

Align user IDs across all your machines:

# On each client machine
sudo usermod -u 1000 jellyfin
sudo usermod -u 1000 sonarr
sudo groupmod -g 1000 media

The Group Approach (Recommended)

Create a shared group and add all your media services to it:

# On the NFS server
sudo groupadd -g 2000 mediausers
sudo chgrp -R mediausers /media/storage
sudo chmod -R 775 /media/storage

# On each client
sudo usermod -a -G mediausers jellyfin
sudo usermod -a -G mediausers sonarr

This way, everyone in the mediausers group can read and write, regardless of their individual user IDs.

NFSv3 vs NFSv4: Choosing Your Version

Understanding the differences helps you make the right choice.

NFSv3: The Old Reliable

Uses multiple ports (2049 plus random high ports)
Separate daemons for locking and status
Simpler protocol, potentially faster for basic operations
Pain in the neck for firewalls

NFSv4: The Modern Choice

Single port (2049)
Built-in locking and security
Better support for ACLs and modern features
Slightly more overhead but much easier to secure

💡

Tip: Go with NFSv4 unless you have specific legacy requirements. It’s easier to firewall and generally more robust.

Mount Options That Actually Matter

The default mount options are okay, but you can do better:

192.168.1.5:/media/storage /mnt/media nfs hard,intr,nfsvers=4,rsize=1048576,wsize=1048576,noatime 0 0

Let’s break down what each option does:

hard: Don’t give up on network failures, keep retrying
intr: Allow interruption with Ctrl+C if things get stuck
nfsvers=4: Force NFSv4 for better security and single-port operation
rsize/wsize=1048576: Use 1MB read/write buffers for better performance
noatime: Don’t update access timestamps, reduces I/O overhead

Docker and NFS: The Right Way

Here’s a common mistake: mounting NFS shares directly inside Docker containers. Don’t do this. It’s unreliable and causes weird permission issues.

Instead, mount NFS on your Docker host and bind-mount into containers:

# Mount on the host first
sudo mount 192.168.1.5:/media/storage /mnt/media

# Then use in docker-compose.yml
    volumes:
      - /mnt/media:/data/movies
    user: "1000:1000"  # Match your media user

This approach is more reliable and gives you better control over permissions.

Firewall Configuration: Locking Down Access

Out of the box, NFSv3 can open multiple ports, which is a security nightmare. Here’s how to lock it down:

For NFSv3 (If You Must)

You’ll need to pin the additional services to specific ports. Add this to /etc/default/nfs-kernel-server:

RPCMOUNTDOPTS="--manage-gids --port 32767"
STATDOPTS="--port 32765 --outgoing-port 32766"

Then restart NFS and open the ports:

sudo systemctl restart nfs-kernel-server
sudo ufw allow from 192.168.1.0/24 to any port 2049
sudo ufw allow from 192.168.1.0/24 to any port 32765:32767

For NFSv4 (Recommended)

sudo ufw allow from 192.168.1.0/24 to any port 2049

Common NFS Problems and How to Fix Them

Stale File Handles

This happens when you move or delete files on the server while clients are accessing them. The fix is usually a remount:

sudo umount /mnt/media
sudo mount 192.168.1.5:/media/storage /mnt/media

To prevent this, avoid editing files directly on the NFS share. Instead, work on files locally and then move them into place when complete.

For example, if you’re processing a video file, edit it in /tmp/processing/movie.mkv and then mv /tmp/processing/movie.mkv to /mnt/media/movies/movie.mkv when done. This way, NFS clients either see the old file or the new file, never a half-written mess that causes stale handles.

Performance Issues

If NFS feels slow:

Check your network, gigabit Ethernet minimum for media streaming
Verify your disk I/O isn’t the bottleneck with iostat -x 1
Try increasing rsize/wsize values in your mount options
Consider NFSv4 if you’re still on v3

Permission Denied Errors

Usually a UID/GID mismatch. Check:

What user/group owns the files on the server?
What user/group is your client process running as?
Are your squash settings allowing the access you need?

Performance Tuning and Benchmarking

Don’t just assume your NFS setup is fast, measure it:

Basic Write Test

dd if=/dev/zero of=/mnt/media/testfile bs=1M count=1000

Real-World Performance Testing

Install fio for more realistic testing:

sudo apt install fio

Test random read/write (simulates media streaming)

fio --name=nfs-test --ioengine=libaio --rw=randrw --bs=64k --size=1G --numjobs=4 --runtime=60 --group_reporting --filename=/mnt/media/fiotest

Look for:

Sustained throughput above 100MB/s for 4K media streaming
Low latency (under 10ms for most operations)
No dramatic performance drops under load

Advanced Security: Beyond Basic IP Filtering

Using hosts.allow and hosts.deny

Add an extra layer of access control: Add this to /etc/hosts.allow:

rpcbind mountd nfsd statd lockd rquotad : 192.168.1.0/24

Add this to /etc/hosts.deny:

rpcbind mountd nfsd statd lockd rquotad : ALL

Network Segmentation

Consider putting your NFS traffic on a dedicated VLAN or subnet. This limits the blast radius if something goes wrong and makes monitoring easier.

Your NFS Pre-Flight Checklist

Before you call your setup “done,” verify:

✅ Squash options are configured for your security needs
✅ You’re using sync for data safety
✅ no_subtree_check is enabled for performance
✅ IP restrictions are tight and tested from allowed/denied hosts
✅ Firewall rules only allow access from trusted networks
✅ User IDs are aligned or properly squashed
✅ Docker containers use host bind mounts, not direct NFS mounts
✅ Mount options include hard,intr,nfsvers=4
✅ You’ve tested normal operations and permissions

Wrapping Up: NFS That Actually Works

Look, anyone can copy-paste some commands and get NFS technically functioning. But there’s a massive difference between “technically working” and “rock-solid reliable.” One approach gets you streaming tonight but leaves you troubleshooting permission disasters next month. The other gets you streaming tonight and still working flawlessly two years from now.

The security stuff isn’t paranoia, it’s insurance. Those squash settings and firewall rules seem like overkill until the day they save you from a client machine that’s been compromised or misconfigured. Your media server should be boring in the best possible way: it just works, day after day, without drama.

When you’ve done NFS right, you’ll forget it exists. Your Jellyfin scans will run smoothly, your download clients will move files without hiccups, and you’ll never get woken up by permission errors. That’s not luck, that’s good engineering.

Build it once, build it right, then move on to the next cool project in your lab. Your future self will thank you for not cutting corners.

Seagate Barracuda 24TB Internal Hard Drive

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Jellyfin + Intel QuickSync in Unprivileged LXC - The Complete Guide

Sat, 26 Jul 2025 07:46:41 -0600

Why Everyone Gets This Wrong

People treat unprivileged LXC like it’s cursed black magic. “You can’t do NFS!” “GPU passthrough is impossible!” “Just use a VM, it’s easier!”

Complete bullshit.

You absolutely can run Jellyfin with Intel QuickSync transcoding in an unprivileged LXC container. The problem isn’t the technology, it’s that most tutorials skip the crucial details or rely on hacky workarounds that break on the first system update.

This guide walks you through the proper way to set up hardware-accelerated Jellyfin transcoding in an unprivileged LXC on Proxmox. No sketchy scripts. No Snap packages. No privileged containers. Just clean, secure, transcoding.

💭 TL;DR

Yes, Intel QuickSync works in unprivileged LXC. All you need is to give the container access to the GPU, map its group IDs to match the host, install Intel drivers and Jellyfin using APT (not Snap), and flip the hardware transcoding switch in Jellyfin. The result? A secure, lightweight setup that chews through simultaneous 1080p streams without breaking a sweat.

Why VMs Are Overkill for This Job

Before we dive in, let’s destroy the lazy “just use a VM” argument once and for all.

The Resource Waste is Criminal

Running Jellyfin in a VM means you’re literally wasting resources you paid for:

Memory: 512MB-1GB VM overhead vs. 10-20MB for LXC
Storage: 12-20GB VM footprint vs. 400-800MB container
Boot time: 30-60 seconds vs. 2-5 seconds
Backups: 10-20GB snapshots vs. 200-500MB

On a typical 16GB homelab box, that VM overhead costs you 2-3 additional services you could be running.

GPU Passthrough Complexity

VM route: VFIO setup, IOMMU groups, driver blacklisting, potential single-GPU nightmares.
LXC route: Map device nodes. Done.

Every disk I/O and network packet in a VM goes through unnecessary virtualization layers. LXC gives you direct host kernel access with zero translation overhead.

The “Easier” Myth

People claim VMs are “easier” because they’re familiar. That’s not easier. That’s just lazy. You are wasting resources, creating a more complex GPU passthrough, larger backups, and full OS maintenance overhead for zero benefit. VMs make sense for different kernels, untrusted workloads, or legacy apps that need system control. For a media server? Not so much.

The Real Reason

Fear. Fear of learning device mapping. Fear of doing things better instead of familiar. This guide eliminates that fear. Once you understand LXC device passthrough, you’ll wonder why you ever considered wasting resources on a VM for simple application hosting.

Prerequisites: What You Need

Hardware Requirements

Intel 8th gen CPU or newer with integrated graphics (Coffee Lake+)
QuickSync support enabled in BIOS
Proxmox VE 7.0+ host

Intel® Core™ i5-12500 12th Generation Desktop Processor

Forget GPUs. This 12th-gen i5 packs QuickSync with UHD 770 graphics, enough to power 4K → 1080p transcodes like a champ. You’ll push 10+ simultaneous 1080p streams with near-zero CPU load. Ideal for low-power, headless Proxmox boxes that run hot and quiet. No dGPU? No problem.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Supported Codecs

Intel QuickSync can hardware-accelerate:

H.264 (AVC) - encode/decode
H.265 (HEVC) - encode/decode (9th gen+)
VP9 - decode only (some newer CPUs)
AV1 - decode only (12th gen+)

❌

Danger:

This is an in-depth topic.

Any missed or skipped details could casue Quicksync transcoding to not work correctly.

All commands and confs have been tested and re-tested to ensure everything is accurate.

Step 1: Verify Your Hardware Setup

Before diving into container configuration, confirm your hardware is ready.

Check iGPU Detection

On your Proxmox host:

ls -la /dev/dri/

You should see something like:

crw-rw---- 1 root video 226,   0 card0
crw-rw---- 1 root render 226, 128 renderD128

card0 - Display interface (major:minor = 226:0)
renderD128 - Render interface for compute (major:minor = 226:128)

Understanding Device Major:Minor Numbers

When you see 226:0 and 226:128 in the GPU device configuration, these aren’t random numbers, they’re part of Linux’s device identification system. Understanding them is crucial for GPU passthrough because you need to grant the container permission to access these specific device numbers.

What the Hell Are Major:Minor Device Numbers?

In Linux, every hardware device is represented by a file in /dev/. But don’t get too excited, are not files you can open and modify. They are more like hotline numbers that the kernel uses to dial up the right hardware driver.

Each device file has two ID numbers:

Major Number: Identifies the device driver/subsystem
Minor Number: Identifies the specific device within that subsystem

Think of it like a phone system:

Major number = Area code (which phone company/region)
Minor number = Local number (which specific phone)

Load Intel Graphics Driver

Ensure the i915 kernel module is loaded:

lsmod | grep i915

Load if missing:

modprobe i915

Make persistent across reboots:

echo "i915" >> /etc/modules

Verify QuickSync Capability

Install tools if not present:

apt install intel-gpu-tools vainfo intel-media-va-driver-non-free

Check available encoders

vainfo | grep -i enc

Look for entries like:

      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileHEVCMain               : VAEntrypointEncSliceLP
      VAProfileHEVCMain10             : VAEntrypointEncSliceLP
      VAProfileVP9Profile0            : VAEntrypointEncSliceLP
      VAProfileVP9Profile1            : VAEntrypointEncSliceLP
      VAProfileVP9Profile2            : VAEntrypointEncSliceLP
      VAProfileVP9Profile3            : VAEntrypointEncSliceLP
      VAProfileHEVCMain444            : VAEntrypointEncSliceLP
      VAProfileHEVCMain444_10         : VAEntrypointEncSliceLP
      VAProfileHEVCSccMain            : VAEntrypointEncSliceLP
      VAProfileHEVCSccMain10          : VAEntrypointEncSliceLP
      VAProfileHEVCSccMain444         : VAEntrypointEncSliceLP
      VAProfileHEVCSccMain444_10      : VAEntrypointEncSliceLP

If you don’t see these, your CPU might not support QuickSync or it’s disabled in BIOS.

ASRock Intel ARC A380 Challenger
The Arc A380 isn’t for gaming—it’s for obliterating video streams. With support for H.264, HEVC, and full AV1 hardware encode/decode, it crushes 20+ 1080p streams or 6–8 HDR tone-mapped 4Ks without breaking a sweat. Drop it in your media server, give Jellyfin direct VA-API access, and watch your CPU finally cool off for a bit.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Step 2: Create the LXC Container

In Proxmox web interface:

Create CT → Use Ubuntu 24.04 LTS template (Jellyfin prefers Ubuntu over Debian)
Keep “Unprivileged” checked (this is crucial)
Resources:
- CPU: 2-4 cores
- RAM: 2GB minimum, 4GB recommended
- Disk: 80GB+ for Jellyfin metadata and cache
Network: Bridge to your main network
Don’t start the container yet

Step 3: Configure Device Access

This is where the magic happens. Edit /etc/pve/lxc/<CTID>.conf and add:

Allow access to DRI devices:

lxc.cgroup2.devices.allow: c 226:0 rwm
lxc.cgroup2.devices.allow: c 226:128 rwm

Mount DRI devices into container:

lxc.mount.entry: /dev/dri/ dev/dri/ none bind,optional,create=dir

What These Lines Do

lxc.cgroup2.devices.allow - Grants permission to access specific device nodes
lxc.mount.entry - Bind mounts the entire /dev/dri directory into the container

Step 4: Handle Group ID Mapping (Critical!)

This step trips up 90% of people attempting GPU passthrough. Why: Unprivileged LXC containers use user namespaces to isolate processes, which means group IDs inside the container don’t directly correspond to group IDs on the host. Without proper mapping, your container processes can’t access the GPU devices even if the device files are present.

Understanding User Namespaces and ID Mapping

When Proxmox creates an unprivileged container, it maps container user/group IDs to a range of IDs on the host system. By default:

Container UID/GID 0 (root) → Host UID/GID 100000
Container UID/GID 1 → Host UID/GID 100001
Container UID/GID 1000 → Host UID/GID 101000
And so on…

This means when a process inside the container tries to access /dev/dri/renderD128 (owned by group ID 104 on the host), the kernel sees it as an access attempt from group ID 100104, which doesn’t exist and has no permissions.

The ID Mapping Strategy

We need to create “holes” in the default mapping to let specific container group IDs map directly to host group IDs. Think of it like creating bridges between the container and host for specific groups while keeping everything else isolated. This is similar to how firewall rules work.

Find the Host Group ID of

On the Proxmox host:

ls -n /dev/dri/renderD128

Output example:

crw-rw---- 1 0 104 226, 128 Nov 15 10:30 /dev/dri/renderD128

Breaking this down:

crw-rw---- = Character device with read/write for owner/group
0 = Owner UID (root)
104 = Group ID that owns the device (usually render group)
226, 128 = Major:minor device numbers

The 104 is what we need to remember. This is the host group ID we need to map later.

Standardize GPU Device Ownership

Instead of dealing with potentially different group IDs for different GPU devices, let’s ensure both GPU devices use the same group:

Change the group for card0

chgrp render /dev/dri/card0

Make it persistent:

echo 'SUBSYSTEM=="drm", KERNEL=="card0", GROUP="render", MODE="0660"' > /etc/udev/rules.d/99-render.rules
udevadm control --reload-rules && udevadm trigger

Now both card0 and renderD128 should be owned by the same group ID (usually 104 for render).

Create User in Container

Start the container and enter the console to create the Jellyfin user:

adduser jellyfin --system --group --home /var/lib/jellyfin

Create the group render

groupadd -g 993 render

Add the render group to the Jellyfin user:

usermod -aG render,media jellyfin

Why GID 993?

We’re going to map container GID 993 to host GID 104 (the render group).
The choice of 993 is arbitrary, it just needs to be:

Available in the container (not already used)
Consistent with our mapping configuration

Show the group IDs of the user jellyfin:

id jellyfin

Make sure the 993 render group is listed.

Configure ID Mapping

⚠️

Warning: This assumes your are using the group media with an ID of 1001 to access your media.
If yours is diffrent replace any refernces to media and 1001 with your own.

Stop the container and edit /etc/pve/lxc/<CTID>.conf:
Map container UIDs/GIDs to host:

lxc.idmap: u 0 100000 65536
lxc.idmap: g 0 100000 993
lxc.idmap: g 993 104 1
lxc.idmap: g 994 100994 7
lxc.idmap: g 1001 1001 1
lxc.idmap: g 1002 101002 64534

Detailed Breaking Down Each Mapping Line:

lxc.idmap: u 0 100000 65536

Maps all container UIDs (user IDs) normally
Container UID 0 → Host UID 100000
Maps 65536 UIDs total (standard range)
This line handles all user accounts

lxc.idmap: g 0 100000 993

Maps container GIDs 0-992 to host GIDs 100000-100992
This is the “normal” mapping for system groups
Stops at 992 to leave room for our special mapping

lxc.idmap: g 993 104 1

This is the critical line.
Maps container GID 993 → host GID 104 (render group)
Only maps 1 GID (just this specific group)
This creates our bridge to GPU device access

lxc.idmap: g 994 100994 7

Resumes normal mapping for GIDs 994-1000
Maps to host GIDs 100994-101000
Fills the gap between our special mapping and media group

lxc.idmap: g 1001 1001 1

Maps container GID 1001 → host GID 1001 (media group)
Assumes your media files are owned by GID 1001
Adjust this to match your actual media group ID

lxc.idmap: g 1002 101002 64534

Resumes normal mapping for all remaining GIDs
Maps container GIDs 1002-65535 → host GIDs 101002-165535
Handles any additional groups that might be created

Update Host Subordinate GIDs

On the Proxmox host add the render and media groups to the subgid file:

echo "root:104:1" >> /etc/subgid

and

echo "root:1001:1" >> /etc/subgid

This tells the system that the root user (which manages LXC containers) can map:

Host GID 104 (render group) into containers
Host GID 1001 (media group) into containers

Step 5: Install Software Stack

Start the container and install the required packages:

Update package lists:

apt update && apt upgrade -y

Install Intel GPU drivers and tools

apt install intel-gpu-tools intel-media-va-driver libdrm-intel1 vainfo curl gnupg software-properties-common -y

Add Jellyfin repository:

Pull the gpg key:

curl -fsSL https://repo.jellyfin.org/jellyfin_team.gpg.key | gpg --dearmor -o /usr/share/keyrings/jellyfin-archive-keyring.gpg

Add the Repository:

echo "deb [signed-by=/usr/share/keyrings/jellyfin-archive-keyring.gpg] https://repo.jellyfin.org/ubuntu $(lsb_release -cs) main" > /etc/apt/sources.list.d/jellyfin.list

Install Jellyfin:

apt update && apt install jellyfin -y

Why Not Snap/Flatpak/Docker?

Snap: Broken device access due to confinement
Flatpak: Similar sandboxing issues
Docker: Adds unnecessary complexity to device mapping

APT packages have proper system integration and device access.

Step 6: Verify Device Access

Check Device Permissions

Inside the container:

ls -la /dev/dri/

You should see:

crw-rw---- 1 nobody render 226,   0 card0
crw-rw---- 1 nobody render 226, 128 renderD128

If the group isn’t render, you need to check your:

lxc.mount.entry and/or lxc.idmap entries in the LXC conf file.

Test Hardware Acceleration

Read Test:

sudo -u jellyfin test -r /dev/dri/renderD128 && echo "Readable"

Write Test:

sudo -u jellyfin test -w /dev/dri/renderD128 && echo "Writable"

Step 7: Configure Jellyfin

Access Web Interface

Navigate to http://<container-ip>:8096 and complete the initial setup wizard.

Enable Hardware Acceleration

Dashboard → Playback → Transcoding
Hardware acceleration: Intel QuickSync (QSV)
Enable hardware decoding for: H264, HEVC, VP9 (as supported)
Enable hardware encoding: Yes
Enable VPP Tone mapping: Yes (for HDR content)
Save

Advanced Settings

For better performance:

Allow encoding in HEVC format: Yes (if supported)
Transcoding thread count: Auto

Need a Mini Server?

The DeskMini B760 is a compact and powerful barebone system perfect for homelab use. It supports 14th Gen Intel CPUs, dual DDR4 RAM up to 64GB, and fast storage via M.2 slots plus dual 2.5" drive bays. It’s ideal for running lightweight VMs and/or containers.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Step 8: Test Hardware Transcoding

Force Transcoding Test

Upload a high-bitrate H.264/HEVC video to Jellyfin
Start playback and immediately change quality to force transcoding
On the Proxmox host (not in container) run:

intel_gpu_top

You should see spikes in the Video engine usage during transcoding.

Browser Verification

In Chrome/Edge:

Navigate to chrome://media-internals/
Start playing your test video
Look for:
- video_codec: h264 or hevc
- hardwareAccelerated: true

Jellyfin Dashboard

Check Dashboard → Activity for active transcodes. Hardware transcoding shows much lower CPU usage than software.

Troubleshooting Guide

Problem	Symptoms	Solution
No /dev/dri in container	Missing device files	Check `lxc.mount.entry` in config
Permission denied on GPU	“Cannot access /dev/dri/renderD128”	Fix GID mapping or group membership
vainfo fails	“libva error” or crashes	Normal in LXC - test via Jellyfin instead
CPU still transcoding	High CPU usage during playback	Enable QSV in Jellyfin playback settings
Transcoding fails entirely	Playback errors or fallback to direct play	Check Jellyfin logs for codec support issues
GPU owned by wrong group	Device shows render/video instead of jellyfin	Map to correct host group ID

Advanced Debugging

Check Jellyfin logs:

tail -f /var/log/jellyfin/jellyfin.log

Verify codec support:

ffmpeg -hide_banner -encoders | grep qsv

Performance Expectations

Transcoding Capacity

Intel QuickSync can typically handle:

8th-10th gen: 4-6 simultaneous 1080p H.264 transcodes
11th gen+: 6-8 simultaneous 1080p transcodes, 2-3 4K HEVC
12th gen+: 8-10 simultaneous 1080p, 3-4 4K transcodes

Quality Considerations

Hardware encoding produces slightly larger files than software (x264)
Quality is excellent for streaming but may not match software for archival
HEVC hardware encoding (if available) provides better efficiency than H.264

Additional Optimizations

Performance Tweeks

Memory Tuning

For 4K transcoding, increase container RAM:

memory: 4096

CPU Priority

Give transcoding higher priority:

cores: 4
cpulimit: 0
cpuunits: 1024

What About NFS?

Since we’re on the topic of “impossible” things in unprivileged LXC:

NFS works perfectly fine. Mount it on the host, then bind mount into the container:

Host:

mount -t nfs nas.local:/volume1/media /mnt/nas-media

Container config: In /etc/pve/lxc/CTID.conf add:

mp0: /mnt/nas-media,mp=/mnt/media

Security Benefits

This setup provides several security advantages over alternatives:

Process isolation: Jellyfin runs in its own namespace
Limited privilege: No root access to host system
Resource limits: CPU/memory can be strictly controlled
Network isolation: Can be restricted to specific VLANs
Minimal attack surface: Only required devices are exposed

Conclusion

Unprivileged LXC containers are not the limitation—lack of understanding is. With proper device mapping and group management, you get the security benefits of containerization with near-native hardware performance.

This setup gives you:

Secure, unprivileged execution
Direct GPU access without overhead
Professional-grade media streaming
Easy maintenance and updates

Stop settling for bloated VMs or dangerous privileged containers. Master the mappings and run Jellyfin the right way.

Next Steps

Want to level up further? Consider:

Remote storage: Set up NFS/SMB mounts for media libraries
Reverse proxy: Add Nginx/Traefik for HTTPS and custom domains
Backup strategy: Implement container snapshots and config backups

MINISFORUM MS-A2
A Ryzen-powered beast in a mini PC shell. Dual 2.5 GbE, 10 GbE option, triple NVMe. Small box, big Proxmox energy.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Why I Ditched My VM NAS and Went Bare-Metal (And You Should Too)

Thu, 24 Jul 2025 06:44:27 -0600

My Jellyfin server used to forget movies. Random ones wouldn’t show up, or new ones would vanish into the ether. Reboot Proxmox, and poof, they’re back. The culprit? A race condition nightmare from running my NAS in a Proxmox-hosted VM.

I tried everything: automount, systemd, UID hacks, ritual sacrifices to the filesystem gods. Best I ever got was “mostly works.” And that’s not good enough when Jellyfin’s your nightly unwind ritual.

So I ditched the VM, went bare-metal with XFS and MergerFS, and finally, finally, built a NAS that boots clean and mounts right. Every. Single. Time.

💭 TL;DR

Running your NAS inside a VM? That's fine until you're fighting race conditions you didn't sign up for. Go bare-metal with XFS and MergerFS for simplicity, speed, and rock-solid reliability. Just know you're trading Proxmox's creature comforts for predictable behavior that actually works.

Fractal Design Define 7 XL

The Define 7 XL can accommodate up to 18 HDDs/SSDs plus five additional SSDs in the Storage Layout, with flexible configurations using included multi-brackets and HDD/SSD trays.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Why VM NAS Setups Sound Sexy (But Aren’t)

Sure, it looks efficient on paper. One box. Multiple VMs. Snapshots. Live migrations. The homelab porn writes itself. But reality hits a bit different:

Race conditions from hell: Proxmox boots, VMs start spinning up, but your containers beat NFS to the punch. Result? Jellyfin loads with a library that looks like Swiss cheese.
Mounting nightmares: Getting the Proxmox host to mount NFS shares after the NAS VM boots is like herding cats. I tried automounts, failed spectacularly. Switched to systemd mounts, same story. Finally built UID-mapped folders to sidestep Proxmox’s 100000 offset nonsense. Worked 97% of the time, but “mostly working” storage is like being “mostly pregnant.”
Death by a thousand cuts: Every virtualization layer (Proxmox → QEMU → ext4/XFS → NFS → LXC) adds latency. You bleed throughput. You sacrifice reliability.
The debugging tax: When things break (and they will), you’re troubleshooting across multiple abstraction layers. Is it the VM? The host? The container? The mount? Good luck figuring that out Sunday afternoon when your family is rioting when they can’t watch their favorite movie or the latest episode of their current indulgence.

“There is not much difference in performance if any at all.” – Some Reddit user who clearly never spent a weekend troubleshooting missing folders and/or files.

Try saying that after your fourth reboot hoping your media will magically reappear.

Why Bare-Metal XFS + MergerFS Actually Wins

No more race conditions: NFS shares mount early via proper systemd ordering. Containers see their media, first boot, every boot, forever.
Direct I/O that doesn’t suck: XFS is battle-tested and fast. MergerFS pools drives seamlessly without the virtualization overhead tax. Your drives work at their actual speed.
Predictable boots: No more crossing your fingers hoping your storage VM came up in time. No more UID hacks. Just clean systemd dependencies that do what they say on the tin.

Bonus wins:

Full 10GbE bandwidth (not strangled by virtio drivers)
Simpler storage stack = fewer things to break
Cleaner disaster recovery: rsync, backups, and mounts you actually understand
Sleep peacefully knowing your storage isn’t playing startup roulette

Bare-Metal vs. VM: The Real Scorecard

Setup	Pros	Cons
VM NAS	✔️ Snapshots ✔️ Easy Proxmox backups ✔️ Service consolidation ✔️ Looks good in /r/homelab	❌ NFS race conditions ❌ I/O performance tax ❌ Complex UID/GID mapping ❌ Multi-layer debugging hell
Bare-Metal NAS	✔️ Predictable boots ✔️ Zero virtualization overhead ✔️ Simple, direct mounts ✔️ Full hardware performance	⚠️ Manual backup strategy ⚠️ Extra box to power & manage ⚠️ No VM convenience features

Power tradeoff? Absolutely. That’s why I went with a G3220. It sips power like a gentleman but handles the workload without breaking a sweat. The 10Gb NIC and HBA get to stretch their legs properly.

Build Blueprint: What Actually Works

Hardware (Stuff I had lying around):

Intel G3220
Gigabyte GA-Z87X-D3H
16GB DDR3
LSI 9300-8i HBA in IT mode
10Gb NIC

Software Stack:

Debian Trixie
XFS on each drive
MergerFS for seamless pooling
NFS for rock-solid container access
systemd for proper mount ordering

Why this combo works: Dead simple architecture. Nothing fancy. It just boots and works, every time.

For Details on MergerFS and HBAs:

LSI 9300-8i

Already Flashed to IT mode.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

The Cold, Hard Truth About My Experience

I burned two entire weekends trying to make VM-NAS race conditions disappear. They laughed at my attempts.

I deployed automounts like a hopeful fool. I crafted systemd units with the precision of a Swiss watchmaker. I even UID-hacked workarounds that would make a kernel developer weep. And still, some folders only materialized after rebooting the entire Proxmox host.

Bare-metal isn’t perfect. You lose snapshots. You lose centralized VM backups. You lose the satisfaction of running everything on one box.

But you gain something precious: predictability. When you power on your NAS, it works. When containers start, they see their media. When users browse your library, the files are actually there.

One box, one job, one stack to debug. That clarity is worth the extra 20 watts, especially when your CPU barely registers on the power meter and your Jellyfin setup never misses a beat.

The Bottom Line

A VM NAS can work if you enjoy weekend troubleshooting sessions and the thrill of uncertainty. But a bare-metal NAS does work, every single time, without drama or surprise downtime.

If you’re tired of startup order roulette, phantom mount points, and explaining to family why half the movie collection disappeared again. Go physical. Go simple. Go fast.

Your sanity will thank you. Your users will thank you. Your Saturday mornings will thank you.

Ready to Build It Right?

Ditch the VM complexity. Build your NAS properly with bare-metal XFS and MergerFS. Stop trusting virtualization layers to mount your media collection in the correct order.

I’ve got fstab configs, systemd unit files, and plenty of battle scars if you need guidance.

Just ask.

Seagate Barracuda 24TB Internal Hard Drive

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Why Unprivileged LXC + NFS = Regret (Here’s How I Learned the Hard Way)

Tue, 22 Jul 2025 06:04:43 -0600

I spun up some unprivileged LXCs on Proxmox (Jellyfin, Sonarr, Radarr, and Audiobookshelf). The plan was to keep it lightweight, clean, and have them all talk to my NAS over NFS.

That plan lasted about a week.

What followed was a parade of silent failures, missing files, and permission bugs that made me question reality. Unprivileged sounded safe. Turns out LXCs are just too stripped down to work reliably if you need NFS access.

Let me show you why unprivileged LXC is a trap for anything that needs NFS access, and how I crawled back to VMs running Docker. Humbled but functional.

💭 TL;DR

Unprivileged LXC + NFS seems awesome and secure until root mapping, id shifts, and bind mount hell break your stack. Use privileged LXC or, better yet for NFS, a VM. I learned this the hard way with Proxmox.

The Two Faces of LXC: Privileged vs Unprivileged

LXC containers come in two flavors: privileged and unprivileged. That one word changes everything about how your containers behave, what they can access, and how much pain you’ll experience.

🔓 Privileged Containers: Power at a Price

A privileged container runs as root on the host. Not “container root.” Actual host root.

What that means:

Container UID 0 = host UID 0
Full access to system calls
Direct read/write access to host files
Minimal UID translation (things just work with NFS, USB devices, bind mounts, etc.)

Sounds scary? It should be. If a service inside that container gets compromised, the attacker now has root on your host. Full stop.

When privileged LXC makes sense:

Internal-only services you fully trust
Containers behind a firewall, with zero external exposure
Services that need real root access

🔒 Unprivileged Containers: Safe but Issues with NFS

Unprivileged containers were designed to fix that security risk by adding a layer of UID mapping.

They add 100000 to all container UIDs:

Container UID 0 → host UID 100000
Container UID 1000 → host UID 101000
And so on…

So even if something breaks inside, the container can’t mess with your host. It’s sandboxed. Safe.

But here’s the catch: that UID mapping breaks everything outside the container.

NFS doesn’t recognize 100000 as root.
File permissions stop making sense.
Accessing anything shared with the host becomes a pain.

Unprivileged containers work great when:

You don’t need to write to NFS
You don’t care about permissions on shared files
You want to sandbox a sketchy app or test environment

So Which One Should You Use?

Use Case	Best Container Type
Running Jellyfin/Arr stack with NFS	Virtual Machine or Privileged
Public-facing container	Virtual Machine or Unprivileged
Docker inside LXC	Privileged (not recommended)
Internal utility that touches host fs	Privileged
Unsafe app or 3rd-party binary	Unprivileged

Bottom line:
Privileged = easier, more powerful, more dangerous
Unprivileged = safer, but crippled when it comes to real-world file access

And if you’re mixing in NFS?
Unprivileged goes from “safe” to “useless.”

MINISFORUM MS-A2
A Ryzen-powered beast in a mini PC shell. Dual 2.5 GbE, 10 GbE option, triple NVMe. Small box, big Proxmox energy.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

My Descent Into Troubleshooting Hell

Let me walk you through the steps I took. Each one with hope, each one crushed by reality. If this looks like your future, do yourself a favor and skip ahead to VMs now.

Attempt #1: Custom UID Mapping

I tried overriding lxc.idmap to fake container UID 0 as host UID 1000:

lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 101000 1
lxc.idmap: g 1000 101000 1
lxc.idmap: g 1001 101001 1
lxc.idmap: u 1001 101001 64534
lxc.idmap: g 1002 101002 64534

Result: Partially worked, but created more permission edge cases.

Attempt #2: NFS Export Tweaking

I tried various NFS settings and settled on this:

/media/Storage/ *(all_squash,anongid=1001,anonuid=1000,insecure,rw,fsid=100,subtree_check)

Result: Files appeared but the permissions were still an issue.

Attempt #3: Host Mount + Bind Mount

I mounted NFS on the host, then bind-mounted into the LXC:

mp0: /mnt/storage/Shows,mp=/media/Shows
mp1: /mnt/storage/Movies,mp=/media/Movies
mp2: /mnt/storage/Music,mp=/media/Music
mp3: /mnt/storage/eBooks,mp=/media/eBooks
mp4: /mnt/storage/AudioBooks,mp=/media/AudioBooks

Result: Files showed up but were owned by nobody:nogroup. Jellyfin couldn’t scan, play, or write. When the host mount failed during reboots, containers booted with empty folders. Silent disasters everywhere.

Attempt #4: The bindfs Hail Mary

In my final attempt, I tried bindfs to remap ownership:

[Unit]
Description=Bindfs mounts for NAS directories
Requires=mnt-nas_storage.mount

[Service]
Type=oneshot
ExecStart=/usr/bin/bindfs -u 101000 -g 101001 /mnt/nas_storage /mnt/mapped_nas_storage
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

Result: This worked the best, but I’d still randomly lose files. Every workaround fixed one thing and broke three more.

I’m sure someone has forced unprivileged LXCs to work, but I just want to enjoy my media and not be constantly fight with permissions.

The Privileged Container Security Trap

So what’s the catch with using a privileged container to fix NFS? You’ve now handed root access from the container directly to the host.

Root inside = root outside

If someone compromises Jellyfin (or any dependency), they’re root on your Proxmox node. Game over.

Security Misconfigurations

Most people don’t harden their containers. Leave one small crack that someone could exploit, and the container can damage your host or pivot to other network devices.

Network Exposure Risks

Privileged containers can mess with host-level network settings. Bridge them carelessly, and an attacker could sniff or spoof traffic across your entire LAN.

Shared kernel = Shared fate

Containers don’t isolate the kernel. A bug in ffmpeg, libva, or any media processing library could expose your entire host system.

It’s not a sandbox. It’s a potential backdoor.

TP-Link Omada SG3210X-M2
Full-featured, compact, rack-ready. Eight multi-gig ports, dual 10 GbE uplinks, VLAN/QoS/ACL/LACP, and seamless integration with TP‑Link’s Omada controller. It locks down your Jellyfin/NAS traffic while scaling effortlessly with your homelab.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

The Solution: Embrace VMs with Docker

After weeks of fighting with LXC permissions, I gave up and moved everything to VMs running Docker. Here’s why this works:

True Isolation

VMs provide actual isolation. If Jellyfin gets compromised, the attacker is trapped in a virtual machine and not loose on your host.

Docker Handles Permissions

Docker’s built-in user mapping and volume mounts handle NFS permissions much more gracefully than LXC’s UID mapping.

Predictable Behavior

No more silent failures, missing files, or permission mysteries. Things work the way you expect them to.

Final Recommendations

For Jellyfin + NFS + Remote Access:

Use a VM with Docker (best option)
Use privileged LXC only if it’s internal-only and you understand the risks
Avoid unprivileged LXC entirely for this use case

For Other Use Cases:

Internal utilities: Privileged LXC is fine
Public-facing services: Unprivileged LXC or VM
Anything touching NFS: VM with Docker

The Bottom Line:

Unprivileged LXC sounds safe until it isn’t. Add NFS, media servers, and remote access, and you’re stacking pain on top of pain.

I’ve patched, mounted, and prayed my way through this mess. My final verdict? If you’re doing anything serious with NFS or Jellyfin, ditch the LXC complexity and use VMs with Docker.

Don’t fight your stack. If you need NFS, go VM. If you’re exposing Jellyfin publicly, go VM. Save your sanity and your weekends.

TP-Link 2.5GB PCIe Network Card (TX201)
Plug-and-play 2.5 GbE PCIe card that unlocks multi-gig speeds for about $30. Works out of the box with Proxmox, Linux, and Windows. No drama—just faster transfers.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Two Years of LXC Hell - Why I Crawled Back to Docker (And You Should Too)

Sun, 06 Jul 2025 07:29:44 -0600

So, you’re feeling clever. You’ve read the blogs, watched the YouTube tutorials, and decided that unprivileged LXC containers are the “right” way to run your Arr stack. Lightweight! Efficient! So much better than Docker!

Fast forward two years. You’re debugging NFS stale handle errors at 2 AM, your downloads corrupt mid-transfer, and you’re questioning every life choice that led you to this moment.

That was me. Now I’m back on Docker, tail between my legs, with a rock-solid docker-compose.yml that works.

💭 TL;DR

Thought LXC was smarter than Docker? So did I. Until stale NFS handles, ghost downloads, and permission nightmares broke my will to live. This Docker Compose setup just works. Copy, run, exhale.

Need a Mini Server?

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

The Hard Truth About LXC vs Docker Compose

Let me save you the pain I went through. LXC sounds perfect for media servers until you try to run something complex like the full Arr suite and NFS shares.

Here’s what Docker Compose gives you that LXC never could:

One File to Rule Them All

With LXC, adding a new service means spinning up another container, configuring networking, setting up mounts, and praying everything talks to each other. With Docker Compose: Edit a few lines, run docker compose up -d, and you’re done.

Want to restart everything?

docker compose restart

Want to migrate to a new server? Copy two files: your .env and docker-compose.yml and you are back online in minutes.

No More Permission Purgatory

Ever watch a file download successfully but never move to your media folder? Or see Sonarr throw “access denied” errors with zero explanation? That’s LXC’s unprivileged user permissions playing games with your sanity.

This is the one I could never resolve: the file is downloaded and moved to the NFS share but the LXC host never sees it in the mount point until the system is rebooted.

This Docker setup uses PUID and PGID across every container, so they all behave like the same user on your host. No more mystery permission errors. No more chmod 777 voodoo dances.

Shared Downloads That Actually Work

One /downloads directory for everything. SABnzbd drops files there. Sonarr, Radarr, and their friends watch that same folder and move files cleanly. No bind mount spaghetti. No symbolic link nightmares. Just clean, predictable file handling.

What Finally Broke Me

After two years of LXC “optimizations,” these were the straws that broke the camel’s back:

NFS + LXC = Stale File Handle Roulette
Try debugging why your mounts randomly go read-only mid-download or why Jellyfin can’t see a file that’s clearly in the share until you restart NFS. I spent months chasing these ghosts.

Every Container Needs Its Own IP (Maybe)
Unless you NAT everything (gross), LXC means manually assigning static IPs and keeping track of them. Docker Compose skips this entirely. All your apps talk over an internal bridge network.

Updates Are a Gamble
Something breaks in LXC? Hope you documented every tweak you made over the past six months. Docker? Blow it away and recreate it in seconds. Your config survives because it’s volume-mounted.

The Stack That Actually Works

Here’s the battle-tested docker-compose.yml that ended my suffering:

services:

  #################################
  ##  PROWLARR                   ##
  #################################
  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    container_name: prowlarr
    user: "${PUID}:${PGID}"
    env_file: .env
    restart: unless-stopped
    ports:
      - ${PROWLARR_PORT}:9696
    volumes:
      - ${CONFIG_PATH}/prowlarr:/config
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    networks:
      - media_network

  #################################
  ##  SONARR                     ##
  #################################
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    user: "${PUID}:${PGID}"
    env_file: .env
    restart: unless-stopped
    ports:
      - ${SONARR_PORT}:8989
    volumes:
      - ${CONFIG_PATH}/sonarr:/config
      - ${MEDIA_PATH}/Shows:/tv
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      - media_network

  #################################
  ##  RADARR                     ##
  #################################
  radarr:
    image: lscr.io/linuxserver/radarr:latest
    container_name: radarr
    user: "${PUID}:${PGID}"
    env_file: .env
    restart: unless-stopped
    ports:
      - ${RADARR_PORT}:7878
    volumes:
      - ${CONFIG_PATH}/radarr:/config
      - ${MEDIA_PATH}/Movies:/movies
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      - media_network

  #################################
  ##  Lidarr                     ##
  #################################
  lidarr:
    image: lscr.io/linuxserver/lidarr:latest
    container_name: lidarr
    user: "${PUID}:${PGID}"
    env_file: .env
    restart: unless-stopped
    ports:
      - ${LIDARR_PORT}:8686
    volumes:
      - ${CONFIG_PATH}/lidarr:/config
      - ${DOWNLOADS_PATH}:/downloads
      - ${MEDIA_PATH}/Music:/music
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      - media_network

  #################################
  ##  Readarr1 eBooks            ##
  #################################
  readarr1:
    image: lscr.io/linuxserver/readarr:develop
    container_name: readarr1
    user: "${PUID}:${PGID}"
    env_file: .env
    restart: unless-stopped
    ports:
      - ${READARR1_PORT}:8787
    volumes:
      - ${CONFIG_PATH}/readarr1:/config
      - ${DOWNLOADS_PATH}:/downloads
      - ${MEDIA_PATH}/eBooks:/books
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      - media_network

  #################################
  ##  Readarr2                   ##
  #################################
  readarr2:
    image: lscr.io/linuxserver/readarr:develop
    container_name: readarr2
    user: "${PUID}:${PGID}"
    env_file: .env
    restart: unless-stopped
    ports:
      - ${READARR2_PORT}:8787
    volumes:
      - ${CONFIG_PATH}/readarr2:/config
      - ${DOWNLOADS_PATH}:/downloads
      - ${MEDIA_PATH}/AudioBooks:/books
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      - media_network

  #################################
  ##  Bazarr                     ##
  #################################
  bazarr:
    image: lscr.io/linuxserver/bazarr:latest
    container_name: bazarr
    user: "${PUID}:${PGID}"
    env_file: .env
    restart: unless-stopped
    ports:
      - ${BAZARR_PORT}:6767
    volumes:
      - ${CONFIG_PATH}/bazarr:/config
      - ${MEDIA_PATH}/Movies:/movies
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      - media_network

  #################################
  ##  SABnzbd                    ##
  #################################
  sabnzbd:
    image: lscr.io/linuxserver/sabnzbd:latest
    container_name: sabnzbd
    user: "${PUID}:${PGID}"
    env_file: .env
     restart: unless-stopped
    ports:
      - ${SABNZBD_PORT}:8080
    volumes:
      - ${CONFIG_PATH}/sabnzbd:/config
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      - media_network

#################################
##  NETWORK                    ##
#################################
networks:
  media_network:
    name: media_network
    external: true

What Each Piece Actually Does

services:
Each app gets its own container. Easier to debug, update, or nuke from orbit when things go sideways.

image:
I use linuxserver.io images exclusively. It is clean, well-documented, and no weird surprises hiding in latest.

user: "${PUID}:${PGID}"
This is the magic that prevents permission hell. Every container runs as your host user.

env_file: .env
Keeps sensitive info and paths out of the compose file. Makes the whole thing portable between servers.

volumes:

/config: App settings and databases that persist forever
/downloads: Shared workspace for all apps and SAB
/media: Your precious media collection

networks:
Everything sits on media_network. Internal traffic stays inside Docker. No extra IPs to manage.

restart: unless-stopped
Containers come back after reboots, crashes, or when you’re mid-binge and don’t want to babysit anything.

The Essential .env File

# User and Group ID (Prevents permission issues)
# Main user ID
PUID=1000
# Main group ID:
PGID=1001

# Timezone (Ensures correct scheduling and logs)
TZ=America/Denver

# Define Ports (Ports for each container are defined here)
RADARR_PORT=7878
SONARR_PORT=8989
SABNZBD_PORT=8080
PROWLARR_PORT=9696
LIDARR_PORT=8686
READARR1_PORT=8787
READARR2_PORT=8788
BAZARR_PORT=6767

# Data Directories (Keeps storage paths centralized)
CONFIG_PATH=/docker
DOWNLOADS_PATH=/downloads
MEDIA_PATH=/media/Storage

💡

Tip:

Run id to get your PUID and PGID
Set TZ correctly or your downloads will happen at weird hours
Use absolute paths everywhere—don’t get cute with relative paths

Getting Started (The Easy Way)

Drop both files in the same folder: Edit the .env to match your real paths and UID/GID.
Fire it up:
```
docker compose up -d
```
Access your apps:
- Sonarr: http://your-ip:8989
- Radarr: http://your-ip:7878
- Prowlarr: http://your-ip:9696
- (and so on…)

Real-World Scenarios Where This Shines

Running Jellyfin?

This stack becomes your automated feeder system. Jellyfin handles playback, and the Arr apps handle acquisition. New episode downloads → automatically appear in Jellyfin. No more manual file moves. No more metadata headaches.

Tired of Snap’s BS on Ubuntu?

Snap has a mind of its own. Sometimes Snap won’t update, force-updates when you don’t want it to, or your Docker CLI vanishes.

This stack uses real Docker, on your terms, with predictable behavior. (Also why I moved everything back to Debian, but that’s another rant.)

Want Boring Updates? Yes please.

docker compose pull
docker compose up -d

That’s it. Your config persists, your ports don’t change, and you’re back online in seconds with fresh code.

The One Gotcha That’ll Bite You

Mounts matter. If your paths don’t match between host and container, nothing works.

Double-check that:

Host /downloads maps to container /downloads
Same for /media and /config
Your PUID/PGID match your actual user

Get this wrong, and you’ll be back to debugging permission errors like it’s 2019.

The One Gotcha That’ll Bite You

⚠️

Warning:

Mounts matter. If your paths don’t match between host and container, nothing is going to work.

Double-check that:

Host /downloads maps to container /downloads
Same for /media and /config
Your PUID/PGID matches your actual user

If these are wrong, you will be back to debugging permission errors.

The Bottom Line

You now have the complete stack. One YAML file. One .env. All your media apps work together without fighting over ports, permissions, or your sanity.

I fought for two years trying to outsmart this problem with clever LXC setups. Turns out the solution was to stop being clever and just let Docker do the work.

I hope my pain and suffering saves you some time and effort.

Need A NAS?

UGREEN NASync DXP4800, 4-Bay NAS with Intel N100 Quad-Core CPU (Up to 3.4GHz) 8GB DDR5, 2x M.2 PCIe Slots and a 2.5GbE Port (Diskless). This is perfect if you don’t want to DIY your NAS.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Docker vs Mutiple LXCs for the Arr Suite

Sun, 22 Jun 2025 07:13:47 -0600

I used to think running each Arr app in its own LXC was a smart move. It felt clean. Minimal. Efficient. However, if you’ve ever tried to juggle Sonarr, Radarr, SABnzbd, and the rest across a handful of Proxmox containers, you know the cracks start showing up quickly. Trust me, I’ve been there, and it’s not worth the pain.

If you’re serious about your media setup, it’s time to move your Arr stack into a Docker environment inside a single Virtual Machine. Here’s why it matters.

Points that I’m Willing to Concede

You can setup the Arr Suite in their own unprivileged LXCs. I did it and it worked. However, I didn’t like managing it.
I know some of you run Docker in LXCs. That is a special kind of headache that I want nothing to do with. It also isn’t officially supported by Proxmox.

What We’re Working With

Proxmox is a virtualization platform that allows you to run multiple operating systems on a single physical machine, perfect for a homelab or media hoarders who want to consolidate services.

LXC containers are lightweight virtualized environments that share the host’s kernel. Think of them as isolated spaces that use fewer resources than full virtual machines.

Virtual machines (VMs) are complete, isolated operating systems that don’t share anything with the host.

The Arr suite includes applications like Sonarr (TV show automation), Radarr (movie automation), Lidarr (music automation), and SABnzbd (download client) that work together to automatically find, download, and organize your media library.

LXC Containers Look Great on Paper, But They Will Trip You Up Fast

Sure, LXCs are lightweight. They share the Proxmox host’s kernel and do not suck up much in the way of resources. That sounds ideal until you realize just how tightly integrated the Arr apps are.

Too Many Moving Parts: Seven LXCs means seven operating systems, seven update schedules, seven IP addresses, and seven chances for something to break. Docker bundles everything together. Less patching, fewer surprises.

Networking Gets Messy: Apps like Sonarr and Radarr need to talk to Prowlarr and your downloader constantly. Getting that cross-talk working between LXCs means manually configuring IP addresses, firewall rules, and routing between containers. Here is where Docker shines. It creates an internal network where services can find each other by name automatically. Instead of remembering that Sonarr lives at 192.168.1.100:8989, you tell it to connect to “sonarr:8989” and Docker handles the rest.

Storage and Permissions Are a Nightmare: When multiple LXCs attempt to access the same media folders, you might run into user ID and group ID issues. One container might create files that another cannot read or modify. With Docker, you map your storage once to the VM, and all containers share the same user context, eliminating permission headaches.

Unprivileged Containers Make Network Storage a Pain: If you are running unprivileged LXCs (which you should for security), accessing NFS or SMB shares becomes a special kind of hell. Unprivileged containers map user IDs differently than the host system, so your media files could potentially show up as owned by “nobody” or become completely inaccessible. You will spend hours tweaking UID maps, CIFS mount options, and NFS export settings to get basic file access working. Meanwhile, a VM with Docker mounts your network shares normally and passes them through to containers without the mapping headaches.

Config Drift Is Real: One LXC might get updated while another does not. Suddenly, one app fails, and you spend hours figuring out why version mismatches are breaking API calls between services. Docker Compose gives you a single source of truth, a YAML file that defines your entire stack with specific versions.

Docker in a VM: The Sweet Spot for Media Automation

Here is where things get easier.

One VM to Rule Them All: Instead of babysitting a small army of containers, you manage one Debian or Ubuntu VM. Update once. Patch once. Reboot once.

Docker Compose = Sanity: Everything is in a single docker-compose.yml file that handles every Arr app you need (Sonarr, Radarr, Lidarr, SABnzbd, etc.), their connections, volumes, ports, and environment variables, plus user IDs, and timezones are all centralized and clean. Spin up the stack with docker compose up -d, shut it down with one command docker compose down, and update the apps without touching the rest of the system docker compose pull.

True Isolation: VMs are completely fenced off from your Proxmox host. If something breaks, it will not leak into your main system. If you ever need to move the stack, just back up the VM and drop it in the new location.

Less Headache When Things Break: One place to look for problems. Use docker logs and get answers fast. No need to jump between different containers and hunt through logs scattered across multiple LXCs.

Better Community Support: Most media server guides today assume you are running Docker. That means more tutorials, more troubleshooting help, and fewer dead ends when you run into problems.

Efficient Use of Resources: A single VM with Docker may use slightly more memory than LXCs initially, but long term, it is more stable, more predictable, and easier to maintain. The small resource overhead is worth the massive reduction in complexity.

Stop Fighting. Start Watching.

LXCs are ideal for simple, fire-and-forget services that do not need to communicate with each other. But the Arr suite is not that. These apps need to work together seamlessly, and they need consistency across your entire stack.

Docker inside a VM gives you that consistency. This method provides you with the benefits of isolation and virtualization with the simplicity of containerized applications that can communicate with each other effortlessly.

So, skip the mess. Build your media automation stack inside a VM. Use Docker Compose. Spend less time debugging networking and permission issues, and more time enjoying your perfectly organized media library.

Set it up once. Watch it work. Enjoy your media.

ASROCK Mini-Desktop Computer

The DeskMini B760 is a compact yet powerful barebone system perfect for homelab use. It supports up to 14th Gen Intel CPUs (65W), dual DDR4 RAM up to 64GB, and fast storage via both Gen5 and Gen4 M.2 slots plus dual 2.5" drive bays. It’s ideal for running lightweight VMs and/or containers — all in a tiny footprint.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Choosing the Right Linux Distro Debian vs Ubuntu

Sun, 15 Jun 2025 12:47:22 -0600

So, you want to build a computer (server) that stores and shares files across your home network. Think of it like a digital filing cabinet that everyone in your house can access from their laptops, phones, and tablets. This type of computer is called a NAS (Network Attached Storage) server.

When building this kind of file server, you have two main choices for the operating system: Debian or Ubuntu. There are others, but for most people these will be the two they most likely have to decide between. Both are versions of Linux, a free computer operating system that differs from Windows or macOS. Let me explain why Debian is the better choice.

What Makes These Operating Systems Different?

First, let’s understand what we’re comparing. Both Debian and Ubuntu are Linux operating systems, but they work differently:

Debian is like a carefully organized library. Everything is tested thoroughly before getting added to the collection. The librarians (developers) ensure each book (software program) works perfectly with all the other books before putting it on the shelf.

Ubuntu is like a modern bookstore that gets new releases quickly. They stock the latest books, but sometimes a new book might have printing errors or might not work well with other books you already own.

Why Debian is Perfect for File Servers

Rock-Solid Reliability

When you’re storing your family photos, important documents, and music collection, you want a system that rarely breaks down. Debian is famous for its stability. Here’s what that means:

No surprise changes: Once Debian 13 is released, the software won’t suddenly change how it works. Your file server will keep running the same way for years.
Fewer crashes: Debian tests everything extensively, so your server is much less likely to freeze up or stop working.
Predictable behavior: You won’t wake up one day to find that an update changed how your file sharing works.

Ubuntu updates more frequently, which sounds good but can cause problems. Imagine if your car’s dashboard randomly rearranged itself every few months – that’s what frequent updates can feel like on a file server.

Starts Clean and Stays Clean

When you install Debian without a desktop environment (the visual interface with windows and icons), you get exactly what you need and nothing else. It’s like buying a toolbox with only the tools you actually use.

Here’s what this means practically:

Faster startup: Your server turns on and gets ready to share files quickly
Uses less memory: More of your computer’s brain power goes to storing and sharing files instead of running unnecessary programs
Fewer security risks: Fewer programs running means fewer ways for hackers to get in

Ubuntu, even in server mode, comes with extra programs you might not need. It’s like getting a toolbox where half the tools are for jobs you’ll never do.

Software That Just Works

For a file server, you need three main types of programs:

Samba/SMB: Lets Windows computers access your files
NFS: Lets Mac and Linux computers access your files
MergerFS: Combines multiple hard drives into one big storage space

Debian gives you older, more stable versions of these programs. Think of it like using a reliable 5-year-old car versus a brand-new model that might have unknown problems. The older car has had all its bugs ironed out over the years of use and testing.

Ubuntu gives you newer versions, but “newer” doesn’t always mean “better” when you’re dealing with terabytes of critical data.

Easy Updates

Every few years, you’ll want to update your operating system to a newer version. With Debian, this process is smooth and well-documented. It’s like following an easy and clearly written recipe that thousands of people have used successfully.

Ubuntu’s long-term support versions can be trickier to update, especially if you’ve customized your system. Sometimes, the Ubuntu update process can break things.

No Corporate Control

Debian is run entirely by volunteers who believe in free, open software. Ubuntu is owned by Canonical, which sometimes makes decisions based on business needs rather than what’s best for users.

Here’s what this means for you:

No forced software: Debian won’t push programs on you that you don’t want
No hidden agenda: Every decision is made in the open by the community
No surprise changes: Corporate priorities won’t suddenly change how your system works

Long-Term Support

Both systems offer long-term support:

Ubuntu 24.04: 5 years of updates (can extend to 10 years for a fee)
Debian: About 5 years of updates (completely free)

Debian’s support is entirely free and community-driven, while Ubuntu’s extended support requires paying for their “Pro” service.

What About Debian 13’s Release Date?

Debian 13 (code-named “Trixie”) isn’t available yet – it’s expected around mid-2025. If you’re building your file server now, you can start with Debian 12 and easily upgrade to Debian 13 when released. The upgrade process is designed to be smooth and safe.

Debian Just Feels Like Home

I’ve spent the last two weeks migrating all my VMs and LXC containers back to Debian. Not because something broke but because Debian feels more like home. It’s clean, it’s predictable, and I can make it my own without a corporation like Canonical getting in my way. Just the system I want and nothing more.

The Bottom Line

Building a home file server is like setting up a digital foundation for your family’s data. You want something reliable, simple, and long-lasting. Debian 13 provides exactly that – a clean, stable system that will quietly do its job for years without causing headaches.

Ubuntu 24.04 isn’t bad, but it comes with extra complexity and corporate decisions that can get in your way. When your goal is simple file sharing that just works, Debian’s straightforward approach is hard to beat.

For peace of mind and reliable file storage, choose Debian for your home server.

Need a new HDD to keep up with your downloads?

Seagate Barracuda 24TB Internal Hard Drive

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

How To Install Prowlarr in Docker

Sun, 25 May 2025 06:24:52 -0600

What is Prowlarr?

Prowlarr is the download and index manager for your media server. Think of it as the glue between your torrent/Usenet sources and the Arr apps like Sonarr, Radarr, and Lidarr. Instead of configuring downloaders and indexers manually in every app, you set them up once in Prowlarr.

Here’s how it works:

It connects to public and private torrent trackers, and/or Usenet indexers.
It connects your loacal downloaders to the ARR apps.
It centralizes these connections and monitors them for availability.
It automatically syncs these indexers to your other Arr apps using API connections.
It lets you categorize indexers by media type (TV, movies, music) and push them to the right apps.
You log into one dashboard to manage every source your automation relies on. And when something goes wrong with an indexer? Prowlarr lets you know.

Why You Should Use Prowlarr

Running a media server without Prowlarr is like trying to drive a car without tires. You can sort of do it, but why?

Here’s why you want it:

Saves Time: Add an indexer or downloader once. That’s it. No more copy/paste API keys and login info three or more times.
Reduces Errors: When one app works and another doesn’t, the culprit is often a misconfigured or outdated indexer. Prowlarr fixes that.
Monitors Health: Know immediately when an indexer or downloader goes offline. You don’t find out a week later when you are missing your favorite show.
Supports Everything: Private trackers, paid Usenet, free public indexers—Prowlarr works with all of them.

It turns a messy, manual setup into a clean, scalable system that you can set and forget.

Step 1: Install Docker

To get started, you’ll need Docker installed on your server.
Check out this guide for step-by-step instructions: Master the Basics - How to Install Docker

Step 2: Create or Modify Your Docker Compose File

Let’s define your Prowlarr container using docker-compose.yml. In this post we will be adding Prowlarr to our existing docker-compose.yml that contains the settings for the rest of the stack. Post: How to Install Sonarr in Docker

Open the Compose File

Open your existing docker-compose.yml or create a new one:

nano /docker/docker-compose.yml

Then, copy and paste the SABnzbd Section:

services:

  #################################
  ##  PROWLARR                   ##
  #################################
  prowlarr:
    # Official Linuxserver.io Prowlarr image
    image: lscr.io/linuxserver/prowlarr:latest
    # Sets a custom name for the container
    container_name: prowlarr
    # Name and location of the .env file
    env_file: .env
    # Ensures the container restarts if it crashes
    restart: unless-stopped
    ports:
      - ${PROWLARR_PORT}:9696
    volumes:
      # Stores Sonarr's configuration data
      - ${CONFIG_PATH}/prowlarr:/config
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    networks:
      # Connects the container to the custom media network  
      - media_network

  #################################
  ##  SONARR                     ##
  #################################
  sonarr:
    # Official LinuxServer.io Sonarr image
    image: lscr.io/linuxserver/sonarr:latest
    # Sets a custom name for the container
    container_name: sonarr
    # Name and location of the .env file
    env_file: .env
    # Ensures the container restarts if it crashes
    restart: unless-stopped
    ports:
      - ${SONARR_PORT}:8989
    volumes:
      # Stores Sonarr's configuration data 
      - ${CONFIG_PATH}/sonarr:/config
      # Directory where downloaded TV shows are stored  
      - ${MEDIA_PATH}/Shows:/tv
      # Directory where incomplete downloads are stored  
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      # Connects the container to the custom media network  
      - media_network

  #################################
  ##  RADARR                     ##
  #################################
  radarr:
    # Official LinuxServer.io Radarr image
    image: lscr.io/linuxserver/radarr:latest
    # Sets a custom name for the container
    container_name: radarr
    # Name and location of the .env file
    env_file: .env
    # Ensures the container restarts if it crashes
    restart: unless-stopped
    ports:
      - ${RADARR_PORT}:7878
    volumes:
      # Stores Radarr's configuration data
      - ${CONFIG_PATH}/radarr:/config
      # Directory where downloaded Movies are stored  
      - ${MEDIA_PATH}/Movies:/movies
      # Directory where incomplete downloads are stored
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      # Connects the container to the custom media network  
      - media_network

  #################################
  ##  SABnzbd                    ##
  #################################
  sabnzbd:
    # Official LinuxServer.io SABnzbd image
    image: lscr.io/linuxserver/sabnzbd:latest
    # Sets a custom name for the container
    container_name: sabnzbd
    # Name and location of the .env file
    env_file: .env
    # Ensures the container restarts if it crashes
    restart: unless-stopped
    ports:
      - ${SABNZBD_PORT}:8080
    volumes:
      # Stores SABnzbd's configuration data
      - ${CONFIG_PATH}/sabnzbd:/config
      # Directory where incomplete downloads are stored
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      # Connects the container to the custom media network  
      - media_network

#################################
##  NETWORK                    ##
#################################
# Creates an isolated Docker network for media containers
networks:
  media_network:
    driver: bridge

💡 Tip: Make sure the spacing is correct. YAML is very picky about spacing. The key is that each indent is two spaces not a tab.

Step 3: Customize the .env File

Open the .env File

nano /docker/.env

The content of the .env file should look like this:

# User and Group ID (Prevents permission issues)
# Main user ID
PUID=1000
# Our media group:
PGID=1001

# Timezone (Ensures correct scheduling and logs)
TZ=America/Denver

# Define Ports (Ports for each container are defined here)
# Maps Radarr’s web UI to port 7878 on the host
RADARR_PORT=7878
# Maps Sonarr’s web UI to port 8989 on the host
SONARR_PORT=8989
# Maps SABnzbd’s web UI to port 8080 on the host
SABNZBD_PORT=8080
# Maps Prowlarr's web UI to 9696
PROWLARR_PORT=9696

# Data Directories (Keeps storage paths centralized)
CONFIG_PATH=/docker
DOWNLOADS_PATH=/media/downloads
MEDIA_PATH=/media

Step 4: Start SABnzbd

Bring your new SABnzbd container online:

docker compose up -d

Check it’s running:

docker ps

You should see prowlarr in the list of containers:

CONTAINER ID   IMAGE                                 COMMAND   CREATED         STATUS         PORTS                                         NAMES
65470f79b320   lscr.io/linuxserver/radarr:latest     "/init"   6 seconds ago   Up 5 seconds   0.0.0.0:7878->7878/tcp, [::]:7878->7878/tcp   radarr
3e96643b0ba9   lscr.io/linuxserver/sabnzbd:latest    "/init"   6 seconds ago   Up 5 seconds   0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp   sabnzbd
604d2ed3850c   lscr.io/linuxserver/prowlarr:latest   "/init"   6 seconds ago   Up 5 seconds   0.0.0.0:9696->9696/tcp, [::]:9696->9696/tcp   prowlarr
52c78c78f541   lscr.io/linuxserver/sonarr:latest     "/init"   6 seconds ago   Up 5 seconds   0.0.0.0:8989->8989/tcp, [::]:8989->8989/tcp   sonarr

Step 5: Fix Permissions (If Needed)

Permissions issues are a common snag with media containers. Here’s how to make sure everything plays nice:

sudo chown -R `yourusername`:media /docker/ && sudo chmod -R 770 /docker/
sudo chown -R `yourusername`:media /media/ && sudo chmod -R 770 /media/

Check out this post if you want to learn more about Linux permissions:
Master the Basics - Linux Permissions

Step 6: Access and Set Up Prowlarr in Your Browser

Open a web browser and visit:

http://your-server-ip:9696

Follow the setup wizard to:

Add your Usenet and torrent indexers
Link your downloader (qBittorent, SABnzbd, or NZBget) via API
Link Sonarr, Radarr, Lidarr via API
Set up categories (movies → Radarr, TV → Sonarr, etc.)
Turn on Sync to push indexers automatically

Once connected, Prowlarr becomes the single point to update these apps in your stack.

Step 7: Keep Your Docker Software Updated

To update:

docker compose pull  # Fetches the latest image
docker compose down  # Stops and removes the running container
docker compose up -d  # Starts a fresh container with the new image

Radarr, Sonarr, SABnzbd, and Prowlarr will restart with the latest version, no reconfig needed.

In Closing

Prowlarr plugs a gap in the automation chain. It keeps indexers and downloaders consistent, online, and working with your stack. Run it in Docker and forget about it. You’ll spend less time troubleshooting and more time enjoying your media.

Want a real hands-off setup? Prowlarr is the piece you’re missing. Install it. Sync it. Forget it.

Need a new HDD to keep up with your downloads?

Seagate Barracuda 24TB Internal Hard Drive

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

How To Install SABnzbd in Docker

Sat, 10 May 2025 05:04:12 -0600

If you’re diving into the world of Usenet, you’ll learn of SABnzbd existence immediately and for good reason. While tools like Radarr and Sonarr handle the what and when part of downloading, SABnzbd takes care of the how. SABnzbd is the download engine that grabs NZB files from your indexer, handles repairs and unpacking, and drops the final product into your media library.

And the best part? It just works. Once configured, SABnzbd hums quietly in the background, handling downloads with zero fuss.

Why SABnzbd Is a Core Part of Your Media Stack

Here’s why SABnzbd remains a fan favorite:

100% Free and Open Source – No premium licenses or paywalls. It’s fully featured out of the box.
Handles Everything Automatically – SABnzbd can repair, extract, and even clean up files after download using built-in tools like par2 and unrar.
Custom Categories – Create custom routing rules for different media types so that Radarr, Sonarr, and Lidarr can each get their own download folders.
Web Interface – Clean, responsive UI for managing and monitoring downloads from any device.
API + Script Support – Want to customize behavior? SABnzbd supports post-processing scripts and integrates easily with tools like Radarr and Sonarr.

If you’re using Usenet, SABnzbd is the no-brainer choice for managing your downloads.

Why Run SABnzbd in Docker?

Docker makes SABnzbd easier to manage and more portable:

Cleaner Installs – No Python dependencies or package conflicts.
Effortless Updates – Updating is as easy as pulling the latest image.
Easy to Move – Need to switch servers? Just copy your config folder and go.
Better Separation – Keep your download service sandboxed from the rest of your system.

Step 1: Install Docker

To get started, you’ll need Docker installed on your server.
Check out this guide for step-by-step instructions: Master the Basics - How to Install Docker

Step 2: Create or Modify Your Docker Compose File

Let’s define your SABnzbd container using docker-compose.yml. In this post we will be adding SABnzbd to our existing docker-compose.yml that contains the settings for the rest of the stack. Post: How to Install Sonarr in Docker

Open the Compose File

Open your existing docker-compose.yml or create a new one:

nano /docker/docker-compose.yml

Then, copy and paste the SABnzbd Section:

services:

  #################################
  ##  SONARR                     ##
  #################################
  sonarr:
    # Official LinuxServer.io Sonarr image
    image: lscr.io/linuxserver/sonarr:latest
    # Sets a custom name for the container
    container_name: sonarr
    # Name and location of the .env file
    env_file: .env
    # Ensures the container restarts if it crashes
    restart: unless-stopped
    ports:
      - ${SONARR_PORT}:8989
    volumes:
      # Stores Sonarr's configuration data 
      - ${CONFIG_PATH}/sonarr:/config
      # Directory where downloaded TV shows are stored  
      - ${MEDIA_PATH}/Shows:/tv
      # Directory where incomplete downloads are stored  
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      # Connects the container to the custom media network  
      - media_network

  #################################
  ##  RADARR                     ##
  #################################
  radarr:
    # Official LinuxServer.io Radarr image
    image: lscr.io/linuxserver/radarr:latest
    # Sets a custom name for the container
    container_name: radarr
    # Name and location of the .env file
    env_file: .env
    # Ensures the container restarts if it crashes
    restart: unless-stopped
    ports:
      - ${RADARR_PORT}:7878
    volumes:
      # Stores Radarr's configuration data
      - ${CONFIG_PATH}/radarr:/config
      # Directory where downloaded Movies are stored  
      - ${MEDIA_PATH}/Movies:/movies
      # Directory where incomplete downloads are stored
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      # Connects the container to the custom media network  
      - media_network

  #################################
  ##  SABnzbd                    ##
  #################################
  sabnzbd:
    # Official LinuxServer.io SABnzbd image
    image: lscr.io/linuxserver/sabnzbd:latest
    # Sets a custom name for the container
    container_name: sabnzbd
    # Name and location of the .env file
    env_file: .env
    # Ensures the container restarts if it crashes
    restart: unless-stopped
    ports:
      - ${SABNZBD_PORT}:8080
    volumes:
      # Stores SABnzbd's configuration data
      - ${CONFIG_PATH}/sabnzbd:/config
      # Directory where incomplete downloads are stored
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      # Connects the container to the custom media network  
      - media_network

#################################
##  NETWORK                    ##
#################################
# Creates an isolated Docker network for media containers
networks:
  media_network:
    driver: bridge

💡 Tip: Make sure the spacing is correct. YAML is very picky about spacing. The key is that each indent is two spaces not a tab.

Step 3: Customize the .env File

Open the .env File

nano /docker/.env

The content of the .env file should look like this:

# User and Group ID (Prevents permission issues)
# Main user ID
PUID=1000
# Our media group:
PGID=1001

# Timezone (Ensures correct scheduling and logs)
TZ=America/Denver

# Define Ports (Ports for each container are defined here)
# Maps Radarr’s web UI to port 7878 on the host
RADARR_PORT=7878
# Maps Sonarr’s web UI to port 8989 on the host
SONARR_PORT=8989
# Maps SABnzbd’s web UI to port 8080 on the host
SABNZBD_PORT=8080

# Data Directories (Keeps storage paths centralized)
CONFIG_PATH=/docker
DOWNLOADS_PATH=/media/downloads
MEDIA_PATH=/media

Update the SABnzbd file paths as needed. Here’s what to change:

CONFIG_PATH=/docker → Root folder where Docker stores persistent files.
DOWNLOADS_PATH=/media/downloads → Root folder where your download client stores temp/incomplete files

Make sure the SABnzbd container access to the /downloads path.

Also update the timezone (TZ) to match yours.
Refer to: This list of valid timezones.

Step 4: Start SABnzbd

Bring your new SABnzbd container online:

docker compose up -d

Check it’s running:

docker ps

You should see sabnzbd in the list of containers:

CONTAINER ID   IMAGE                               COMMAND   CREATED          STATUS          PORTS                                         NAMES
c8d2c60a955b   lscr.io/linuxserver/sonarr:latest   "/init"   54 seconds ago   Up 53 seconds   0.0.0.0:8989->8989/tcp, [::]:8989->8989/tcp   sonarr
ff12a474a4fe   lscr.io/linuxserver/radarr:latest   "/init"   54 seconds ago   Up 53 seconds   0.0.0.0:7878->7878/tcp, [::]:7878->7878/tcp   radarr
d152d14e3fe3   lscr.io/linuxserver/sabnzbd:latest  "/init"   15 seconds ago   Up 11 seconds   0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp   sabnzbd

Step 5: Fix Permissions (If Needed)

Permissions issues are a common snag with media containers. Here’s how to make sure everything plays nice:

sudo chown -R `yourusername`:media /docker/ && sudo chmod -R 770 /docker/
sudo chown -R `yourusername`:media /media/ && sudo chmod -R 770 /media/

Check out this post if you want to learn more about Linux permissions:
Master the Basics - Linux Permissions

Step 6: Set Up SABnzbd in Your Browser

Open a web browser and visit:

http://your-server-ip:8080

Follow the setup wizard to:

Add your Usenet provider’s server info
Set up download folders
Create categories like tv and movies
Configure API keys for Radarr and Sonarr

Once connected, SABnzbd becomes the download engine for your automated stack.

Step 7: Keep Your Docker Software Updated

To update:

docker compose pull  # Fetches the latest image
docker compose down  # Stops and removes the running container
docker compose up -d  # Starts a fresh container with the new image

Radarr, Sonarr, and SABnzbd will restart with the latest version, no reconfig needed.

In Closing

SABnzbd is the workhorse behind Usenet downloads. It’s reliable, fast, and customizable. When paired with Radarr and Sonarr, it forms the core of an automated media server setup.

By running it in Docker, you keep things clean, portable, and easy to maintain. Once set up, SABnzbd quietly handles the heavy lifting while your media library manages itself. Just how it should be.

If you’re serious about automation and want a hands-off experience with your downloads, SABnzbd is non-negotiable.

Master the Basics - How to Use parted to Create Partitions Format Them and Add a Mount Point

Fri, 09 May 2025 06:24:47 -0600

You purchased a new multi-terabyte drive for your media server and are ready to slap it into service. But hold up, before you run fdisk like it’s 1999, it’s worth knowing it is no longer the right tool for the job. If your drive is over 2TB you need to use GPT instead of MBR. fdisk cannot create GPT partitions, so parted is the way to go.

I’ll walk you through how to use parted to create partitions, format them, and set up automatic mounting using fstab.

Why Parted Over Fdisk?

fdisk only works with MBR partition tables, which limits your partition sizes to 2TB. That’s a deal-breaker for modern drives. parted, on the other hand, works with both MBR and GPT and doesn’t care how big the drive is.

It also has more robust support for scripting, alignment, and resizing. If you’re working with advanced setups or need to future-proof your system, parted is the tool to learn.

fdisk vs parted: Feature Comparison

Feature	`fdisk`	`parted`
Partition Table Support	MBR (Master Boot Record) only	MBR and GPT (GUID Partition Table)
Maximum Disk Size	Up to 2TB	Supports disks larger than 2TB
Partition Resizing	Not supported	Supports resizing and moving partitions
Filesystem Creation	No (requires separate tools like `mkfs`)	Yes (can create filesystems during partitioning)
User Interface	Text-based, menu-driven	Command-line and scriptable interface
Advanced Features	Basic partitioning tasks	Advanced features like alignment and scripting
Best Use Case	Simple setups with MBR partitioning	Complex setups, large disks, GPT partitioning

When to Use Each Tool

Use fdisk for straightforward partitioning tasks on disks smaller than 2TB using the MBR scheme. It’s suitable for legacy systems and simple setups.
Use parted when dealing with disks larger than 2TB, requiring GPT partitioning, or needing advanced features like resizing partitions and scripting. It’s ideal for modern systems and complex configurations.

Setting Up Your New Drive with Parted

Here’s how to prep that new drive using parted.

Step 1: Identify the Target Disk

Run:

lsblk

Look for the disk you just installed. If it’s /dev/sdb and it’s showing no partitions, that’s the one we’ll use.

⚠️ Triple-check you’ve got the right disk before proceeding.

Step 2: Install and Launch Parted and Create a GPT Partition Table

Install parted and xfsprogs:

sudo apt install parted xfsprogs

Start parted:

sudo parted /dev/sdb

Set the disk label to GPT (recommended for drives over 2TB or UEFI systems):

In the parted shell:

mklabel gpt

Step 3: Create a New Partition

Still inside parted:

mkpart primary xfs 0% 100%

You can swap out xfs for another filesystem label if you plan to use ext4 or btrfs later. Don’t worry, this step doesn’t actually format the drive, it just defines what it’s for.

Now type:

quit

Followed by:

sudo partprobe /dev/sdb

Step 4: Format the New Partition

Run:

sudo mkfs.xfs /dev/sdb1

You can use ext4 if you prefer, but for media servers handling big files, XFS is fast and reliable.

Step 5: Create a Mount Point

Let’s say you’re adding a 5th disk to a mergerFS pool:

sudo mkdir -p /mnt/pool0/disk5

Step 6: Mount It for Testing

Test it out before making anything permanent:

sudo mount /dev/sdb1 /mnt/pool0/disk5

Check that it worked:

df -h

You should see /dev/sdb1 mounted at /mnt/media.

Step 7: Add It to fstab

First, grab the UUID:

sudo blkid /dev/sdb1

You’ll get something like:

UUID="abc123-xyz789" TYPE="xfs"

Copy the UUID

Edit your fstab:

sudo nano /etc/fstab

Add this line:

UUID=abc123-xyz789 /mnt/media xfs defaults 0 0

Save and exit.

Step 8: Test Your fstab Config

Unmount the drive:

sudo umount /mnt/pool0/disk5

Now reload fstab:

sudo mount -a

If you get no errors, you’re good to go.

Wrapping Up

parted isn’t just a newer tool, it’s the right one when working with modern storage. You’ve now set up your drive with a GPT table, created a partition, formatted it, and mounted it with fstab. All without hitting the 2TB wall that haunts fdisk.

Next time you drop a new drive into your rig, make parted your go-to tool. Your future self will thank you.

Don’t have a new drive yet pick one up here:

Seagate Barracuda 24TB Internal Hard Drive

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

The Best and Worst PC Cases for Media Servers – Ranked and Reviewed

Sat, 03 May 2025 07:39:35 -0600

You don’t need RGB LEDs and tempered glass side panels to build a good home server. You need airflow. You need drive bays. And most of all, you need peace of mind. Let’s be honest, most PC cases aren’t built for this. They’re built for looks, not longevity. If you’re stacking hard drives and chasing silence, the case matters more than you think.

I’ve built more home servers than I can count. Friends, clients, online strangers, and all run into the same wall: case selection. They assume any big or “premium” tower will do. Then they try to cram 12 spinning drives into a gaming case and realize there’s no airflow, no cable space, and no way to keep it quiet. The whole thing sounds like an F/A-18 Super Hornet and cooks the hard drives like an air fryer.

This is not the way.

Home media servers aren’t about flexing GPU specs or running rainbow light shows. They’re about stacking storage, managing heat, and keeping your build dead silent. Whether building a 100TB media monster or a modest 24TB file server, the case is the make-or-break stat.

So, to help with your case selection I have ranked the best cases for media servers. This isn’t fluff. This is a tier list based on hands-on experience, airflow, cable management sanity, and raw drive capacity. Every pick includes specs and an honest verdict. No sponsorships, no hype, just what works when you’re building practicality.

Let’s get into it.

🟩 S-Tier – Best of the Best

Fractal Design Define 7 XL

Manufacturer’s Link: Factal Design
Price: 💰💰💰💰

The Define 7 XL is the endgame for serious NAS and media server builders. It’s big, heavy, and not cheap, but it earns every inch and dollar. With room for up to 18 drives, whisper-quiet acoustics, and a modular layout that adapts to your needs, it’s the only consumer case that handles a 100TB+ array without hacks or headaches.

This isn’t just a good case. It’s the gold standard. Built like a tank, cooled like a server, and quiet enough to live next to your desk, the Define 7 XL dominates when it comes to long-term, high-capacity builds.

If you want to build it once and use it forever, this is the case you buy.

Form Factor: Full Tower
Dimensions: 23.8" × 9.4" × 22.3"
Motherboard Support: E-ATX / ATX / mATX / mITX / EE-ATX / SSI-CEB / SSI-EEB
Storage: You can get up to 18 3.5”/2.5” drives inside with optional trays.
Cooling: Three 140mm fans out of the box. You can fit a 480/420mm rad in the top, another 480/420mm rad in the front, and still have room to breathe. Upto 11 120mm fans or 9 140mm fan can be used in this case. Airflow is good, even fully loaded.
Cable Management: You’ve got space behind the motherboard tray for thick SATA and power cables—even with 10+ drives. Velcro straps and deep channels make routing easy.
Noise: Sound-dampening panels on all major surfaces. It’s incredibly quiet, even with a full drive load.
Build Quality: Thick steel, zero flex, excellent panel fitment. You can tell Fractal didn’t cheap out here.
Build Material: Steel, plastic, sound-dampened panels
Pain Points: It’s big. You need room on or under your desk. And it’s not cheap, but it’s absolutely worth it.

Verdict: If you’re serious about building a media server you can set and forget, the Define 7 XL is the one to beat. Yes, it’s expensive, but you’ll never outgrow it.

Fractal Design Define 7 XL

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

SilverStone CS380B

Manufacturer’s Link: SilverStone
Price: 💰💰💰💰

Built for one job, and built well. The SilverStone CS380B is a no-nonsense NAS case with real hot-swap support at a price that won’t gut your budget. You get 8 hot-swap bays with proper backplanes, solid cooling, and a compact footprint perfect for closet installs or headless setups.

Yeah, the internal layout is cramped. Cable routing is a pain. And no, it won’t win any beauty contests. But if you care more about function than flash, this case delivers exactly what matters: easy drive access, reliable airflow, and a build that’s purpose-built for storage.

If hot-swapping is a must, this is the case to get.

Form Factor: Mid Tower
Dimensions: 16.8" × 8.5" × 19.2"
Motherboard Support: ATX / mATX / Mini-ITX
Storage: 8 hot-swap bays in the front, each with a metal tray and built-in backplane. Add two 5.25" bays above for accessories or more drives with adapters.
Cooling: Includes two 120mm side fans and a 120mm rear fan keep drives reasonably cool, but if you load all 8 bays, you’ll want better fans.
Cable Management: This is where it hurts. It’s tight. Especially around the drive bay area. You’ll fight with SATA power cables. Modular PSUs help.
Noise: Not dampened. The stock fans are loud. You’ll hear the drives spinning. Not ideal for a living room.
Build Quality: The frame is solid, but the plastic front door feels cheap and wobbly. Hinges are known to pop loose over time.
Build Material: SECC steel, plastic
Pain Points: Limited GPU space (9.5”) and low CPU cooler clearance (5.7”) restrict future upgrades.

Verdict: It is a bit awkward to build in, but for a dedicated NAS tucked in a closet or rack, this case nails the essentials, hot-swap support at a fair price.

SilverStone CS380B

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

🟨 A-Tier – Strong Performers with Minor Quirks

Fractal Design Define R5

Manufacturer’s Link: Fractal Design
Price: 💰💰💰

The Define R5 is the quiet, compact workhorse of the Fractal lineup. Think of it as the little brother to the Define 7 XL, smaller, easier to fit into media centers or home offices, and still packed with premium features. You lose some drive slots but gain acoustic dampening, modular cages, and a build that feels perfect.

It’s not built for massive arrays or hot-swapping, but for up to 10 drives in a whisper-quiet setup, the R5 hits a sweet spot. Perfect for bedroom or office servers where silence matters more than scale.

Form Factor: Mid Tower
Dimensions: 20.5" × 9.1" × 17.8"
Motherboard Support: ATX / mATX / Mini-ITX
Storage: Comes with 8 combo 3.5"/2.5" bays plus 2 SSD mounts. Enough for a modest media or backup server.
Cooling: Two quiet 140mm fans included. Add more if needed. This case supports up to 9 fans total or a 420mm rad.
Cable Management: Generous space behind the board. It’s easy to keep things clean, even with a bunch of SATA runs.
Noise: It’s quiet. One of the quietest mid-towers you can buy.
Build Quality: Excellent. Panels are thick, the door is sturdy, and everything lines up perfectly.
Build Material: Steel, plastic, sound-dampened panels
Pain Points: You’re capped at 10 total drives, and no hot-swap. Front I/O is aging. Like no USB-C.

Verdict: If you want a whisper-quiet server in the same room you work or sleep in, the R5 is a top choice. Just keep in mind the front I/O is a little dated.

Fractal Design Define R5

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Montech KING 95 PRO

Manufacturer’s Link: Montech
Price: 💰💰💰

If you want a media server that performs well and looks good doing it, the KING 95 PRO delivers. With space for up to 13 drives, strong airflow, and a dual-chamber layout, it is more than just a pretty face. The tempered glass and ARGB fans add flair without getting in the way.

It is not a perfect case, but for the price, it is surprisingly capable. This is the budget-friendly case that proves your server doesn’t have to look like a file cabinet to get the job done.

Form Factor: Mid Tower
Dimensions: 18.7" × 11.8" × 17.4"
Motherboard Support: ATX / mATX / Mini-ITX
Storage: 8 x 3.5" HDDs and 5 x 2.5" SSDs. Enough for most users unless you’re running a full-blown archive.
Cooling: Comes with six PWM ARGB fans and a 10-port hub. Excellent airflow. Great out of the box.
Cable Management: Dual-chamber layout makes routing super easy. You’ll have plenty of room to hide cables.
Noise: Not bad, but no insulation. Fan curve tuning will matter here.
Build Quality: Surprisingly solid. Panels fit well. The curved tempered glass is sturdy, but it’s a fingerprint magnet.
Build Material: 0.8mm SPCC steel, tempered glass
Pain Points: No hot-swap. Bottom filter is a pain to clean. Riser cable for vertical GPU not included.

Verdict: Slick, spacious, and stylish, this case looks great in an office or home theater setup. It’s not for massive arrays or hot-swapping, and build quality isn’t perfect, but for the price, it punches way above its weight.

Montech KING 95 PRO

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Rosewill Helium NAS

Manufacturer’s Link: Rosewill
Price: 💰

The Helium NAS is all about stuffing in drives without draining your wallet. It’s not polished. The case suffers from thin panels, sharp edges, and noisy stock fans, but for under $100, it gets the job done. You get high drive capacity, reasonable airflow, and enough room to build something serious on a tight budget.

It’s rough around the edges, but if you care more about storage than style, the Helium NAS delivers real value where it counts.

Form Factor: Mid Tower
Dimensions: 19.2" × 8.5" × 19.2"
Motherboard Support: ATX / mATX / Mini-ITX
Storage: 10 x 3.5" + 3 x 2.5". Huge capacity for the price.
Cooling: Four 140mm fans stock. All intake by default and needs reconfiguration for proper airflow.
Cable Management: Tight. Especially with full SATA and Molex bundles. Plan your routing before plugging anything in.
Noise: Mesh front and aggressive airflow = louder than you’d expect. But temps stay good.
Build Quality: It’s budget steel. Side panels flex. Drive cage fitment isn’t always great. Expect quirks.
Build Material: SECC steel, plastic
Pain Points: No hot-swap. Some drives may block airflow. Front I/O is decent though with USB-C included.

Verdict: You’ll fight some build quirks, but for under $100, it’s a solid budget case for stuffing full of drives. 13 bays and mesh airflow seal the deal.

Rosewill Helium NAS

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

🟧 B-Tier – Usable if You’re Handy

DARKROCK Classico Max

Manufacturer’s Link: DARKROCK
Price: 💰💰

This case aims for maximum drive count on a budget and mostly nails it. It has space for 13 drives, four pre-installed fans, and a clean exterior, all for around $90. It’s a solid foundation for a media server, especially if you’re trying to stretch every dollar.

That said, the build quality won’t blow you away. Thin panels, tight cable routing, and sharp edges make the build process a hassle. But if you have patience and a first aid kit (You will cut your hands), it’s hard to beat the value for the drive count.

Form Factor: Mid Tower
Dimensions: 18.9" × 8.3" × 18.5"
Motherboard Support: E-ATX (with drive cage removed) / ATX / mATX / Mini-ITX
Storage: 10 x 3.5", 3 x 2.5". Impressive at this price.
Cooling: Four fans included, and it fits a 360mm rad on top. Drive area airflow could be better.
Cable Management: Weak spot. Rear cable space is limited. SATA and Molex cables bulge the panel.
Noise: No dampening. Expect noticeable fan and drive noise.
Build Quality: Metal panels are thin. Side panel fitment is hit-or-miss.
Build Material: Steel, plastic
Pain Points: USB-C missing. One USB 3.0 port only. Watch out for cable bulk behind the tray.

Verdict: If you need maximum drive count at a low cost, this case has you covered (in your own blood). However, expect thin panels and a serious fight for cable space.

DARKROCK Classico Max

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Thermaltake CTE C700 TG

Manufacturer’s Link: Thermaltake
Price: 💰💰💰

The C700 TG isn’t necessarily built for storage, but it brings some serious firepower if you’re building a hybrid rig. With a rotated motherboard layout for direct airflow, triple ARGB fans, and room for custom loops, it’s clearly aimed at high-performance builds. Think media storage, gaming, and VMs all in one box.

It’s massive, flashy, and absolutely overkill for a pure NAS. But if you need a case that can handle mixed workloads and look good doing it, the C700 TG pulls it off with style. Just don’t expect drive-focused design. It’s all about airflow and flexibility.

Form Factor: Mid Tower
Dimensions: 22.3" × 12.9" × 19.8"
Motherboard Support: E-ATX / ATX / mATX / Mini-ITX
Storage: 7 x 3.5" + 6 x 2.5". Okay, but not great for dedicated NAS use.
Cooling: Includes 3 140mm fans. This case can support up to 11 fans. One of the best for airflow. Additionally, it can also support up to 3 rads.
Cable Management: Excellent, thanks to the dual chamber. Cables route cleanly, even with multiple drives and fans.
Noise: With high-RPM fans, it gets loud. Replace them for silence.
Build Quality: Very solid. Premium glass and thick panels.
Build Material: Steel, tempered glass, plastic
Pain Points: Heavy. Top I/O not ideal for under-desk setups.

Verdict: This case is suited for high-performance setups like gaming, media playback, VMs, or creative workstations. It’s overkill for pure storage but works if you want fancy cooling and extra headroom.

Thermaltake CTE C700 TG

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Phanteks Enthoo Pro TG

Manufacturer’s Link: Phanteks
Price: 💰💰💰

This case is starting to show its age, but it still holds up if you manage your expectations. You get decent drive support, solid build quality, and enough room for fans, but airflow and cable management don’t match what newer cases offer.

It was top-tier back in 2016. Today? It’s functional, not exceptional. If you already own it, it’s worth using. But if you’re shopping for something new, there are better options on the market.

Form Factor: Full Tower
Dimensions: 21.1" × 9.3" × 21.7"
Motherboard Support: SSI-EEB / E-ATX / ATX / mATX / Mini-ITX
Storage: 6 x 3.5", 4 x 2.5". Good for mid-size builds.
Cooling: One front fan and one rear fan are included. Airflow is okay, but you’ll want more fans.
Cable Management: Lots of tie points and channels. Easy to keep tidy.
Noise: No insulation. Average sound profile.
Build Quality: Decent. Nothing to write home about.
Build Material: Steel, tempered glass, plastic
Pain Points: Vertical GPU mount needs a riser. Build layout is less optimized by today’s standards.

Verdict: This case is dated but dependable. Still usable if you already have it, but if you’re buying new, there are better options for the price.

Phanteks Enthoo Pro TG

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

🟥 C-Tier – Functional with Major Tradeoffs

Corsair 7000D AIRFLOW

Manufacturer’s Link: Corsair
Price: 💰💰💰💰

This case is an absolute monster. Built for custom loops, high-end hardware, and airflow that won’t quit. It’s big, bold, and stunning to look at. But when it comes to media server duty, it misses the mark.

Drive support is the weak link. You’ll be improvising mounts by the time you hit six drives, and it’s clearly not designed with storage in mind. Unless you’re building a dual-purpose gaming and media rig, this is the wrong tool for the job. Beautiful, but not practical for a server.

Form Factor: Full Tower
Dimensions: 21.6" × 9.8" × 23.6"
Motherboard Support: E-ATX / ATX / mATX / Mini-ITX
Storage: 6 x 3.5" and 4 x 2.5" out of the box. You’ll need adapters or mods to expand.
Cooling: 3 140mm fan are included. Supports up to 12 120mm or 7 140mm fans. Top-tier airflow. Fits basically every radiator and fan combo.
Cable Management: Corsair’s RapidRoute system is excellent. 36mm of routing space.
Noise: Loud with stock fans. Quiet down with Noctua or Be Quiet swaps.
Build Quality: Premium all the way. Heavy, rigid, and beautifully finished.
Build Material: Steel, tempered glass, plastic
Pain Points: Expensive, overkill for NAS use, lacking drive expansion out of the box.

Verdict: This case looks amazing and works great for gaming or workstations, but for a media server, the size and cost aren’t worth it. There are better picks for storage and cooling.

Corsair 7000D AIRFLOW

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Cooler Master MasterBox NR400

Manufacturer’s Link: Cooler Master
Price: 💰💰💰

The NR400 is compact, clean, and easy to work with. It has great ventilation, a solid layout, and a breeze to build in. But with support for just 4 drives, it’s not built for serious media server applications.

It’s a good fit for HTPCs, small servers, or setups where storage is handled elsewhere. But if you are planning to scale your media library, you’ll outgrow it quickly.

Form Factor: Mini Tower
Dimensions: 16.2" × 8.3" × 16.2"
Motherboard Support: mATX / Mini-ITX
Storage: 4 x 3.5"/2.5" bays. That’s it.
Cooling: Two 120mm fans included. Good airflow, but not enough for dense builds.
Cable Management: Space is tight. Modular PSU strongly recommended.
Noise: No insulation. Expect fan and drive noise.
Build Quality: Not bad for a mini-tower. Side panel is a bit wobbly.
Build Material: Steel, plastic, tempered glass
Pain Points: Drive cage blocks PSU airflow. Limited upgrade path.

Verdict: Good airflow and a simple layout make it beginner-friendly, but it’s more HTPC than a server case. This case is best for a tiny, low-power build with storage handled elsewhere.

Cooler Master MasterBox NR400

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Final Words

If you are building a home media server, you need to prioritize function over flashy aesthetics. This means thinking about storage, airflow, cable space, and noise before aesthetics or gaming extras. The Fractal Define 7 XL is the top recommendation for anyone serious about capacity and silence. The SilverStone CS380B is the best plug-and-play option if you need hot-swap capabilities. And if you’re building on a budget, the Rosewill Helium or DARKROCK Classico will get you there with a little extra effort.

Pick based on your storage needs, noise tolerance, and build experience. Pick right, and you will only have to buy a case once.

How to Install Radarr in Docker

Sun, 20 Apr 2025 05:50:50 -0600

Automate Your Movie Downloads: A Step-by-Step Guide to Installing Radarr in Docker

If you are like me and love watching movies. However, keeping them organized and up to date can feel like a full-time job. Between release dates, varying quality options, and sources scattered across the internet, managing your movie library can quickly become a frustrating mess.

This is where Radarr comes in. Instead of rummaging through torrent or Usenet sites for that new release or trying to remember when a movie drops digitally, Radarr automates the entire process. It monitors your wanted list, watches for new releases, and grabs them using torrents or Usenet. Once downloaded, it renames, organizes, and moves the files into your media library, ready to watch on Jellyfin, Plex, or Kodi.

Radarr lets you set it and forget it.

Why Radarr Is a Must-Have

Here’s why Radarr is my go-to tool for movie automation:

Automated Downloads – Add the movie you want, and Radarr will handle the rest. It’ll search for it, download it, and upgrade it when better quality becomes available.
Missing Movie Search – Radarr continuously scans for movies that are missing or were not available when you added it.
Integration with Download Clients – Works seamlessly with qBittorrent, Deluge, SABnzbd, and NZBGet.
Library Management – Organizes downloaded movies into clean folder structures, complete with proper naming and metadata.

Radarr transforms your movie library into a hands-off system that just works.

Why Run Radarr in Docker?

Docker is the one of the best ways to run it. Here’s why:

Clean Isolation – Keep Radarr and its dependencies separate from your main system.
Effortless Updates – Updating is as easy as pulling the latest image.
Portability – Easily move your setup to another machine.
Simplified Maintenance – Avoid dependency hell and conflicting libraries.

Running Radarr in Docker keeps things clean, organized, and easy to manage, update, and troubleshoot.

If you’re ready to take control of your digital movie collection, setting up Radarr in Docker is the way to go.

Step 1: Install Docker

To get started, you’ll need Docker installed on your server.
Check out this guide for step-by-step instructions: Master the Basics - How to Install Docker

Step 2: Create or Modify Your Docker Compose File

Let’s define your Radarr container using docker-compose.yml. In this post we will be adding Radarr to our existing docker-compose.yml that contains the settings for Sonarr. Post: How to Install Sonarr in Docker

Open the Compose File

Open your existing docker-compose.yml or create a new one:

nano /docker/docker-compose.yml

Then, copy and paste the Radarr Section:

services:

  #################################
  ##  SONARR                     ##
  #################################
  sonarr:
    # Official LinuxServer.io Sonarr image
    image: lscr.io/linuxserver/sonarr:latest
    # Sets a custom name for the container
    container_name: sonarr
    # Name and location of the .env file
    env_file: .env
    # Ensures the container restarts if it crashes
    restart: unless-stopped
    ports:
      - ${SONARR_PORT}:8989
    volumes:
      # Stores Sonarr's configuration data 
      - ${CONFIG_PATH}/sonarr:/config
      # Directory where downloaded TV shows are stored  
      - ${MEDIA_PATH}/Shows:/tv
      # Directory where incomplete downloads are stored  
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      # Connects the container to the custom media network  
      - media_network

  #################################
  ##  RADARR                     ##
  #################################
  radarr:
    # Official LinuxServer.io Radarr image
    image: lscr.io/linuxserver/radarr:latest
    # Sets a custom name for the container
    container_name: radarr
    # Name and location of the .env file
    env_file: .env
    # Ensures the container restarts if it crashes
    restart: unless-stopped
    ports:
      - ${RADARR_PORT}:7878
    volumes:
      # Stores Radarr's configuration data
      - ${CONFIG_PATH}/radarr:/config
      # Directory where downloaded Movies are stored  
      - ${MEDIA_PATH}/Movies:/movies
      # Directory where incomplete downloads are stored
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      # Connects the container to the custom media network  
      - media_network

#################################
##  NETWORK                    ##
#################################
# Creates an isolated Docker network for media containers
networks:
  media_network:
    driver: bridge

💡 Tip: Make sure the spacing is correct. YAML is very picky about spacing. The key is that each indent is two spaces not a tab.

Step 3: Customize the .env File

Open the .env File

nano /docker/.env

The content of the .env file should look like this:

# User and Group ID (Prevents permission issues)
# Main user ID
PUID=1000
# Our media group:
PGID=1001

# Timezone (Ensures correct scheduling and logs)
TZ=America/Denver

# Define Ports (Ports for each container are defined here)
# Maps Radarr’s web UI to port 7878 on the host
RADARR_PORT=7878
# Maps Sonarr’s web UI to port 8989 on the host
SONARR_PORT=8989

# Data Directories (Keeps storage paths centralized)
CONFIG_PATH=/docker
DOWNLOADS_PATH=/media/downloads
MEDIA_PATH=/media

Update the Radarr file paths as needed. Here’s what to change:

CONFIG_PATH=/docker → Root folder where Docker stores persistent files.
MEDIA_PATH=/media → Root folder for your media files
DOWNLOADS_PATH=/media/downloads → Root folder where your download client stores temp/incomplete files

Make sure the download client container shares access to the /downloads path.

Also update the timezone (TZ) to match yours.
Refer to: This list of valid timezones.

Step 4: Start Radarr

Bring your new Radarr container online:

docker compose up -d

Check it’s running:

docker ps

You should see radarr in the list of containers:

CONTAINER ID   IMAGE                               COMMAND   CREATED          STATUS          PORTS                                         NAMES
c8d2c60a955b   lscr.io/linuxserver/sonarr:latest   "/init"   54 seconds ago   Up 53 seconds   0.0.0.0:8989->8989/tcp, [::]:8989->8989/tcp   sonarr
ff12a474a4fe   lscr.io/linuxserver/radarr:latest   "/init"   54 seconds ago   Up 53 seconds   0.0.0.0:7878->7878/tcp, [::]:7878->7878/tcp   radarr

Step 5: Fix Permissions (If Needed)

Permissions issues are a common snag with media containers. Here’s how to make sure everything plays nice:

sudo chown -R `yourusername`:media /docker/ && sudo chmod -R 770 /docker/
sudo chown -R `yourusername`:media /media/ && sudo chmod -R 770 /media/

Check out this post if you want to learn more about Linux permissions:
Master the Basics - Linux Permissions

Step 6: Access Radarr

Open your browser and go to:

http://your-server-ip:7878

From there, you can add movies, set quality profiles, and connect your favorite download clients.

For detailed configuration help, check the official Radarr Wiki.

Step 7: Keep Your Docker Software Updated

To update:

docker compose pull  # Fetches the latest image
docker compose down  # Stops and removes the running container
docker compose up -d  # Starts a fresh container with the new image

Radarr and Sonarr will restart with the latest version, no reconfig needed.

Conclusion

Radarr is an absolute game-changer for movie lovers. It tracks, downloads, upgrades, and organizes your collection automatically. No more hunting for files, renaming, or manually moving stuff around.

Running it in Docker makes everything easier to manage and keeps your system clean. And when you combine it with other tools like Sonarr for TV shows or Lidarr for music, you’re well on your way to a fully automated, self-updating media empire.

How I Fixed My 24 Hour NFS Crash Loop With MergerFS LXC and Proxmox

Fri, 11 Apr 2025 06:52:23 -0600

Every professional and/or weekend warrior sysadmin has that one issue that haunts them. For me, this week, it was a weird NFS crash loop that kicked in like clockwork. Every 24 hours, like it was on a timer (it was, my backups were running). The server booted, NFS shares mounted fine, and media apps ran smoothly. Looked solid. Then… boom. NFS would stop responding. Containers started throwing stale file handle errors and memory usage shot through the roof.

I spent days chasing ghosts trying to figure it out. If you’re running NFS exports from a MergerFS-backed VM in Proxmox, especially with LXC clients, here’s what fixed it for me and why you should check your setup too.

Stack Snapshot

Before we dig into the fix, here’s what my setup looked like:

Proxmox host with a ZFS RAIDZ1 pool
NAS VM with an HBA passing through XFS drives, combined using MergerFS
MergerFS presenting /media/Storage
NFS server inside the NAS VM, exporting that MergerFS mount
LXC containers (Sonarr, Jellyfin, etc.) mounting those exports as clients

On paper, this setup checks out. But under the hood, it was primed for failure thanks to one small flag: noforget.

Where Things Went Sideways

It wasn’t obvious at first. But symptoms started stacking:

VM would freeze after ~24 hours
LXC clients hit “stale file handle” errors
Slab memory ballooned, especially fuse_inode (Over 110,000 inodes)

That last part was the key. Hundreds of thousands of inodes hanging around with no cleanup.

Wait—What’s an Inode?

Think of an inode as the metadata brain behind every file in a Linux filesystem. It stores everything about the file except its name and contents. That means stuff like:

File size
Permissions
Owner and group
Timestamps
Pointers to where the actual data lives on the disk

Every time you create, read, or move a file, the system checks the inode to figure out what it’s dealing with. The inode number is what NFS uses to track files across the network. If those numbers change or pile up, things can get ugly fast, especially with MergerFS and NFS in the mix.

Smoking Gun: `noforget` in MergerFS

Here’s what I originally had for my MergerFS entry in /etc/fstab:

/mnt/Pool0/Disk* /media/Storage fuse.mergerfs direct_io,defaults,allow_other,noforget,dropcacheonclose=true,category.create=mfs,minfreespace=50G,fsname=storage 0 0

The noforget flag was the root of my problems.

What it does:
Prevents the kernel from purging unused FUSE inodes. Great for certain workloads. Awful for MergerFS over NFS.

What happened:
Every NFS client interaction added more FUSE inodes. The kernel kept them all. Memory usage exploded. Stability collapsed.

You Can Check Your `fuse_inode`

Run this:

cat /proc/slabinfo | grep fuse_inode

Before the fix, mine hit 100,000+ entries. After? Around 200. Immediate memory relief.

The Fixes That Saved My Sanity and Marriage

1. Replace `noforget` with `inodecalc=path-hash`

I replaced noforget from my MergerFS options with this instead. This is key for NFS stability. Without it, inode numbers jump around and NFS freaks out. New MergerFS line in /etc/fstab/:

/mnt/Pool0/Disk* /media/Storage fuse.mergerfs direct_io,defaults,allow_other,dropcacheonclose=true,category.create=mfs,minfreespace=50G,inodecalc=path-hash,fsname=storage 0 0

Now FUSE inodes are purged normally, and NFS clients get consistent inode numbers.

2. Boost `vfs_cache_pressure`

Force the kernel clean inodes and dentries more aggressively. In /etc/sysctl.conf:

echo vm.vfs_cache_pressure=200 | sudo tee -a /etc/sysctl.conf

Then reboot or run:

sudo sysctl -p

3. Change Proxmox Disk Cache to `writethrough`

In the Proxmox VM Hardware settings, switch the disk cache mode to:

cache=writethrough

It forces better consistency between Proxmox, ZFS, and your VM’s disk I/O.

What Stability Looks Like Now

After these changes:

No more stale handles or NFS hangs
fuse_inode count is flat — around 8,000 after days of uptime
Memory usage is predictable
LXC clients mount and run cleanly — even under load

Quick Fix Table

Tweak	Why It Matters
❌ Remove `noforget`	Stops memory leaks via inode bloat
✅ Add `inodecalc=path-hash`	Prevents NFS from freaking out
⚙️ Set `vfs_cache_pressure=200`	Cleans up unused inode/dentry entries
💽 Use `writethrough` in Proxmox	Improves disk I/O behavior with ZFS
👀 Monitor `/proc/slabinfo`	Catch inode bloat before it breaks stuff

TL;DR

NFS + MergerFS + Proxmox VM + LXC? Check your MergerFS flags.

Specifically:

Ditch noforget. Add inodecalc=path-hash. Crank vfs_cache_pressure. Set Proxmox disk cache to writethrough.

These four config change saved my server from a daily crashes. If your NFS setup feels haunted, you might want to start here.

Try it. Save your sanity and sleep again.

Hardware - Why You Need an HBA

Sun, 06 Apr 2025 08:14:46 -0600

Ever hit a wall with your media server setup? Maybe you maxed out your motherboard’s SATA ports. Or you want to hand control of your drives to a VM in Proxmox without the host getting in the way. That’s where a Host Bus Adapter (HBA) becomes your best friend. It’s your ticket to smoother storage configuration, more drives, and better performance, especially if you’re running a virtualized environment.

Here’s what you need to know: when to use an HBA, why it works great in virtual storage VMs, what cables you’ll need, and how to buy an HBA that works out of the box.

What’s an HBA and When Should You Use It?

A Host Bus Adapter (HBA) is a PCIe card that gives your server more drive connectivity than your motherboard can. Think of it as a high-performance SATA or SAS controller, just way more capable than those cheap expansion cards that drop drives under load.

You’ll want one if:

You’re out of SATA ports. Most motherboards provide you with six. If you’re running a Plex or Jellyfin server, you’ll blow through those fast.
You’re using Proxmox or any hypervisor. Want to pass your drives directly to a VM? You need an HBA flashed to IT mode.
You care about reliability. HBAs are built to handle a bunch of drives without dropping them randomly like bargain-bin SATA controllers.

When to Use an HBA

Problem	HBA Fixes It By…
Not enough SATA ports	Expands drive capacity (8+ drives)
Running Proxmox VMs	Allows direct passthrough to VM
Cheap SATA cards unreliable	Provides stable, enterprise-grade control
Want future expansion	Supports SAS expanders (24+ drives)

HBAs in Virtual Storage VMs (This Is Where They Shine)

Running a NAS in a VM? Stop fighting your hypervisor. Pass the HBA straight to the storage VM and let it take over.

1. Direct Passthrough = Better Performance

Instead of juggling drive access through the host, pass the HBA to your VM. That VM gets direct, raw control over the drives. Perfect for ZFS, MergerFS, or SnapRAID.

2. IT Mode: No RAID, No Nonsense

Flashing the HBA to IT mode removes the RAID stuff. The VM sees each drive on its own, just like it should. This avoids weird RAID layers interfering with smart tools or parity calculations.

3. Fewer Headaches, More Stability

Onboard SATA gets weird in VMs. Unreliable, slow, or just flaky. An HBA gives you dedicated hardware built for this job.

4. Room to Grow

Planning for expansion? A single HBA can talk to a SAS expander and let you run 24 or more drives through one PCIe slot.

How to Buy an HBA That Just Works

Get One Already Flashed to IT Mode

Most used enterprise HBAs ship with RAID firmware (IR mode). You want IT mode. This makes each drive show up independently.

Popular models:

LSI 9211-8iB

Already Flashed to IT mode.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

LSI 9300-8i

Already Flashed to IT mode.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Dell H310

Already Flashed to IT mode.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Also look for pre-flashed cards on:

eBay (Search for “IT mode HBA”)
Server resellers with refurb listings

They usually run $50 to $100. Cheap, considering the performance and stability boost.

Need More Drives? Get a SAS Expander

If 8 ports aren’t enough, plug a SAS expander into your HBA.

What It Does

Think of it like a network switch for hard drives. You plug the HBA into the expander, and the expander gives you dozens of ports.

Why It’s Useful

More drives per HBA – Some expanders support 24 or more drives.
Fewer PCIe slots used – Leave room for GPUs, NICs, or other gear.
Lower cost – Expanders cost less than more HBAs.

Popular SAS Expander

Intel RES2SV240

Compact and solid for home labs.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Cables: Here’s What You Need

HBAs don’t use regular SATA ports. They use SFF connectors.

SFF-8087 to 4x SATA

Used for older HBAs like the LSI 9211-8i.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

SFF-8643 to 4x SATA

Used for newer HBAs like the LSI 9300-8i.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

If you’re using an expander, you’ll also need:

SFF-8087 to SFF-8087

Used for older HBAs like the LSI 9211-8i.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

SFF-8643 to SFF-8087

Used for newer HBAs like the LSI 9300-8i.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

HBA Port Type	Use This Cable
SFF-8087	SFF-8087 to 4x SATA
SFF-8643	SFF-8643 to 4x SATA
Expander Link	SFF-8087 ↔ SFF-8087

Wrap-Up: Yes, You Should Use an HBA

Want to scale up? Make your VM manage your drives directly? Avoid janky SATA cards? Then an HBA flashed to IT mode is a must. Pair it with an expander if you’re going big. Use the right cables. And your home media server just leveled up.

Skip the guesswork. Get an HBA Controller.

SABnzbd vs NZBGet: Which NZB Downloader Should You Choose in 2026?

Sat, 29 Mar 2025 06:26:41 -0600

Choosing between SABnzbd vs NZBGet matters more than most folks realize. Back in the day, using Usenet meant spending hours manually unpacking, repairing, and organizing downloads. Today, tools like SABnzbd and NZBGet handle all of that for you. The hard part now? Choosing which one to use.

If you’re brand new to Usenet or building your first DIY media server, this decision matters more than it seems. Pick the wrong downloader, and you’ll end up fighting settings, broken automation, or maxed-out hardware. Pick the right one and Usenet becomes a true set-it-and-forget-it experience.

This guide breaks down the sabnzbd vs nzbget debate from a beginner’s point of view. I’ll focus on ease of setup, real-world performance, automation, and long-term support, so you can confidently choose the best NZB downloader for your setup in 2026.

💭

TL;DR: If you’re new to Usenet and want the easiest and least frustrating experience, SABnzbd is the winner. NZBGet is faster and lighter, but SABnzbd’s guided setup, polished interface, and straightforward automation make it the better choice for most beginners.

What Are SABnzbd and NZBGet?

Before comparing them, let’s define what they are.

Both SABnzbd and NZBGet are NZB download managers, software that automates Usenet downloads.

They:

Download files from Usenet using NZB files
Repair missing parts with PAR files
Unpack archives
Rename and sort files
Hand everything off to apps like Sonarr or Radarr

In short, they’re the backbone of any Usenet-based media server.

The difference is how they do it and how much effort they require from you. And, that effort adds up fast when you’re just trying to get things working.

SABnzbd vs NZBGet: Performance and System Requirements

Raw Speed and Resource Usage

Alright, this is the one area where NZBGet clearly wins.

NZBGet is written in C++, which makes it extremely efficient. It uses less CPU, less RAM, and generally downloads faster on the same hardware. Real-world reports show noticeable speed differences, especially during heavy post-processing like repairing and unpacking large files.

SABnzbd is written in Python. Python is easier to maintain and extend, but it costs more CPU cycles. During unpacking and repair, SABnzbd can briefly spike CPU usage, which matters on weaker systems.

📝

Note: On a Raspberry Pi 4 downloading a 50GB file, NZBGet typically uses 15-20% less CPU during unpacking and completes the job 10-15% faster.

Here’s the thing though, for most people, this doesn’t matter as much as you might think.

Decisions:

If you’re running on a Raspberry Pi, older Intel CPU, or NAS hardware → Choose NZBGet
If you have a modern mini PC, desktop CPU, or home server → Either works fine

Even low-end Intel N100 and Ryzen mini PCs handle SABnzbd without breaking a sweat. Hardware is no longer the bottleneck for most beginners.

Setup and Installation: NZBGet vs SABnzbd

SABnzbd: Built for Beginners

This is where SABnzbd earns its reputation.

On first launch, SABnzbd walks you through a clean setup wizard:

Enter your Usenet provider
Test the connection
Pick download and completed folders
Enable basic security options

You can be downloading within minutes, even if you’ve never touched Usenet before. The defaults are sensible, and most users never need to touch advanced settings.

NZBGet: More Control, More Work

NZBGet installs easily, especially via Docker or NAS app stores. The challenge comes after installation.

Many important behaviors require manual configuration:

Paths
Post-processing options
Security settings
Script behavior

None of this is impossible, but it assumes you know what you’re configuring and why. And honestly? When you’re just starting out, you probably don’t.

Example setup flow:

SABnzbd: Install → Run wizard → Start downloading
NZBGet: Install → Configure paths → Set up categories → Configure post-processing → Start downloading

See the difference? SABnzbd gets you downloading in three steps. NZBGet needs five, and each one requires you to understand what you’re doing.

RaspberryPi 4GB A low-cost, beginner-friendly platform for running SABnzbd or NZBGet, making it ideal for novices following this guide.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Web Interface and Day-to-Day Usability

SABnzbd Interface

SABnzbd has one of the cleanest web interfaces in the Usenet world.

Modern layout
Clear queue view
Multiple themes
Easy access to logs and warnings

You always know what’s downloading, what failed, and why. For novices, this matters more than raw speed. Visibility prevents frustration.

I can’t tell you how many times I’ve avoided a headache because SABnzbd showed me exactly what went wrong instead of making me dig through logs.

NZBGet Interface

NZBGet’s interface is fast and minimal. It works well, but it assumes you already understand Usenet terminology.

It shines when customized with widgets and scripts, but out of the box it feels utilitarian rather than welcoming. NZBGet will get the job done, but you won’t enjoy looking at it.

Automation and Arr App Integration

SABnzbd: Plug and Play Automation

SABnzbd integrates seamlessly with:

Sonarr
Radarr
Lidarr

No scripts required. You point the Arr apps at SABnzbd, map your folders, and you’re done.

Basic Sonarr integration:

Sonarr Settings → Download Clients → Add SABnzbd
Host: localhost
Port: 8080
Category: tv
Completed Download Handling: Enabled

SABnzbd also excels at:

Handling obfuscated NZBs (those weirdly-named files that trip up other downloaders)
Renaming files reliably
Sorting downloads without manual rules

What success looks like: After adding SABnzbd to Sonarr, you’ll see a green checkmark in the download client settings. Your first episode will download, unpack, and appear in your media library without you touching anything.

NZBGet: Powerful but Script-Driven

NZBGet supports everything SABnzbd does, and often more, but frequently through scripts or additional configuration:

Custom post-processing
Advanced RSS filters
RPC API access

Both tools integrate with Arr apps just fine. SABnzbd tends to work out of the box, while NZBGet may need category mapping or post-processing scripts for complex workflows.

📝

Note: If you love tinkering, NZBGet gives you more knobs to turn. But if you just want your shows to download while you sleep? SABnzbd gets you there faster.

Power Efficiency and Background Behavior

This is a subtle but potentially important difference for 24/7 systems.

SABnzbd uses iNotify on Linux systems, which allows it to detect new files instantly without constantly scanning folders. This can reduce background CPU usage and allows systems to sleep when idle.

NZBGet periodically rescans folders, which may:

Prevent sleep modes
Use more background CPU
Increase power consumption on always-on systems

The real-world impact varies by system and configuration. On modern hardware, the difference is typically small but can add up over time on power-conscious setups.

If you’re running a home server 24/7 and care about your power bill, this is worth considering. Five watts here, ten watts there, it adds up over a year.

Seagate Barracuda 24TB Internal Hard Drive Large storage is essential for media server users downloading content with SABnzbd or NZBGet, but this drive is best for single-drive/light-duty setups, not advanced NAS.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Long-Term Support and Updates

SABnzbd

Frequent updates
Active development
Large user community
Excellent documentation

From a stability and security perspective, SABnzbd is the safer long-term choice. When something breaks, SABnzbd usually has a fix within days.

NZBGet

NZBGet development slowed significantly after 2019, which raised concerns in the community. Development has recently picked back up under new maintainers, but the update cadence is still less predictable.

It remains stable and functional, but beginners typically benefit from active ecosystems. You want a tool that’s being actively maintained when you run into issues.

SABnzbd vs NZBGet Comparison Table

Feature	SABnzbd	NZBGet
Performance	Higher resource usage	Extremely lightweight
Setup	Wizard-driven, beginner-friendly	Manual configuration
Interface	Polished and modern	Minimal and utilitarian
Automation	Plug and play	Script-based options
Power Efficiency	iNotify-based monitoring	Folder rescans
Updates	Frequent and consistent	Less predictable
Best For	New users, automation	Low-power hardware

Troubleshooting Common Beginner Issues

Downloads Are Slow

Check Usenet provider connection limits (most cap you at 20-30 connections)
Verify SSL is enabled (it should be, but double-check)
NZBGet may outperform SABnzbd on weak CPUs

Files Fail to Unpack

Enable automatic repair and unpack (should be on by default in SABnzbd)
Ensure enough free disk space (you need at least 2x the download size)
Avoid moving files before post-processing finishes, let the downloader finish its job first

Sonarr or Radarr Cannot See Downloads

Double-check folder mappings, especially in Docker (this trips up everyone at least once)
Confirm completed download paths match Arr app settings exactly

High CPU Usage During Downloads

Normal during unpacking, that’s just how PAR repair works
Consider NZBGet if running on older hardware
Schedule downloads for off-hours if it’s bothering you

Fractal Design Define R5 A quiet, flexible case helps beginners build a tidy, expandable media server for SABnzbd/NZBGet, though not strictly required if reusing existing hardware.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

FAQs: NZBGet vs SABnzbd 2026

➤ Which is faster, NZBGet or SABnzbd?

NZBGet is typically faster and more efficient due to its C++ architecture. The difference is most noticeable on low-powered hardware.

➤ I have a Raspberry Pi or NAS. What should I use?

NZBGet. It was built for low-resource systems, and you’ll actually notice the performance difference.

➤ Which is easier for beginners?

SABnzbd. The setup wizard, interface, and defaults are designed for novices. You’ll be downloading in minutes instead of hours.

➤ Can both integrate with Sonarr and Radarr?

Yes. SABnzbd tends to work out of the box, while NZBGet offers deeper customization options if you need them.

➤ Which one uses less power?

SABnzbd typically uses less background power thanks to iNotify-based file monitoring, though the difference varies by setup.

➤ Which one should I pick if I'm unsure?

Start with SABnzbd. You can always switch later if you outgrow it, but honestly? Most people never do.

Conclusion: SABnzbd vs NZBGet Winner

After going back and forth between these two for years, I always end up back on SABnzbd.

Yes, NZBGet is faster and lighter. But SABnzbd wins the sabnzbd vs nzbget debate where it matters most for beginners:

Easier setup
Better interface
Cleaner automation
More predictable updates

If you want something that just works and stays out of your way, SABnzbd is the best choice for 2026.

If you’re running very limited hardware or love tweaking every detail, NZBGet still has a place. For everyone else? Start with SABnzbd and enjoy Usenet the way it was meant to be used—automatically, reliably, and without constant babysitting.

Resources

SABnzbd Official Documentation

Visit

NZBGet Official Documentation

Visit

Sonarr Integration Guide

Visit

Radarr Integration Guide

Visit

Amazon Fire TV Stick 4K Useful for streaming downloaded media to a TV, but not necessary for running SABnzbd/NZBGet or building the server itself.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Usenet vs Torrenting: Which Is Best for Your Media Server in 2026?

Fri, 21 Mar 2025 06:52:48 -0600

If you’re building a home media server with Jellyfin, Kodi, Plex, Emby, or whatever your flavor, you quickly run into the same question everyone does:

How do I actually get the media?

For most people, the choice comes down to Usenet or torrenting. They both work, are popular and they both can be automated. But they feel very different once you actually live with them day to day.

I used torrents for years. They worked, but between sketchy files, malware scares, dead downloads, and always needing a VPN, I eventually hit a point where I just wanted something easier, even if it cost a few extra dollars a month.

This post breaks down the Usenet vs torrent comparison, so you can make the choice between these systems for your media server, without hype or gatekeeping. You’ll learn which system fits your priorities: speed, cost, privacy, or automation and what trade-offs each one brings.

💭

TL;DR: If you want free and familiar, torrents still work. If you want speed, privacy, automation, and fewer headaches, Usenet usually wins for home media servers, even if it costs a bit each month.

Quick Comparison: Usenet vs Torrent

Factor	Torrents	Usenet
Cost	Free (VPN ~$5/mo)	~$10-15/mo total
Speed	Depends on seeders	Maxes your connection
Privacy	VPN required	SSL encrypted (No VPN needed)
Automation	Good with setup	Excellent
Old content	Depends on seeders	Up to 18 years or more retention
Setup complexity	Simple	Moderate

Usenet vs Torrenting: What Are You Really Choosing?

Before we compare pros and cons, let’s talk about what problem each system actually solves.

Torrents (P2P downloading)

Torrents use peer-to-peer sharing. When you download a file, you’re pulling pieces from other users (seeders) who already have it, while also uploading pieces you have to others. It’s a community effort, which sounds great until you realize that means you’re dependent on that community to share the content you want.

You usually need:

A torrent client like qBittorrent
A tracker (public or private)
A VPN if you care about privacy (unless you like getting nasty letters in the mail from your ISP)

Usenet (NZB-based downloading)

Usenet uses centralized servers run by providers. Files are uploaded once, then stored for years. When you download, you pull directly from those servers using an NZB file as a map. No peers, no sharing, just a direct line to the content.

You usually need:

A Usenet provider (paid)
An indexer (to find content, usually paid)
A downloader like SABnzbd or NZBGet

Look, if this sounds more complex, it can be at first. But it also unlocks a lot of automation that makes your life way easier down the road.

If you want the deeper history? Check out these other posts:

History of Torrents
How P2P Changed the Way We Share Files

View Article

History of Usenet
And How It Powers NZB Media Downloads Today

View Article

Torrents: Pros, Cons, and Reality in 2026

Pros of Torrents

Free to use - No subscriptions needed (though you’ll want a VPN)
Huge content library - Almost anything popular has been torrented
Resumable downloads - Pick up where you left off, even days later
Simple starting point - Install client, click magnet link, done

Cons of Torrents

Here’s where it gets real.

Speed depends on seeders - Few seeders means slow or dead downloads. You’ll sit there watching a 4K movie crawl at 200KB/s because three people are seeding and two of them are on dial-up. Okay, maybe not dial-up, but it feels like it.
Privacy exposure - Your IP is visible to peers and trackers. Everyone can see you.
Higher legal risk - Copyright monitoring is easier with P2P. Those cease-and-desist letters? They come from torrent activity.
Dead torrents happen - If nobody seeds, the file is gone. I’ve spent hours hunting for a specific release only to find every torrent has zero seeders.
Sketchy files exist - Public torrents can include malware or junk. You wanted a movie, you got a .exe file. Do not run any executable files found in torrents.

NVIDIA SHIELD Pro
Acts as a robust Jellyfin/Plex client and server, making it easy to stream downloaded content to your TV.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Usenet (NZB): Pros, Cons, and Why It Feels Different

Pros of Usenet

Very fast downloads - Direct from high-bandwidth servers. You can max out your gigabit connection, every single time. No waiting, no hoping someone seeds.
Better privacy by default - SSL encryption, no peer exposure. You’re not broadcasting to strangers.
Long retention - Top providers offer 18+ years of file storage. That obscure show from 2008? Still there.
Excellent automation - Pairs seamlessly with Sonarr, Radarr, and the rest of the *arr stack. Set it and forget it.
Consistency - If the NZB exists and your provider has it, it downloads. No “check back later, maybe someone will seed.”

Cons of Usenet

Nothing’s perfect.

It costs money - $7.50-20/month for unlimited plans. For some people, that’s a dealbreaker. I get it.
More pieces to set up - Provider + indexer + downloader. It’s not complicated, but it’s more than “install qBittorrent.”
DMCA takedowns happen - Content can be removed faster than torrents. Popular stuff gets hit within hours sometimes.
Retention is not infinite - Files age out after many years.
Sketchy files still exist - Although I have encountered less on Usenet, they do still exist. Do not run any executable files found in NZBs.

Privacy and Safety

Let’s talk about what actually protects you, because there’s a lot of misinformation out there.

Torrents and VPNs

If you torrent, a VPN is basically mandatory. But here’s what most guides skip: bind your torrent client to the VPN interface. This prevents downloads if the VPN disconnects (Also known as a kill switch).

Without this, your real IP can leak during connection drops. And it will drop. VPNs aren’t perfect. I learned this the hard way when my ISP sent me a friendly letter about a download that happened during a very short VPN hiccup.

Five minutes setting up interface binding saves you from that.

Usenet Privacy Limits

Usenet feels more private because you’re not sharing with peers, and SSL encrypts the connection. But let’s be clear: providers still log your activity, and your payment method links to your identity.

SSL only protects data in transit, not metadata about what you downloaded. If someone really wants to know what you’re doing, they can find out. It’s just way harder than with torrents, where your IP is literally broadcast to everyone.

NZB vs Torrent: Indexers and Trackers Explained

This is where many beginners get confused, so let me break it down.

Torrent Trackers

Trackers coordinate who has which pieces of a file. They’re like a phonebook for the swarm.

Public trackers are easy but unreliable. Anyone can use them, which means quality varies wildly.
Private trackers are reliable but invite-only. You’ll need to maintain a ratio (upload as much as you download) or get kicked.

Trackers don’t host files. They just help peers find each other. When a tracker goes down, your torrents stop working until it comes back.

Usenet Indexers

Indexers catalog Usenet posts and generate NZB files. Think of them as search engines for Usenet.

Good indexers show completion rates, file health, and categories
Some are free, some require invites, some cost money
You’ll want at least two indexers for coverage

Indexers make Usenet automation work, especially with Prowlarr (which manages all your indexers in one place). Without a good indexer, Usenet is basically useless.

LSI 9211-8iB IT MODE Useful for expanding storage with multiple drives in a DIY NAS or media server, but only needed if you plan to scale beyond a few disks.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

Decision Guide: Usenet vs Torrenting for Your Setup

Alright, so which one’s right for you?

Choose Torrents if:

You want zero monthly cost and don’t mind the VPN subscription
You’re comfortable using a VPN at all times (and binding it properly)
You mainly download popular, well-seeded content
You don’t mind occasional dead or slow downloads

Choose Usenet if:

You want fast, consistent downloads without the seeder lottery
You value privacy without mandatory VPN usage
You want full automation with media management tools
You’re okay paying a small monthly fee for the convenience

Budget reality check

If your budget is under $10 per month, here’s what I’d do:

Try Usenet free trials first. Most providers offer them. See if it works for you. If it feels too complex or limited, fall back to torrents + VPN. There’s no shame in that. Torrents still work, they’re just more hands-on.

Basic Setup Overview (High Level)

Let’s walk through what you’re actually signing up for with each system.

Torrent setup in practice

Install qBittorrent
Subscribe to a VPN and bind the client to VPN interface (seriously, do this)
Add trackers (public or private)
Optional: connect Sonarr (TV shows) and Radarr (movies) via Prowlarr

What success looks like: You click a magnet link, the download starts immediately, and your VPN shows as connected. If you disconnect the VPN, downloads pause automatically.

If downloads are slow, check seeders. If there are fewer than 10, expect problems. That’s just how P2P works.

Usenet setup in practice

Choose a provider (trial first—don’t commit until you’ve tested)
Join one or two indexers
Install SABnzbd or NZBGet
Add provider details, enable SSL
Connect Sonarr and Radarr via Prowlarr

What success looks like: You add a show to Sonarr, and within minutes it’s downloading at full speed. No waiting, no checking seeders, just done.

If speeds are slow, check that you’re on an unlimited plan and using enough connections (20-60 depending on provider). Some providers throttle if you’re not using their recommended settings.

Hybrid Approach: Best of Both Worlds

Here’s what many experienced homelab users actually do:

Usenet as primary for new and popular media
Torrents as backup for rare or niche content

This gives you speed and automation without losing coverage. Sonarr and Radarr can search both simultaneously, grabbing from whichever source has the best release.

I’ve been running this setup for 10 years. Usenet handles 95% of my downloads, torrents catch the rest. It’s the best of both worlds, and honestly, once you’ve got it configured, you forget it’s even there.

Seagate Barracuda 24TB Internal Hard Drive Must have for this build. Why it fits this post: Large, reliable storage is essential for both torrent and Usenet media libraries, and this drive offers high capacity for bulk downloads and archiving.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Troubleshooting Common Problems

You’re going to hit issues. Everyone does. Here’s how to fix the most common ones.

Problem	System	Solution
Downloads are slow	Torrents	Check seeders (need 5+), try different tracker, verify VPN isn’t throttling
Downloads never finish	Torrents	Dead torrent. Look for different release with active seeders
Downloads are slow	Usenet	Confirm unlimited plan, increase connections (20-60)
NZBs fail or missing blocks	Usenet	DMCA takedown. Try different indexer or provider
No results in Sonarr/Radarr	Both	Sync Prowlarr, check indexer categories, verify retention settings

FAQs: Usenet vs Torrent Questions

➤ What is the difference between NZB vs torrent files?

A torrent file points to peers sharing pieces of a file. An NZB file points to Usenet servers storing those pieces. Same end result, completely different infrastructure.

➤ Do I need a VPN with Usenet?

Usually no. SSL encryption is standard, and you’re not exposing your IP to a swarm. Some users still use a VPN for extra privacy, but it’s not required like torrenting.

➤ Are there free Usenet providers?

There are free tiers and trials, but they’re limited by speed, data, or retention. You’ll hit those limits fast if you’re actually using it. Think of free tiers as test drives, not long-term solutions.

➤ Why do torrents die, but Usenet files last years?

Torrents need active seeders. If everyone stops seeding, the file’s gone. Usenet’s files are stored on servers for a defined retention period, usually years. The file exists whether anyone’s downloading it or not.

➤ Which is better for old or rare content?

It depends. Usenet has long retention (18+ years on some providers), but private torrent trackers can sometimes win for ultra-niche content. If you’re looking for a specific fansub from 2005, you might need both.

Final Verdict: Usenet vs Torrenting

The Usenet vs torrenting debate really comes down to what you value.

Torrents are free, familiar, and still useful. But they come with trade-offs: slower speeds, privacy risks, dead files, and the constant need for a VPN.

Usenet costs money, but in return you get speed, privacy, automation, and reliability. For me, that trade was worth it. I stopped worrying about sketchy downloads and just let my media server do its thing.

If you’re brand new, try both. Use trials. Break things. Learn what annoys you. Then make your decision.

That’s how you end up with a setup you actually enjoy using.

MINISFORUM MS-A2 Must have for this build. Why it fits this post: A powerful, flexible mini-server that can handle torrent/Usenet clients, indexers, and media server duties with ample I/O for future growth.

Amazon Price: Loading...

Availability: Checking...

Amazon

Contains affiliate links. I may earn a commission at no cost to you.

The History and Usage of Torrents

Sat, 15 Mar 2025 07:29:33 -0600

Back in the early 2000s, the internet was changing rapidly, and new ways to share files were emerging. Traditional downloads had a major problem because servers would get overloaded when too many people tried to access the same file. This led to the development of torrents, which provided a way to distribute data by allowing users to share pieces of a file with each other instead of downloading from a single source. Torrents have been widely associated with piracy, but the technology itself is 100% legal. Many people use torrents to distribute Linux ISOs, share public domain media, and transfer large files efficiently.

If you have ever been curious about how torrents work, how they are used for media, and why people recommend using a VPN when downloading them, this guide will break it down.

What Are Torrents, and How Do They Work?

A torrent is a peer-to-peer (P2P) file-sharing method that relies on a decentralized network. Instead of downloading a file from a single server, torrents allow users to download bits and pieces of the file from multiple users who already have it. This process is coordinated by a BitTorrent client, which connects users and ensures everyone is sending and receiving pieces of the file efficiently.

How the process works:

You download a torrent file or magnet link. This file contains metadata about the content you are trying to download.
Your BitTorrent client connects to a tracker. A tracker is a server that helps coordinate the connections between different users.
You download file fragments from multiple sources. Instead of getting the file from one place, your client pulls bits from users all over the world.
You upload pieces while you download. As you receive parts of the file, your client shares them with others, which speeds up the process for everyone.
The file is reassembled on your device. Once all pieces have been collected, your client puts them together into the final usable file.

This system makes torrenting incredibly fast and efficient, especially for large files.

Before torrents became the dominant method for peer-to-peer (P2P) file sharing, early P2P networks laid the foundation for how digital media was distributed online. These early services were the beginning of digital file sharing, and they influenced how torrents evolved into a more efficient and resilient system.

1. Napster (1999 – 2001): The Beginning of P2P

Napster was the first major P2P file-sharing service to gain mainstream popularity. It allowed users to share MP3 files directly with each other, creating the first large-scale digital music piracy issue. Napster’s centralized nature made it easy to use, but it also made it easy to shut down. In 2001, after a massive legal battle with the Recording Industry Association of America (RIAA), Napster was forced to shut down. However, the concept of P2P file sharing had already taken root.

2. Limewire & Kazaa (2001 – 2010): Decentralization and the Golden Age of P2P

After Napster fell, new P2P networks emerged that were more decentralized, which made them harder to shut down. Limewire and Kazaa became the next big platforms, using the Gnutella and FastTrack networks to share files without relying on a central server.

These programs allowed users to share not just music but also movies, software, and other files. However, they had major issues:

Malware & Viruses: Many downloads came packed with spyware, adware, or outright malicious programs.
Fake Files & Corrupt Downloads: Since there was no verification system, many files were mislabeled or incomplete.
Legal Battles: Like Napster, Limewire and Kazaa were eventually shut down due to lawsuits from copyright holders.

Despite their flaws, these services influenced modern torrenting by proving that decentralized file-sharing networks were the future.

3. How These P2P Networks Shaped Modern Torrents

The downfall of Napster, Limewire, and Kazaa made it clear that centralized P2P networks were too easy to take down. This led to the rise of BitTorrent technology, which improved on past P2P models by:

Using swarming technology. Instead of downloading from one source, BitTorrent splits files into small pieces and downloads them from multiple users, which speeds up transfers.
Eliminating reliance on a single server. Unlike Napster or Kazaa, torrents do not rely on a single central authority, which makes them more resilient to shutdowns.
Providing better file integrity. Torrents use hash checks to verify that each piece of a file is correct, which prevents corrupt downloads.

Essentially, torrents are the evolution of early P2P networks. They fixed many flaws while maintaining the core idea of distributed file sharing.

How Are Torrents Used for Media?

Torrents have played a major role in how media is distributed online. Here are some of the most common legal and practical uses:

1. Distributing Open-Source Software

Many open-source projects rely on torrents to distribute their software. For example, Linux distributions like Ubuntu or Debian offer torrents as a way to download the latest ISO files without overloading their servers.

2. Archiving Public Domain Media

Organizations like The Internet Archive use torrents to distribute massive amounts of public domain books, movies, and music. Since torrents reduce bandwidth costs, they are a great tool for distributing freely available media.

3. Gaming and Large File Transfers

Some game developers, especially in the early days of digital distribution, used torrents to distribute patches or entire game files. This method helps reduce strain on central servers when thousands of users try to download updates at the same time.

4. Peer-to-Peer Streaming

Some platforms have experimented with using torrent-based streaming, where users share video files as they watch, which reduces reliance on a single hosting provider.

The Dark Side of Torrents: Piracy and Legal Issues

While torrents have many legal uses, they have also been widely used for piracy. Some of the most common illegal uses include:

Downloading pirated movies, TV shows, and music from torrent sites like The Pirate Bay.
Sharing cracked software and video games that bypass DRM protections.
Distributing leaked content and pre-release media without authorization.
Spreading malware and scams by disguising harmful files as legitimate downloads.

Legal Consequences of Illegal Torrenting

Many countries have strict anti-piracy laws, and ISPs monitor torrent traffic. If caught downloading copyrighted material, you could face:

Fines.
ISP warnings and throttling.
Lawsuits from copyright holders.

The best way to avoid legal trouble is to only use torrents for legal purposes and download from trusted sources.

Why You Might Need a VPN When Downloading Torrents

Even if you are only using torrents for legal purposes, your ISP (Internet Service Provider) might not be too thrilled. Here is why you might want a VPN when torrenting:

Protect Your Privacy. A VPN hides your IP address from other users in the swarm.
Avoid ISP Throttling. Some ISPs slow down torrent traffic. A VPN prevents this.
Bypass Geo-Restrictions. Some countries block torrent sites. A VPN lets you access them.
Stay Anonymous on Public Trackers. Public torrents expose your IP to thousands of users. A VPN reduces your risk.

Final Thoughts

Torrents have been a game-changer for file distribution, allowing users to share large files quickly and efficiently. Early P2P networks like Napster and Limewire introduced the world to decentralized file sharing, and torrents perfected the concept by making downloads faster, safer, and more efficient.

However, with great power comes great responsibility. While the technology is legal, what you download matters. Always ensure you are using torrents for legal purposes, and consider using a VPN to protect your privacy.

The Rise, Fall, and Rebirth of Usenet

Tue, 11 Mar 2025 07:57:16 -0600

Before Google, social media, or even the World Wide Web, Usenet was the backbone of online communication. It began as a simple way for researchers and tech enthusiasts to exchange information but soon evolved into a massive, decentralized network for discussions, debates, and file sharing. While it may not be as widely known today, Usenet is still active and remains a powerful tool for downloading media through NZB files.

What Is Usenet?

Usenet was created in 1979 as a decentralized system for exchanging messages across a network of servers. Unlike web forums or email, it functioned as a distributed platform where messages, known as “articles,” were copied across multiple servers to ensure accessibility and reliability.

In its early days, Usenet focused on discussion groups, much like an early version of Reddit. These groups, called “newsgroups,” were organized by topics ranging from technology and science to music and movies. Users would post messages, which would then be distributed across multiple Usenet servers, making them accessible for others to read and respond to.

The Evolution of Usenet: From Text to Binaries

As the internet advanced, Usenet’s purpose expanded. By the 1990s, users realized it could do more than host discussions. It could also distribute files. This led to the creation of “binary newsgroups,” where people began sharing images, software, and eventually full-length movies and TV shows.

However, Usenet was not designed for file transfers. Files had to be split into small fragments and posted as separate articles. If even one piece was missing, the file would be incomplete. To solve this problem, the Usenet community introduced the NZB file format, which made downloading files faster and more reliable.

NZB Files: The Modern Usenet Experience

An NZB file works like a torrent file, but for Usenet. Instead of manually searching for and downloading hundreds of file fragments, an NZB file directs your Usenet client to locate all the pieces and assemble them automatically.

Here’s how it works:

Download an NZB file from an indexer, a website that catalogs and organizes Usenet content.
Open the NZB file using a Usenet client such as SABnzbd, NZBGet, or Newsbin.
The client connects to a Usenet provider, retrieves all file parts, and reassembles them into a complete download.

This method is extremely fast, often outpacing torrents because Usenet providers offer direct high-speed downloads without requiring seeding or peer-to-peer connections.

Do You Need a VPN for Usenet?

One of the most common questions from new Usenet users is whether a VPN is necessary for downloading files. The answer depends on your privacy concerns and how your internet service provider (ISP) handles Usenet traffic.

Unlike torrents, where your IP address is exposed to other users in a peer-to-peer network, Usenet downloads are direct connections to a Usenet provider’s servers. This means your activity is not publicly visible. Most Usenet providers also support SSL encryption, which secures your connection and prevents third parties, including your ISP, from seeing what you are downloading.

However, there are still reasons why some users choose to use a VPN with Usenet:

ISP Throttling – Some ISPs slow down Usenet traffic, especially if they detect large downloads. A VPN can mask your Usenet activity, preventing throttling and ensuring maximum download speeds.
Additional Privacy – While SSL encryption secures your data in transit, it does not hide the fact that you are using Usenet. A VPN conceals your internet activity from your ISP and anyone monitoring your connection.
Access to Restricted Content – In some countries, ISPs block access to certain Usenet providers or indexers. A VPN allows users to bypass these restrictions by connecting through servers in other locations.

For most users, an SSL-encrypted Usenet connection is secure enough. But if you want extra privacy, a VPN can provide another layer of protection, ensuring your Usenet usage remains completely anonymous.

Why Choose Usenet Over Torrents?

Usenet offers several advantages over torrents:

Speed: Downloads come directly from high-speed servers, allowing you to fully utilize your internet connection.
Privacy: Unlike torrents, there’s no need to join a peer-to-peer network, which minimizes your exposure and keeps your activity more private.
Retention: Usenet providers typically store files for years, and in some cases, even more than a decade. This makes it easier to find older content that may no longer be available on torrents.

Getting Started with Usenet

If you want to dive into Usenet and NZB downloads, here’s what you’ll need:

A Usenet Provider – Services like Newshosting, Eweka, or UsenetServer give you access to Usenet newsgroups.
An NZB Indexer – These sites help you find NZB files. Some popular ones include NZBGeek, DrunkenSlug, and NZBPlanet.
A Usenet Client – SABnzbd, NZBGet, and Newsbin are great choices for downloading and managing files.

Final Thoughts

While Usenet may not be as well-known as modern streaming services or torrenting, it remains one of the most powerful and efficient ways to download media. Its combination of high-speed downloads, privacy benefits, and long-term file retention makes it an excellent alternative to peer-to-peer sharing. With NZB files simplifying the process, Usenet is now more accessible than ever, even for beginners.

If you value speed, security, and reliability, Usenet is worth exploring. Whether you’re setting up a Usenet client for the first time or fine-tuning an existing setup, there’s always something new to learn.

Master the Basics Dockers Compose

Sat, 08 Mar 2025 05:34:38 -0800

So, you’ve heard about Docker and the magic of containers, but the words “YAML” and “Compose file” sound like something out of a sci-fi movie? Don’t worry. You are in the right place. If you’re new to Docker and wondering how to use a docker-compose.yml file to manage your containers, I’ve got you covered.

When you finish this guide, you’ll know what a Docker Compose file is, how to use it, and why it makes running multiple Docker containers easier.

What Is a Docker Compose File?

At its core, a Docker Compose file is just a simple YAML file (usually named docker-compose.yml) that tells Docker how to run multiple containers together.

Think of it like a recipe. Instead of manually starting each container, setting its configurations, and linking them together one by one, you write it all down in this file, and Docker does the rest.

Why Use Docker Compose?

Docker Compose simplifies container management. Here’s why you should use it:

Easy multi-container setup – Instead of running multiple docker run commands, you define everything in one file.
Portability – Share your docker-compose.yml file to allow anyone to replicate your setup.
Easier management – Start, stop, or restart all your containers with a single command.
Environment variables – Configure your setup using a simple .env file.

Now that you know why it’s useful, I will break down my docker-compose.yml file later in this post.

What Is Orchestration?

Orchestration is just a fancy word for automating how different parts of your system work together.

Think of it like a movie production. You have multiple moving parts that all need to work together seamlessly:

The director ensures everything happens at the right time.
The actors perform their roles based on the script.
The camera crew captures the right angles.
The editors put everything together in post-production.

If each person had to be manually told what to do every single time, it would be chaos. Instead, they follow a predefined plan, and everything runs smoothly without constant micromanagement.

Docker Compose works the same way. Instead of manually starting each container, configuring it, and linking everything together, Docker automates the process so your services interact as expected.

YAML Formatting Rules (Read This or Nothing Will Work!)

Before diving into the actual docker-compose.yml, you must understand YAML formatting because one small mistake in spacing or indentation will break everything. Unlike JSON or XML, YAML relies heavily on proper indentation and formatting.

YAML Rules You Must Follow:

Use spaces, not tabs – Indentation must be done using spaces. Tabs are not allowed.
Consistent indentation – Always use the same number of spaces per level (2 or 4 spaces are common).
Key-value pairs are separated by colons – Example: container_name: radarr.
Lists use dashes (-) – Each item in a list starts with -.
Strings don’t need quotes (but sometimes they do) – Strings are usually fine without quotes, but use double quotes "" if the string contains special characters.
Boolean values (true, false) and numbers don’t need quotes – Just write them as they are.

Example of Correct vs. Incorrect YAML Formatting

✅ Correct YAML

services:
  radarr:
    container_name: radarr
    restart: unless-stopped

❌ Incorrect YAML (Tabs used instead of spaces)

services:
	radarr:  # ❌ Tabs used (invalid)
		container_name: radarr
		restart: unless-stopped

❌ Incorrect YAML (Inconsistent indentation)

services:
  radarr:
    container_name: radarr
       restart: unless-stopped  # ❌ Indentation is off (invalid)

Breaking Down a Docker Compose File

Here’s a real-world example of a docker-compose.yml file that sets up Radarr, Sonarr, Prowlarr, and SABnzbd essential tools for an automated media server. Following this example, you should be able to easily add other services.

services:
  radarr:
    image: lscr.io/linuxserver/radarr:latest
    container_name: radarr
    env_file: .env
    ports:
      - "${RADARR_PORT}:7878"
    volumes:
      - ${CONFIG_PATH}/radarr:/config
      - ${DOWNLOADS_PATH}:/downloads
      - ${MEDIA_PATH}/Movies:/movies
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    restart: unless-stopped
    depends_on:
      - sabnzbd
      - prowlarr

  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    env_file: .env
    ports:
      - "${SONARR_PORT}:8989"
    volumes:
      - ${CONFIG_PATH}/sonarr:/config
      - ${DOWNLOADS_PATH}:/downloads
      - ${MEDIA_PATH}/TV:/tv
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    restart: unless-stopped
    depends_on:
      - sabnzbd
      - prowlarr

  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    container_name: prowlarr
    env_file: .env
    ports:
      - "${PROWLARR_PORT}:9696"
    volumes:
      - ${CONFIG_PATH}/prowlarr:/config
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    restart: unless-stopped

  sabnzbd:
    image: lscr.io/linuxserver/sabnzbd:latest
    container_name: sabnzbd
    env_file: .env
    ports:
      - "${SABNZBD_PORT}:8080"
    volumes:
      - ${CONFIG_PATH}/sabnzbd:/config
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    restart: unless-stopped

Now let’s break it down.

1. Defining Services

The services: section lists all the containers you want to run. Each service is essentially a separate Docker container.

radarr and sonarr are the names of each service.
Each service runs a specific Docker image (lscr.io/linuxserver/radarr, etc.).
The container_name specifies a custom name for each running container.

2. Environment Variables

Instead of hardcoding values, we use an .env file to store environment variables. This makes it easy to change settings without modifying the Compose file.

Example .env file:

RADARR_PORT=7878
SONARR_PORT=8989
PROWLARR_PORT=9696
SABNZBD_PORT=8080
CONFIG_PATH=/path/to/config
DOWNLOADS_PATH=/path/to/downloads
MEDIA_PATH=/path/to/media
PUID=1000
PGID=1001
TZ=America/Denver

This way, you can just change the .env file without editing the docker-compose.yml every time.

3. Port Mapping

Each container has ports mapped like this:

ports:
  - "${RADARR_PORT}:7878"

This means port 7878 inside the container (where Radarr runs) is accessible on your local machine at ${RADARR_PORT} (set in the .env file).

4. Volume Mounts

Volumes persist data between container restarts. Without them, you’d lose your settings when restarting.

volumes:
  - ${CONFIG_PATH}/radarr:/config
  - ${DOWNLOADS_PATH}:/downloads
  - ${MEDIA_PATH}/Movies:/movies

5. Restart Policy

The restart: unless-stopped line ensures the container will restart automatically unless you manually stop it.

6. Depends On

The depends_on keyword is used to define startup order between containers. It ensures that certain containers start before others, but it does NOT wait until the dependent container is fully ready, only that it has started.

Confused about .env files? See my Master the Basics - Docker’s .env Files post for a detailed breakdown.

Running the Docker Compose File

Once your docker-compose.yml and .env files are ready, all you have to do is:

1. Navigate to the folder containing your Compose file:

cd /docker

2. Start your containers (in the background):

docker compose up -d

-d runs the containers in detached mode, so they keep running in the background.

3. Check running containers:

docker ps

4. Stopping the containers:

docker compose down

This stops and removes all containers but keeps your data intact.

Wrapping It Up

Congratulations. You now know how to use a Docker Compose YAML file to spin up multiple containers with just one command.

This is just the start. Docker Compose can manage networks and even define dependencies between services. But for now, you have a solid foundation.

Give it a try, and soon you’ll wonder how you ever managed Docker without it.

Master the Basics - Docker Env Files

Fri, 28 Feb 2025 07:00:25 -0700

Why You Need a `.env` File

Setting up a media server with Radarr, Sonarr, Prowlarr, and SABnzbd can get complicated fast. If you’ve ever found yourself digging through your docker-compose.yml or manually editing container configurations to change a single setting, you know the pain.

Hardcoding paths, user IDs, and environment variables across multiple containers make updates a nightmare. Want to change your downloads directory? That’s at least four places you’ll need to edit. Move your media to a new drive? Even worse.

That’s where the .env file comes in.

With a .env file, you centralize all your important variables into a single, easy-to-edit file. Instead of making changes across multiple configurations, you update one file, and everything follows suit. This approach keeps your setup clean, modular, and easily portable.

Let’s dive into how to create, use, and secure a .env file to streamline your Arr stack.

Step 1: Creating the `.env` File

The first step is to create the .env file in the same directory as your docker-compose.yml:

In previous posts, the docker compose file lives in your root directory in the folder docker.

cd /docker
nano .env

The .env file is a hidden file. In fact any file that starts with . is hidden from the ls command.

Paste this in to your .env file:

# User and Group ID (Prevents permission issues)
# Main user ID
PUID=1000
# Our media group:
PGID=1001

# Timezone (Ensures correct scheduling and logs)
TZ=America/Denver

# Define Ports (Ports for each container are defined here)
RADARR_PORT=7878
SONARR_PORT=8989
PROWLARR_PORT=9696
SABNZBD_PORT=8080

# Data Directories (Keeps storage paths centralized)
CONFIG_PATH=/docker
DOWNLOADS_PATH=/media/Downloads
MEDIA_PATH=/media

Breaking Down the Variables

PUID & PGID – These define which user the container runs as. If you’ve ever had issues with files being created with the wrong ownership, this fixes it.
TZ (Time Zone) – Ensures logs and scheduled tasks (like downloads and media scans) are in the correct time zone.
PORT – These define the port configuration for each container.
CONFIG_PATH – A dedicated directory for your app settings. Keeping all config files in one place makes backups and migrations easy.
DOWNLOADS_PATH – Centralized directory for your download clients (SABnzbd, etc.).
MEDIA_PATH – This is where your completed movies and TV shows live. Your media player (like Jellyfin or Plex) will read from here. If you are following along, the media folder is located here: /media.

This .env file keeps everything in one place, so you never have to edit multiple files when making a change.

Important Note:

Ensure the CONFIG_PATH folder exists and has the correct permissions set before proceeding:

sudo mkdir /docker
sudo chown -R $USER:media /docker
sudo chmod -R 770 /docker

Step 2: Securing the `.env` File

Since this file stores important configuration values (and possibly API keys if you extend it), we need to lock it down:

chmod 600 /docker/.env

Why This Is Important

chmod 600 ensures only the owner can read and write the file.
Prevents accidental edits or unauthorized access (especially if you store sensitive data later, like API keys).

Step 3: Using the `.env` File in `docker-compose.yml`

Now, let’s modify your docker-compose.yml file to pull values from .env.

services:
  radarr:
    image: lscr.io/linuxserver/radarr
    container_name: radarr
    env_file: .env
    ports:
      - ${RADARR_PORT}:7878
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - ${CONFIG_PATH}/radarr:/config
      - ${DOWNLOADS_PATH}:/downloads
      - ${MEDIA_PATH}/Movies:/movies
    restart: unless-stopped

  sonarr:
    image: lscr.io/linuxserver/sonarr
    container_name: sonarr
    env_file: .env
    ports:
      - ${SONARR_PORT}:8989
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - ${CONFIG_PATH}/sonarr:/config
      - ${DOWNLOADS_PATH}:/downloads
      - ${MEDIA_PATH}/Shows:/tv
    restart: unless-stopped

  prowlarr:
    image: lscr.io/linuxserver/prowlarr
    container_name: prowlarr
    env_file: .env
    ports:
      - ${PROWLARR_PORT}:9696
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - ${CONFIG_PATH}/prowlarr:/config
    restart: unless-stopped

  sabnzbd:
    image: lscr.io/linuxserver/sabnzbd
    container_name: sabnzbd
    env_file: .env
    ports:
      - ${SABNZBD_PORT}:8080
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - ${CONFIG_PATH}/sabnzbd:/config
      - ${DOWNLOADS_PATH}:/downloads
    restart: unless-stopped

How This Works

env_file: .env automatically loads all the variables from .env, making them accessible inside the container.
${CONFIG_PATH}, ${DOWNLOADS_PATH}, and ${MEDIA_PATH} dynamically replace the hardcoded paths with the values from .env.
If you ever need to move your media directories, just update .env, and all containers will follow suit.
${PUID} and ${PGID} are used if you need to change the user or the group running the containers.
${TZ} is used if you would like to change the time zone.

Step 4: Testing and Validating Your Setup

Once everything is set, bring up your stack:

docker compose up -d

To verify that the .env file is being used correctly, check the logs of any container:

docker logs radarr

You should see environment variables applied (like correct directories being loaded).

You can also inspect a container to confirm environment variables:

docker exec -it radarr env | grep CONFIG_PATH

It should return:

CONFIG_PATH=/docker

If everything checks out, you’re good to go!

Step 5: Why This Matters in the Long Run

1. Easy Updates

Need to move your media to a new drive? Just update .env, and every container will follow.
Changing the timezone? One edit in .env instead of hunting through multiple config files.

2. Portability

Moving to a new server? Copy docker-compose.yml and .env, and your entire stack is configured instantly.

3. Clean and Readable Configs

No more massive, unreadable docker-compose.yml files with long, hardcoded paths.

4. Security and Best Practices

Keeps sensitive info (API keys, passwords) out of docker-compose.yml for a cleaner and more secure setup.

Taking It Further: Advanced `.env` Use Cases

Want to level up your .env game? Here are a few extra tricks:

Use `.env` for API Keys (Carefully)

If you’re using a service like NZBHydra or a third-party indexer, add API keys to .env:

NZBHYDRA_API_KEY=yourapikeyhere

Then in docker-compose.yml:

environment:
  - API_KEY=${NZBHYDRA_API_KEY}

💡 Caution: Never commit .env to GitHub or public repositories! Use .gitignore to exclude it.

One file. Easy updates. No headaches.

Wrapping Up

You should now be able to access these containers from your browser like this:

Sonarr: http://your-server-ip:8989
Radarr: http://your-server-ip:7878
Prowlarr: http://your-server-ip:9696
SABnzbd: http://your-server-ip:8080

Reminder: you can find your server IP address using this command:

ip a | grep inet

A .env file is one of the simplest yet most powerful tools in your Docker toolbox. It keeps your Arr stack modular, easy to manage, and future-proof.

Set it up today and never hardcode settings again.

Master the Basics - Understanding Linux Permissions

Fri, 28 Feb 2025 05:52:14 -0700

Ever tried to open a file on Linux and been hit with a “Permission Denied” error? It’s one of those moments that makes you feel like your computer is laughing at you. But don’t worry, you’re not alone, and it’s not as complicated as it seems. Linux permissions might seem cryptic at first, but once you understand the basics, you’ll be using them like a pro.

Let’s break down how Linux permissions work and how you can manage who can read, write, or execute files on your system. By the end of this, you’ll not only understand what “Permission Denied” messages mean but also how to fix them.

What Are Linux Permissions?

In Linux, every file and directory has a set of permissions that determine who can read, write, or execute them. These permissions are essential for security and controlling user access to different parts of the system. They’re divided into three categories:

Owner – The person who created the file.
Group – A set of users who share permissions for the file.
Others – Anyone else who has access to the system.

When you look at a file’s permissions with the ls -l command, you’ll see something like this:

-rwxr-xr--

This might look like gibberish, but it actually breaks down like this:

The first character (-) indicates the type of file (e.g., - for a regular file, d for a directory).
The next three characters (rwx) are the Owner’s permissions.
The next three (r-x) are for the Group.
The final three (r--) are for Others.

Let’s break down what these letters mean:

r – Read permission (view the file’s contents)
w – Write permission (modify the file)
x – Execute permission (run the file as a program)

How to Read Linux Permissions

Let’s look at an example:

-rwxr-xr--

Here’s how you read it:

Owner has rwx which means they can read, write, and execute the file.
Group has r-x, so they can read and execute, but not modify it.
Others have r--, so they can only read the file.

Want to see this in action? Run this command in your terminal:

ls -l /

You’ll see the permissions, owner, group, and other file details. It’s a quick way to check who can do what with your files.

Changing Permissions with `chmod`

To change permissions, you use the chmod (change mode) command. There are two ways to do this: Symbolic and Numeric.

Symbolic Method

The symbolic method uses letters to specify permissions. Here’s the syntax:

chmod [who][operation][permissions] filename

who: u (user/owner), g (group), o (others), a (all)
operation: + (add), - (remove)
permissions: r, w, x

Example:

chmod u+x filename

This gives the owner execute permission.

You can combine multiple changes like this:

chmod u+x,g-w filename

This allows the owner to execute the file while preventing the group from writing to it.

Numeric Method

The numeric method uses three numbers to set permissions, corresponding to Owner, Group, and Others. Each type of permission has a value:

r = 4
w = 2
x = 1

Add the numbers together to get the desired permission:

7 (4+2+1) = Read, Write, Execute
6 (4+2) = Read, Write
5 (4+1) = Read, Execute
4 = Read only

Example:

chmod 755 filename

This breaks down as:

7 (Owner: rwx)
5 (Group: r-x)
5 (Others: r-x)

This setting lets the owner read, write, and execute the file, while the group and others can only read and execute it.

Changing File Ownership with `chown`

In Linux, you can also change who owns a file using the chown command:

chown newowner filename

Or change both owner and group:

chown newowner:newgroup filename

To make changes recursively (like for an entire directory), use the -R option:

chown -R newowner:newgroup directoryname

Practical Examples

Let’s put this into practice. Suppose you have a script called backup.sh, and you want to:

Make it executable for yourself,
Allow your group to read it but not modify or execute it,
Prevent everyone else from accessing it.

Here’s how to do it:

chmod u+x,g=r,o= backup.sh

Alternatively, using the numeric method:

chmod 750 backup.sh

Now, check the result with:

ls -l backup.sh

You should see:

-rwxr-x---

This confirms:

Owner can read, write, and execute.
Group can read but not write or execute.
Others have no access.

Why Understanding Permissions is Crucial

Learning Linux permissions isn’t just about avoiding “Permission Denied” errors. It’s about controlling who can access sensitive files, protecting your system from accidental modifications, and maintaining overall system security.

Linux is powerful because it puts you in control, but with great power comes great responsibility. Misconfigured permissions can lead to security risks or system failures, so it’s worth taking the time to learn how they work.

Why Using 777 Permissions is a Bad Idea

If you’ve spent time searching for fixes to permission issues on Linux, you’ve probably come across the advice to “just use 777 permissions.” At first glance, it sounds like a magic bullet—after all, it gives everyone full access to read, write, and execute the file. Problem solved, right? Well, not exactly.

Setting permissions to 777 is basically the equivalent of leaving your front door wide open with a neon sign that says, “Come on in, take whatever you want!” It grants read, write, and execute access to everyone—Owner, Group, and Others. This means that any user on the system can do anything they want with that file or directory. They can modify or delete it, or even run malicious scripts. That’s a security nightmare waiting to happen.

Imagine you have a web server running a site, and you set one of the directories to 777 because it “fixes” a permission error. Congratulations, you’ve just allowed every user, including anonymous visitors, to upload and execute any file they want. Hackers love this kind of thing because it makes compromising your system laughably easy.

It’s also risky from a stability perspective. If anyone, even by accident, modifies or deletes a critical file, it could cause applications to crash or the entire system to become unstable. You’ll be left scratching your head, wondering what went wrong.

So, what should you do instead? Always follow the principle of least privilege. Grant only the permissions that are absolutely necessary for the file or directory to function. If you’re unsure which permissions to use, take a moment to think about who actually needs access and what they need to do. Need a web server to read files but not modify them? Use 755 instead. Need a directory where a specific group can write files? Try 775.

The bottom line is this: Avoid using 777 unless you’re in a testing environment and understand the risks. In a production system, it’s an invitation for trouble. Secure your files properly, and you’ll save yourself a lot of headaches (and potentially some sleepless nights).

Final Thoughts

Mastering Linux permissions is one of the first steps toward becoming comfortable with the command line. It might feel a bit overwhelming at first, but with practice, it will start to make sense.

The next time you see -rw-r--r--, you’ll know what it means—and how to change it if you need to.

Ready to try it out? Open up your terminal and take control of your files.

Linux Basics for Hackers: Getting Started with Networking, Scripting, and Security in Kali

This is the book I used to learn Linux basics

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

How to Install Sonarr in Docker

Tue, 18 Feb 2025 06:24:50 -0700

If you’re anything like me and love watching a few good TV shows, keeping up with new episodes can be a real headache, especially with the chaotic streaming landscape today. One week, your favorite show is on Netflix, and the next, it’s pulled for an exclusive run on yet another platform. Trying to keep track of what’s available where, remembering release dates, and manually downloading episodes can quickly feel like more work than it’s worth.

That’s where Sonarr comes in. Instead of hopping between streaming platforms or endlessly searching the web for downloads, Sonarr automates the entire process. It keeps track of your favorite TV shows, detects new episodes as soon as they’re available, and downloads them using your preferred method (torrent or Usenet). Once downloaded, it renames, organizes, and moves the files into your media library, ready to watch on Jellyfin, Plex, or Kodi. With Sonarr, your shows come to you—no more hunting them down.

Why Sonarr is a Game-Changer

Here’s why Sonarr is a must-have for any TV show enthusiast:

Automation – Say goodbye to manually searching for torrents or NZB files. Sonarr does it all for you.
Seamless Integration – Works perfectly with popular download clients like qBittorrent, Deluge, SABnzbd, and NZBGet.
Library Organization – Automatically renames and organizes downloaded episodes into neatly structured folders.
Custom Quality Control – Prefer 4K for some shows but okay with 1080p for others? Sonarr lets you set your preferred resolution and will even upgrade files if better versions become available.
Missing Episode Search – If an episode isn’t immediately available, Sonarr keeps searching until it finds a valid source.

Instead of juggling multiple websites and tools, Sonarr turns your TV show collection into a hands-off, fully automated system.

Why Run Sonarr in Docker?

Once you see how powerful Sonarr is, the next step is figuring out the best way to install it. While you could install it directly on your system, running Sonarr in Docker has some serious advantages:

Isolation – Keeps Sonarr and its dependencies separate from your main system, reducing conflicts.
Easy Updates – Updating Sonarr is as simple as pulling the latest Docker image.
Portability – Easily move your setup to a new machine without the hassle of reconfiguring everything.
Simplified Dependency Management – No more worrying about conflicting libraries or compatibility issues.

Running Sonarr in Docker keeps things clean, organized, and easy to manage, update, and troubleshoot. If you’re ready to take control of your TV show collection, setting up Sonarr in Docker is the way to go.

Step 1: Install Docker

To get started, you’ll need Docker. Check out this guide for step-by-step instructions: Master the Basics - How to Install Docker

Step 2: Create the Sonarr Docker Compose File

Let’s set up a docker-compose.yml file to define the Sonarr container.

Navigate to Your Desired Folder

Choose where you want to store Sonarr’s configuration files (I use a root folder named docker):

sudo mkdir -p /docker && cd /docker

Create the `docker-compose.yml` File

Use your favorite text editor:

nano /docker/docker-compose.yml

Then, paste the following content:

services:

  #################################
  ##  SONARR                     ##
  #################################
  sonarr:
    # Official LinuxServer.io Sonarr image
    image: lscr.io/linuxserver/sonarr:latest
    # Sets a custom name for the container
    container_name: sonarr
    # Name and location of the .env file
    env_file: .env
    # Ensures the container restarts if it crashes
    restart: unless-stopped
    ports:
      - ${SONARR_PORT}:8989
    volumes:
      # Stores Sonarr's configuration data 
      - ${CONFIG_PATH}/sonarr:/config
      # Directory where downloaded TV shows are stored  
      - ${MEDIA_PATH}/Shows:/tv
      # Directory where incomplete downloads are stored  
      - ${DOWNLOADS_PATH}:/downloads
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=0007
      - TZ=${TZ}
    networks:
      # Connects the container to the custom media network  
      - media_network

#################################
##  NETWORK                    ##
#################################
# Creates an isolated Docker network for media containers
networks:
  media_network:
    driver: bridge

Step 3: Customize the .env File

Open the .env File

nano /docker/.env

The content of the .env file should look like this:

# User and Group ID (Prevents permission issues)
# Main user ID
PUID=1000
# Our media group:
PGID=1001

# Timezone (Ensures correct scheduling and logs)
TZ=America/Denver

# Define Ports (Ports for each container are defined here)
# Maps Sonarr’s web UI to port 8989 on the host
SONARR_PORT=8989

# Data Directories (Keeps storage paths centralized)
CONFIG_PATH=/docker
DOWNLOADS_PATH=/media/downloads
MEDIA_PATH=/media

Update the Radarr file paths as needed. Here’s what to change:

CONFIG_PATH=/docker → Root folder where Docker stores persistent files.
MEDIA_PATH=/media → Root folder for your media files
DOWNLOADS_PATH=/media/downloads → Root folder where your download client stores temp/incomplete files

Make sure the download client container shares access to the /downloads path.

Also update the timezone (TZ) to match yours.
Refer to: This list of valid timezones.

💡 Pro Tip: Make sure your download client (like qBittorrent or SABnzbd) also has access to the /downloads folder for smooth integration.

Step 4: Start Sonarr

With everything set up, start the container:

docker compose up -d

The -d flag runs the container in the background (detached mode).
Sonarr should now be running.

Verify Sonarr is running:

docker ps

You should see sonarr in the list of running containers.

CONTAINER ID   IMAGE                               COMMAND   CREATED          STATUS          PORTS                                       NAMES
e49175ef37c5   lscr.io/linuxserver/sonarr:latest   "/init"   23 seconds ago   Up 22 seconds   0.0.0.0:8989->8989/tcp, :::8989->8989/tcp   sonarr

Step 5: Ensure Permissions Are Set Correctly

Folder permissions are one of the most common issues people run into when setting up the Arr suite in Docker. To avoid headaches, make sure your docker and media folders have the correct permissions set. Here’s what you need to do:

sudo chown -R `yourusername`:media /docker/ && sudo chmod -R 770 /docker/
sudo chown -R `yourusername`:media /media/ && sudo chmod -R 770 /media/

For more information on Linux permissions see this post: Master the Basics - Linux Permissions

Step 6: Access and Configure Sonarr

Open a web browser and visit:

http://your-server-ip:8989

From here, you can configure Sonarr to connect with your download client and set up your TV show library. For detailed guidance, check out the official Sonarr Wiki.

Step 7: Keeping Sonarr Updated

One of Docker’s biggest advantages is easy updates:

docker compose pull  # Fetches the latest image
docker compose down  # Stops and removes the running container
docker compose up -d  # Starts a fresh container with the new image

This keeps you up to date with the latest features and security patches.

Conclusion

Sonarr is an essential tool for automating TV show downloads. It monitors, downloads, and organizes episodes effortlessly, turning your media library into a fully automated system.

By running Sonarr in Docker, you get all these benefits without cluttering your system. It’s straightforward to install, update, and manage—freeing up more time to enjoy your favorite shows instead of dealing with download hassles.

With Sonarr up and running, consider pairing it with other Arr suite members like Radarr for movies and Lidarr for music. You’ll be well on your way to the ultimate automated media setup.

Master The Basics - Linux File Folders - What They Do and Why They Matter

Sun, 16 Feb 2025 07:15:05 -0700

If you are new to Linux, the file system structure can initially seem confusing. Unlike Windows, which organizes files using separate drives (C:, D:, etc.), Linux uses a single hierarchical tree with everything stemming from the root (/) directory.

Each folder inside / has a specific role, and understanding these roles can make troubleshooting, system management, and daily tasks easier. In this post, I will explain the 10ish important directories in Linux, explaining their purpose and contents in detail.

1. `/` - The Root Directory

What it does:

The root directory (/) is the top-level directory in the Linux file system. Everything in Linux is stored inside this directory, whether they are files, folders, or mounted devices.
It contains all other directories, forming the base of the Linux file hierarchy.

Why it matters:

Unlike Windows, where programs and files can be scattered across multiple drives, Linux organizes everything under /.
When you install Linux, this structure is created automatically.
If you delete or corrupt files inside /, your system may become unusable.

2. `/home` - User Home Directories

What it does:

The /home directory contains personal directories for each user on the system.
For example, if your username is john, your personal files are stored in /home/john/.

What’s inside:

Personal files: Documents, downloads, pictures, music, videos, etc.
Configuration files: Hidden “dotfiles” (like .bashrc or .profile) that store user-specific settings.
User-specific applications: Some apps store user data in directories like ~/.config/ or ~/.local/share/.

Why it matters:

Unlike Windows, where user data is stored in C:\Users\, Linux keeps everything neatly inside /home.
If you reinstall Linux, you can keep your /home directory separate so you do not lose personal data.
This is why it is recommend that your home directory is created on its own partition.

3. `/root` - The Root user Home Directory

What it does:

/root is the home directory for the root user (the superuser or administrator).
It is separate from regular user directories (/home/username/).

What’s inside:

Root user-specific files and settings.
This folder contains system administration scripts or commands only accessible by the root user.

Why it matters:

Regular users are restricted from the folder /root, preventing them from making critical system changes.
If you log in as root (not recommended for daily use), this is where your personal files would be.

4. `/etc` - System Configuration Files

What it does:

This directory stores system-wide configuration files that control how Linux behaves.
Most applications and services have their settings stored here.

What’s inside:

Network settings: /etc/network/interfaces (network configuration), /etc/hosts (local hostnames).
User authentication files: /etc/passwd (user accounts), /etc/shadow (encrypted passwords).
Service configurations: Web servers, SSH settings, firewall rules, etc.

Why it matters:

If you want to change system settings, these files are found in the /etc folder, where you will edit them.
Modifying some of these files can break your system, so always make backups before editing.

5. `/bin` and `/sbin` - Essential System Programs

What they do:

/bin/ (binaries) and /sbin/ (system binaries) store essential programs that let you interact with Linux.

What’s inside /bin/:

Basic commands available to all users, like:
- ls (list files)
- cp (copy files)
- rm (remove files)
- cat (view file contents)

What’s inside /sbin/:

System administrator commands, like:
- shutdown (turn off the system)
- fdisk (manage disk partitions)
- iptables (configure firewalls)

Why they matter:

These directories contain fundamental Linux tools required to run the system.
Without /bin/, you could not execute basic commands like the ones listed above.

6. `/var` - Variable Data (Logs, Caches, Databases)

What it does:

Stores files that change frequently, such as logs, cache files, and mail queues.

What’s inside:

Logs: /var/log/ contains system logs (syslog, auth.log, etc.).
Web server files: /var/www/ stores website files if you run a web server.
Print and mail files: /var/spool/ contains print queues and email processing data.

Why it matters:

If your server is suffering from unexplained issues, checking logs in /var/log/ can help pinpoint the problem(s).
If /var/ fills up, it can cause services to fail (e.g., an overfull log partition might crash a web server).

7. `/usr` - User-installed Programs and Libraries

What it does:

Contains applications and libraries that users install manually or via package managers.

What’s inside:

/usr/bin/: Most common Linux programs (e.g., nano, git, firefox).
/usr/local/: Custom software installed by the user (not managed by the OS).

Why it matters:

If you install software manually, you will often find it in /usr/local/bin/.
Unlike /bin/ (which holds system-critical commands), /usr/bin/ is for user applications.

8. `/tmp` - Temporary Files

What it does:

Stores temporary files that are automatically deleted when the system reboots.

What’s inside:

Temporary user files.
Session data for running applications.

Why it matters:

Useful for storing temporary downloads or test files.
Do not store important files here—they will be erased on reboot!

9. `/mnt` and `/media` - Mount Points for External Drives

What they do:

These directories are used for mounting internal or external drives (USBs, CDs, network drives).

What’s inside:

/mnt/: A generic folder where you can manually mount devices.
/media/: Used by the system to auto-mount removable storage (e.g., /media/usbdrive).

Why they matter:

If you plug in a USB drive and it does not appear in /media/, you might need to mount it manually.

Example:

sudo mount /dev/sdc1 /mnt/usb

10. `/dev`, `/proc`, and `/sys` - System and Hardware Information

`/dev/` - Device Files

Contains files representing hardware devices, like:
- /dev/sda (primary hard drive)
- /dev/usb0 (USB devices)

`/proc/` - Process Information

Contains real-time system info, such as:
- /proc/cpuinfo (CPU details)
- /proc/meminfo (memory usage)

`/sys/` - Kernel and Hardware Settings

Provides a way for the system to interact with hardware components.

Why they matter:

Need to check system info? (cat /proc/cpuinfo), These directories are invaluable.
/dev/ is crucial for mounting drives and accessing hardware.

Wrapping Up

The Linux file system might seem complex, but once you understand the role of each folder, it becomes much easier to navigate and manage. The more you explore, the more comfortable you will become.

If you are new to Linux, try using the ls command to look inside each folder. For example:

ls /
ls /etc
ls /usr/bin

This hands-on approach will help reinforce what you have learned. Happy exploring.

Master the Basics - How to Install Docker in Linux

Thu, 13 Feb 2025 07:02:47 -0700

What Is Docker and Why Should You Use It?

Docker is a containerization platform that lets you run applications in isolated environments called containers. These containers package an application with all its dependencies, making them lightweight, portable, and easy to manage.

Why Use Docker?

Simplifies Application Deployment
Instead of installing software directly on your server (which can lead to dependency conflicts), Docker packages everything into self-contained units that run the same way on any system.

Saves System Resources
Unlike virtual machines (VMs), Docker containers share the host OS kernel, making them far more efficient with memory and CPU usage. You can run dozens of containers on one machine without the overhead of multiple full operating systems.

Easy Software Management
Need to install Jellyfin, Sonarr, Radarr, or Home Assistant? With Docker, it’s as easy as running a command to pull the application and all its dependencies—no manual configuration required.

Keeps Applications Isolated
Docker isolates applications from each other. If one container crashes or gets compromised, it won’t affect the rest of your system.

Effortless Updates and Rollbacks
Updating an app is as simple as pulling the latest container image. And if something goes wrong? Just roll back to the previous version with ease.

Now that you know why Docker is such a powerful tool for your home server, let’s install it correctly, with security in mind.

Intel NUC 12 Pro (NUC12WSHi5) Compact mini PC for lightweight servers, GPU Passthrough, Docker stacks, and VMs.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

1. Update Your System and Install Dependencies

Before installing Docker, your system needs to be updated. Additionally, the necessary dependencies also need to be installed. These steps ensure a clean, stable installation. Run the following commands:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg

These commands:

Update your package list (apt update)
Upgrade installed packages (apt upgrade -y)
Install the essential dependencies (if curl and gnupg are not already installed)

2. Add Docker’s Official GPG Key and Repository

Ubuntu includes Docker in its default repositories, but you should not use it. Why?

Outdated versions: Ubuntu’s repository often lags behind Docker’s latest stable releases, meaning you could be missing important features and security fixes.
Slower updates: Critical bug fixes and security patches may take longer to arrive in Ubuntu’s repositories. Where Docker’s official repository adds these patches immediately.
Missing features: The Ubuntu version may lack support for new Docker functionalities.

To install the latest version, add Docker’s official repository run the following commands:

TL;DR - I Just Want to Cut & Paste Commands:

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo tee /etc/apt/keyrings/docker.asc > /dev/null

sudo chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

The Long and Detailed Explanation of the Commands:

sudo install -m 0755 -d /etc/apt/keyrings

Breaking It Down:

sudo → Runs the command with superuser (root) privileges.
install → A command that can copy files, set permissions, and create directories.
-m 0755 → Sets the permissions of the directory to 0755 (read & execute for everyone, write for the owner).
-d → Tells install to create a directory (if it doesn’t exist).
/etc/apt/keyrings → The path where the directory is created. This is where trusted GPG keys for package signing are stored.

🔒 Security Purpose:

Ensures only the owner (root) can modify the keyring directory.
Prevents unauthorized users from tampering with trusted GPG keys used to verify software packages.
Ubuntu 24.04 and later recommend storing GPG keys in /etc/apt/keyrings/ instead of the older /etc/apt/trusted.gpg for better security.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo tee /etc/apt/keyrings/docker.asc > /dev/null

Breaking The Three Parts of This Command Down:

1 `curl -fsSL https://download.docker.com/linux/ubuntu/gpg`

curl → A tool to download files from the internet.
-f → Fails silently if the URL is incorrect (avoids downloading error messages).
-s → Runs in silent mode (hides progress output).
-S → Shows errors (only if they occur, making troubleshooting easier).
-L → Follows redirects (in case the URL redirects to another location).
https://download.docker.com/linux/ubuntu/gpg → The URL to Docker’s official GPG key.

What this does:
Downloads Docker’s GPG key, which is used to verify the authenticity of Docker packages.

2️ `| sudo tee /etc/apt/keyrings/docker.asc`

| → Pipes (redirects) the output of curl to the tee command.
sudo → Runs the command as root (needed to write to system directories).
tee /etc/apt/keyrings/docker.asc →
- tee writes the Docker GPG key into /etc/apt/keyrings/docker.asc.
- This file will later be used to verify that Docker packages are signed and authentic before installing them.

3 `> /dev/null`

> redirects output somewhere else.
/dev/null is a special “trash” file in Linux that discards anything written to it.

sudo chmod a+r /etc/apt/keyrings/docker.asc

Breaking It Down:

sudo → Runs the command with superuser (root) privileges.
chmod → Changes file permissions.
a → Stands for “all users” (owner, group, and others).
+r → Adds read permission (so the file can be read by everyone).
/etc/apt/keyrings/docker.asc This is the GPG key file used to verify Docker packages when installing/updating via apt.

What this does:

1️ Allows the System to Use the Key

When apt installs or updates Docker, it checks package signatures using this GPG key.
Without read access, apt might fail to verify Docker’s authenticity, causing errors.

2 Prevents Unauthorized Modifications

The file remains protected (only root can modify it), but now all users can read it.
This ensures that system processes and normal users can verify packages but not modify the key.

3️ Follows Ubuntu’s New Security Guidelines

Older versions stored GPG keys in /etc/apt/trusted.gpg, which gave all keys full system-wide trust (less secure).
Newer Ubuntu releases use /etc/apt/keyrings/, where each key is isolated and explicitly trusted only for its repository.

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Breaking The Three Parts of This Command Down:

1️ `echo "deb [...] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"`

echo → Outputs the text inside quotes.
"deb [...] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" →
This is a software repository entry in Debian/Ubuntu format.

What’s inside the `deb [...]` line?

deb → Tells apt this is a binary package repository (not source code).
[arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc]
- arch=$(dpkg --print-architecture) → Detects your system architecture (amd64, arm64, etc.), ensuring you install the correct version.
- signed-by=/etc/apt/keyrings/docker.asc → Uses Docker’s GPG key (previously downloaded) to verify package authenticity.
https://download.docker.com/linux/ubuntu → The URL of Docker’s official repository.
$(lsb_release -cs) → Dynamically inserts your Ubuntu codename (e.g., noble for 24.04), ensuring compatibility.
stable → Installs the stable version of Docker (instead of edge/testing builds).

2️ `| sudo tee /etc/apt/sources.list.d/docker.list`

| → Pipes (echo output) to tee, which writes it to a file.
sudo → Runs with root privileges (since /etc/apt/sources.list.d/ requires admin access).
tee /etc/apt/sources.list.d/docker.list → Saves the repository entry into /etc/apt/sources.list.d/docker.list.

3️ `> /dev/null`

Discards the output from tee, keeping the terminal clean.

Update your apt repositories:

sudo apt update

3. Install Docker

To install Docker (The following command will also install the needed dependencies):

sudo apt install -y docker-ce

To ensure Docker starts when the system boots:

sudo systemctl enable --now docker

Once installed and enabled, verify that Docker is running:

sudo docker ps

If docker is running you should see the following after running docker ps

CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

With nothing showing under these headers.

🔒 Security Step: Prevent Unauthorized Docker Access

By default, Docker runs as root, which is a security risk. A safer approach is to create a dedicated user group:

sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker

After running these commands, you can run Docker without sudo:

docker run hello-world

4. Configure Docker for Better Security

A default Docker installation exposes certain risks. Let’s harden it.

Enable AppArmor

Ubuntu ships with AppArmor, a security module that restricts what Docker containers can access.

Check if it’s enabled:

sudo aa-status

If not, enable it with:

sudo systemctl enable --now apparmor

Disable Containers from Getting Root Privileges

By default, containers can run with elevated privileges. Restrict this with user namespaces:

TL;DR Cut & Paste These Commands:

sudo mkdir -p /etc/systemd/system/docker.service.d

echo -e "[Service]\nExecStart=\nExecStart=/usr/bin/dockerd --userns-remap=default" | sudo tee /etc/systemd/system/docker.service.d/override.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

Breakdown of These Commands:

Create a Configuration Directory for Docker

sudo mkdir -p /etc/systemd/system/docker.service.d

sudo → Runs the command as root (required for modifying system settings).
mkdir -p → Creates a directory if it doesn’t already exist (-p ensures no error if the directory exists).
/etc/systemd/system/docker.service.d → This is where custom systemd overrides for Docker are stored.

Why?
This ensures we have a place to store a custom configuration for the Docker service without modifying the main Docker service file.

Create an Override File to Enable User Namespace Remapping

echo -e "[Service]\nExecStart=\nExecStart=/usr/bin/dockerd --userns-remap=default" | sudo tee /etc/systemd/system/docker.service.d/override.conf

echo -e "[Service]\nExecStart=\nExecStart=/usr/bin/dockerd --userns-remap=default" →
- Creates a custom systemd service override for Docker.
- ExecStart= (empty) clears the previous ExecStart setting from the default Docker service.
- ExecStart=/usr/bin/dockerd --userns-remap=default replaces it with a new one that enables user namespace remapping.
| sudo tee /etc/systemd/system/docker.service.d/override.conf →
- Pipes the output (|) to tee, which writes it into the override file at /etc/systemd/system/docker.service.d/override.conf.
- sudo ensures root access for writing the file.

Why?

User namespace remapping (--userns-remap=default) makes Docker containers run as an unprivileged user instead of root.
This mitigates risks if a container is compromised—it won’t have full root access on the host.

Reload systemd to Apply the Changes

sudo systemctl daemon-reload

sudo → Runs as root.
systemctl daemon-reload → Reloads systemd so it recognizes the new Docker service override.

Why?
Without this, systemd won’t detect the new override.conf file.

Restart Docker to Apply the New Configuration

sudo systemctl restart docker

sudo → Runs as root.
systemctl restart docker → Restarts Docker so it runs with the new --userns-remap=default setting.

Why?

This applies the security changes without rebooting the system.
From now on, Docker containers will run as an unprivileged user instead of root.

Wrapping Up

Docker is a powerful tool for running apps on your Ubuntu 24.04 server, but an insecure setup can put your system at risk. By following this guide, you now have Docker installed correctly—with some security mitigations in place.

Want to take security even further? Consider ufw and/or fail2ban for added protection.

This sets us up for deploying Sonarr and Radarr services in the next posts.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Master the Basics - How to Install and Use SnapRAID for a Resilient Home Media Server

Sat, 08 Feb 2025 07:26:32 -0700

Why You Need SnapRAID with MergerFS

Picture this: You’ve spent years building the perfect media collection—movies, TV shows, music, and personal backups—all neatly stored across multiple hard drives. Then one day, you hear that dreaded clicking sound from one of your server’s drives. Panic sets in. Did you just lose everything on that drive? Not if you planned ahead.

This is where MergerFS and SnapRAID come to the rescue. MergerFS lets you combine multiple drives into a single, easy-to-manage storage pool, while SnapRAID adds redundancy to protect against drive failures. See my Master the Basics - MergerFS post. Together, they provide a cost-effective way to safeguard your data without the complexity of traditional RAID setups.

SnapRAID is a parity-based backup system that protects against drive failures. Unlike traditional RAID, it doesn’t constantly write to all drives, making it ideal for media servers with mostly static data.

In this post, I’ll walk you through how to install and use SnapRAID with MergerFS to build a robust and flexible home media server.

What is SnapRAID Parity?

SnapRAID parity is the backbone of SnapRAID’s data protection. It works by creating a special file containing mathematical information (parity data) about the files on your data disks. This parity data allows SnapRAID to reconstruct lost files if a drive fails.

Think of parity as an insurance policy for your media collection. If one of your drives crashes, the parity file acts like a backup blueprint, enabling SnapRAID to rebuild the missing data using the remaining disks.

How SnapRAID Parity Works

Parity Calculation:
- SnapRAID scans all data disks and calculates parity information based on their contents.
- This parity data is stored on a dedicated parity disk(s), separate from the data drives.
Parity Updates:
- Unlike traditional RAID, SnapRAID does not automatically update parity when you add, remove, or modify files.
- You need to run snapraid sync to refresh the parity data. I’ll show you how to automate this with a cron job later.
Drive Recovery:
- If a data disk fails, SnapRAID uses the remaining data drives + parity disk to reconstruct the lost files.
- The more parity disks you have, the more failures you can recover from.

Why Is SnapRAID Parity Important?

Protects Against Drive Failures

The main reason to use SnapRAID is data redundancy. Without parity, a drive failure means losing everything on that disk. SnapRAID parity lets you recover the lost files, preventing catastrophic data loss.

Saves Space Compared to Full Backups

Unlike traditional backups, SnapRAID parity only stores difference-based data, taking up much less space than making full copies of your drives. One parity drive can protect multiple data drives, making it a space-efficient solution.

Scales with Your Storage Needs

SnapRAID allows you to mix and match different-sized disks—no need for matching drives like in traditional RAID. You can start with one parity drive and add more as your storage needs grow.

Allows Multiple Parity Drives for Extra Protection

One parity drive protects against one failed disk. For more security, you can add additional parity drives:

1 parity drive → Recovers from 1 failed disk
2 parity drives → Recovers from 2 failed disks
3 parity drives → Recovers from 3 failed disks

SnapRAID’s flexible and scalable parity system makes it a powerful choice for home media servers, keeping your data safe without wasting space.

To add more parity drives, update your /etc/snapraid.conf file like this:

parity /mnt/disk4/snapraid.parity
parity /mnt/disk5/snapraid.parity2

SnapRAID parity is crucial for protecting your home media server from hard drive failures. By setting up at least one parity drive, you ensure that your Movie, TV Shows, and Music collections are safe from unexpected data loss.

What Is SnapRAID Content?

The SnapRAID content file (snapraid.content) is a critical part of the SnapRAID system. It stores metadata about all your files, including checksums, timestamps, and information necessary for data recovery. Unlike the parity file, which is used to reconstruct lost data, the content file tells SnapRAID what your data looked like at the last sync.

Every time you run snapraid sync, the content file is updated with new metadata. This allows SnapRAID to detect changes, check for corruption, and restore lost files when needed.

Why Is It Important to Have `snapraid.content` on Multiple Drives?

Prevents Complete Data Loss in Case of a Crash

The SnapRAID content file (snapraid.content) is a critical part of the SnapRAID system. It stores metadata about all your files, including checksums, timestamps, and information necessary for data recovery. Unlike the parity file, which is used to rebuild lost files, the content file tells SnapRAID what your data looked like at the last sync.

Ensures SnapRAID Can Rebuild Your Files

If you were to only store snapraid.content on disk1, and disk1 fails. When you try to run SnapRAID recovery, it will fail because it no longer has a record of your data layout. However, if you also had a copy of snapraid.content on disk2, SnapRAID could still function and restore the missing data.

SnapRAID is designed for data resilience, and having multiple copies of the content file aligns with that philosophy. If a drive fails and you only have one copy, you risk losing access to your recovery information. Multiple content files make SnapRAID more fault-tolerant.

How to Store `snapraid.content` on Multiple Drives

In your /etc/snapraid.conf file, define multiple content locations:

content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content
content /mnt/disk3/snapraid.content

Each entry creates a duplicate of the content file on a different disk. SnapRAID will update all content files during a sync, keeping them identical.

By distributing the content file across two or more drives, you protect your media collection from unexpected failures. This small step ensures that if disaster strikes, you’ll always have a path to recovery.

NOTE: You may use the same drives for content and data.

What Is SnapRAID Data?

In SnapRAID, data refers to the actual files stored on your media server—movies, TV shows, music, backups, and other content. These files are located on data drives, which are physical hard drives or storage locations that SnapRAID protects using parity data.

Unlike traditional RAID, SnapRAID does not mirror or stripe data across disks. Each file exists in only one location, and SnapRAID keeps track of which files are on which drives.

Why Is It Important to Have Data Drives Identified in `snapraid.conf`?

SnapRAID Needs to Know Where Your Files Are

SnapRAID relies on parity calculations to recover lost files. If you don’t tell SnapRAID which drives contain data, it cannot protect them or restore your missing files.

In /etc/snapraid.conf, you must define each data drive explicitly, like this:

data d1 /mnt/disk1
data d2 /mnt/disk2
data d3 /mnt/disk3

Each data entry tells SnapRAID:

Which disks hold your files
Which disks need to be included in parity calculations
Where to look when checking for data integrity

Allows SnapRAID to Detect Changes and Prevent Corruption

SnapRAID doesn’t automatically track file changes, you need to run snapraid sync to update parity.

By listing your data drives in snapraid.conf, SnapRAID knows:

Which files were added, modified, or deleted
When to update parity data
How to detect bit rot (silent file corruption)

Without these entries, SnapRAID has no way of knowing which files exist and cannot protect them.

Ensures Proper Data Recovery After a Drive Failure

If a drive dies, SnapRAID uses the parity data to reconstruct lost files. However, this only works if:

The missing drive was listed in snapraid.conf
A valid parity file exists
the remaining data disks are intact

If you forget to list a data drive in snapraid.conf, SnapRAID won’t protect it. That means if the drive fails, your files are permanently lost because they were never included in the parity calculations.

Enables Flexible Storage Expansion

One of SnapRAID’s strengths is drive flexibility. You can add new data disks of any size at any time. By mounting the new drive and adding it to snapraid.conf:

data d4 /mnt/disk4

After running snapraid sync, the new disk will be included in parity protection.

Unlike traditional RAID, you do not need to rebuild or reformat your entire array. Just add drives as needed.

Defining data drives in snapraid.conf is critical for SnapRAID to function correctly. Without these entries, SnapRAID will not know what to protect, cannot detect changes, and will not be able to restore lost files.

If you care about keeping your media safe, make sure every data drive is listed in snapraid.conf and remember to run snapraid sync regularly.

Installing SnapRAID

If you’re using Debian/Ubuntu, installing MergerFS is simple. SnapRAID is available in the official package repository:

sudo apt update && sudo apt install snapraid -y

To verify that SnapRAID is installed, run:

snapraid status

This command should return:

Self test...
No configuration file found at '/etc/snapraid.conf'

Configuring SnapRAID

Planning Your SnapRAID Setup

Before configuring SnapRAID, you need to plan:

How many data disks? SnapRAID protects your data by storing parity on a separate drive, so you’ll need at least one data disk and one parity disk.
How much parity? One parity disk protects against one drive failure, two parity disks protect against two failures, and so on.
Which drives hold parity and content? The parity disk should have enough free space for the parity data, while your content should be spread across multiple data drives for better redundancy and organization.

Creating the SnapRAID Configuration File

The main configuration file for SnapRAID is /etc/snapraid.conf. Open it in a text editor:

sudo nano /etc/snapraid.conf

A basic configuration for three data disks and one parity disk looks like this:

# Parity file - stored on the largest disk or a dedicated parity drive
parity /mnt/disk3/snapraid.parity  

# Content files - store metadata; should be on multiple drives for redundancy
content /mnt/disk1/snapraid.content  
content /mnt/disk2/snapraid.content  

# Data drives - these contain actual files
data d1 /mnt/disk1  
data d2 /mnt/disk2  
data d3 /mnt/disk3

NOTE: You can see that both disk 1 and disk2 are use for content and data.

Key Points to Consider

Parity Drive: Should be the largest or have enough space for parity data.
Content Files: Should be placed on multiple drives for redundancy.
Data Drives: List each drive that stores actual files.

Additional SnapRAID Options

For better protection and logging, add:

# Define the block size used for parity calculations (default is 256K)
block_size 256  

# Auto-save changes to the content file before syncing
autosave 300  

# Enable scrub (data integrity check) with a limit on recovered errors
scrub_percent 10  
scrub_recover 5

Save and exit the file (CTRL + X, then Y, then Enter).

Running SnapRAID for the First Time

Step 1: Perform an Initial Sync

The first time you run SnapRAID, you need to create the initial parity information. Run:

sudo snapraid sync

This process can take a long time (hours to days), depending on the size of your data. Once completed, SnapRAID will have recorded parity data, allowing you to recover files if a drive fails.

Step 2: Verify Data Integrity

SnapRAID doesn’t automatically detect changes, so you need to check for issues periodically:

sudo snapraid check

This command compares stored parity data with the actual files to detect corruption.

Step 3: Scrubbing for Bit Rot

Over time, files can become corrupted due to bit rot. SnapRAID can scrub files to detect and correct errors. Run:

sudo snapraid scrub -p 10

-p 10 limits scrubbing to 10% of files, reducing disk wear.
Scrubbing should be run periodically to catch issues before they become serious.

Step 4: Recovering a Lost Drive

If a drive fails, don’t panic! SnapRAID can restore its data. First, replace the failed drive with a new one and mount it in the same location. Then run:

sudo snapraid fix

SnapRAID will reconstruct the missing data using the parity drive.

Automating SnapRAID Maintenance

To keep your system safe, schedule SnapRAID syncs and scrubs automatically. Open the crontab:

crontab -e

Add the following lines:

0 3 * * * /usr/bin/snapraid sync
0 4 * * * /usr/bin/snapraid scrub -p 10

Sync runs daily at 3 AM to update parity.
Scrub runs at 4 AM to check for silent corruption.

Save and exit (CTRL + X, then Y, then Enter).

Why MergerFS and SnapRAID Make the Perfect Combo

By combining MergerFS and SnapRAID, you get:

Simple storage management – All your drives show up as one.
Flexible disk usage – Mix and match drives of different sizes without hassle.
Data redundancy – SnapRAID safeguards your data against disk failures.
Low resource usage – No constant disk mirroring like traditional RAID.

This setup is perfect for media servers, where most of the data is read-only. If a drive fails, you can easily restore it without losing everything.

Final Thoughts

Setting up SnapRAID with MergerFS is a game-changer for media storage. It keeps your files organized, accessible, and protected.

Now that you know how to get it up and running, it’s time to safeguard your media collection!

Master the Basics - MergerFS the Best Way to Combine Drives for Your Home Media Server

Sun, 02 Feb 2025 07:23:12 -0700

What if You Could Combine Multiple Drives into One? If you’re like me, you buy hard drives whenever you find the best price per terabyte. Over time, this leads to a mix of different-sized drives, making storage management a nightmare. Your media files end up scattered across multiple disks, and figuring out where everything is stored becomes a hassle. Wouldn’t it be great if all your drives worked together as one seamless storage pool? That’s exactly what MergerFS does.

MergerFS is a game-changer for home media server users who want flexibility and simplicity. It lets you combine multiple drives into a single virtual drive without the complexity of RAID setups or the risk of losing all your data if a drive fails. The best part? It integrates perfectly with tools like Sonarr, Radarr, and Jellyfin.

In this guide, I’ll explain how MergerFS works, walk you through the best configuration options, and show you how to install it on your media server. By the end, you’ll have a streamlined storage pool that maximizes your available space and keeps your files organized.

Examples of how this can happen:

When you find great deals on random drive sizes like this:

Seagate BarraCuda 8TB Internal Hard Drive
Western Digital 14TB Internal Hard Drive
Toshiba N300 12TB Internal Hard Drive

Seagate Barracuda 24TB Internal Hard Drive

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

What is MergerFS and Why Do You Need It?

MergerFS is a union filesystem for Linux that lets you combine multiple storage devices into a single mount point. Instead of managing separate drives, you get to access all your files from one unified location. Unlike traditional RAID setups, MergerFS is:

✅ Flexible – You can add or remove drives anytime without having to rebuild an array.
✅ Safe – If a drive fails, you don’t lose all your data (unlike RAID 0).
✅ Simple – Works with standard filesystems like ext4, XFS, and Btrfs.
✅ Transparent – You don’t need any special tools to access your data if you decide to remove a drive.

How It Works

Think of MergerFS as a smart directory manager. It doesn’t move your files around or create duplicates. Instead, it shows you a virtual filesystem where all your drives appear as one.

For example, if you have:

/mnt/disk1/Movies/
/mnt/disk2/Movies/
/mnt/disk3/Movies/

MergerFS lets you access everything under:
/mnt/storage/Movies/

Now, apps like Jellyfin or Sonarr only need to look in one place, and they don’t care where the actual files reside!

How to Install MergerFS on Your Linux Server

MergerFS is available for most Linux distributions. Here’s how to install it on Debian-based systems (Ubuntu, Proxmox, etc.) and Arch Linux.

Install on Ubuntu/Debian

First, update your package list and install MergerFS:

sudo apt update && sudo apt install mergerfs -y

Verify Installation

Once installed, check the version to confirm it’s working:

mergerfs -V

Best MergerFS Configuration for a Home Media Server

Setting up MergerFS correctly ensures efficient file placement and seamless operation with media apps. Below is my recommended setup that balances performance and flexibility.

Step 1: Mount Your Drives

Before configuring MergerFS, make sure your drives are mounted. You can list available drives using:

lsblk -o NAME,FSTYPE,MOUNTPOINT,SIZE

For example, if your drives are /dev/sdb1 and /dev/sdc1, create mount points:

sudo mkdir -p /mnt/disk1 /mnt/disk2

Then mount them manually (replace ext4 with your actual filesystem type):

sudo mount -t ext4 /dev/sdb1 /mnt/disk1
sudo mount -t ext4 /dev/sdc1 /mnt/disk2

Step 2: Create a MergerFS Pool

Now, create a new directory for your MergerFS mount:

sudo mkdir -p /mnt/storage

Then mount the drives using MergerFS:

sudo mergerfs -o defaults,allow_other,use_ino,cache.files=off,dropcacheonclose=true,minfreespace=50G,category.create=mfs /mnt/disk* /mnt/storage

Understanding the Options

Let’s break down the key options:

allow_other → Allows other users (like Jellyfin, Sonarr) to access the files.
use_ino → Helps avoid issues with file system operations.
cache.files=off → Prevents problems with cached files.
dropcacheonclose=true → Ensures proper file updates.
category.create=mfs → Distributes new files across the drives evenly.
minfreespace=50G → Stop writing to the disk when there is less than 50GB of free space.

Step 3: Make the MergerFS Mount Permanent

Edit your /etc/fstab file to ensure the pool mounts at boot:

sudo nano /etc/fstab

Add this line at the bottom (adjust paths as needed):

/mnt/disk* /media/Storage fuse.mergerfs direct_io,defaults,allow_other,noforget,dropcacheonclose=true,category.create=mfs,minfreespace=50G,fsname=storage 0 0

Save and exit (CTRL+X, then Y and ENTER).

Finally, reload the fstab configuration:

sudo mount -a

Optimizing MergerFS for Media Servers

Now that MergerFS is running, let’s optimize it for media handling.

Best `category.create` Policy

The category.create option determines where new files are placed.

mfs (Most Free Space) → Best for evenly spreading files across drives.
epmfs (Existing Path, Most Free Space) → Ideal if you want files grouped together.
lus (Least Used Space) → Can improve performance by filling up one drive at a time.

For media servers, mfs is usually the best choice because it balances space usage.

Handling Deleted Files

When you delete a file from a MergerFS pool, it only removes it from the original drive. If a file appears to still exist, try refreshing the filesystem cache:

sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

Why MergerFS is Perfect for Home Media Servers

MergerFS is the ideal solution for combining multiple drives into a single storage pool. It’s flexible, easy to set up, and plays perfectly with apps like Jellyfin, Sonarr, and Radarr.

Key Benefits:

✅ Easy Setup – No complicated RAID configurations.
✅ No Data Loss Worries – Each drive is independent, so no risk of losing everything if one fails.
✅ Flexible Expansion – Add or remove drives whenever you need.
✅ Built for Media Servers – Works seamlessly with Jellyfin, Proxmox, and Docker.

If you’re tired of juggling individual disks, MergerFS is the solution. Install it, set it up right, and enjoy a streamlined, organized media library.

Choosing the Right NAS Solution OpenMediaVault vs UNRAID vs TrueNAS Core vs TrueNAS Scale vs DIY

Fri, 31 Jan 2025 07:24:52 -0700

Network Attached Storage (NAS) solutions are essential for home users, media enthusiasts, and businesses looking to store, manage, and protect data. With numerous software NAS options available, choosing the right one depends on various factors such as ease of use, expandability, redundancy, and budget.

This article compares 5 of the most common software NAS solutions: OpenMediaVault, UNRAID, TrueNAS Core, TrueNAS Scale, and building your own custom NAS. I will be outlining the pros and cons of each to help you make an informed decision.

1. OpenMediaVault (OMV)

OpenMediaVault (OMV) is a Debian-based operating system that will transform standard hardware into a powerful and easy-to-manage NAS solution. It provides a web-based interface for managing storage, users, and network services, making it accessible even for those with limited technical expertise. OMV supports various file-sharing protocols, including SMB, NFS, and FTP, allowing seamless integration with multiple devices and operating systems. It also includes built-in monitoring tools, automated backup options, and RAID management, making it a solid choice for home users and small offices looking for reliable network storage.

One of OMV’s greatest strengths is its extensibility. Users can enhance functionality by utilizing plugins, including Docker support for running containerized applications, rsync for automated backups, and various security enhancements. While it offers a straightforward setup, OMV is best suited for users who prefer a stable and controlled environment, as heavy customizations outside of its official updates can sometimes lead to stability issues.

Pros:

Free and Open Source – No licensing fees.
Debian-based – Supports additional Debian packages.
Easy to Use – Web-based GUI for setup and management.
Extensible – Various plugins available to expand functionality.
Supports Various File Systems – Including EXT4, XFS, and Btrfs.
Docker and Virtualization Support – Can run containers for additional services.

Cons:

Limited Enterprise Features – Lacks some high-end features for business environments.
Customization – Can cause stability issues, plugins can conflict with each other.
Community Support – Official support is limited to forums and community contributions.
Not as Polished as Other Solutions – Interface and updates can occasionally cause issues.

Notes:

I used OpenMediaVault (OMV) for several years, but in my experience, it doesn’t handle customizations or updates outside of its official release very well. Once you start making modifications beyond its intended setup, its stability comes into question, making it frustrating to maintain and use.

2. UNRAID

Unraid is a powerful operating system that combines NAS functionality, application hosting, and hardware virtualization into a single, flexible solution. It installs on a USB flash drive and runs in RAM, ensuring minimal system overhead while maintaining persistent configurations. With a modern Linux kernel and broad hardware compatibility, Unraid can operate on nearly any 64-bit x86 system, making it an excellent choice for home and enterprise users.

Managing Unraid is simple through its intuitive web interface, offering easy setup with sensible defaults while allowing advanced customization. Its three core functions—network-attached storage, Docker-based application hosting, and virtual machine management—enable users to store, serve, and run various workloads efficiently. Whether you need a media server, a personal cloud, or a virtualization platform, Unraid provides the tools to maximize your hardware’s potential.

Pros:

Flexible Storage Pooling – Mix and match drives of different sizes.
Data Parity Instead of RAID – Allows easy drive replacement and expansion.
Docker and Virtual Machine Support – Excellent for running applications like Jellyfin, Sonarr, Radarr, or even VMs.
Intuitive Web Interface – User-friendly and feature-rich.
Efficient Use of Storage – Only requires one or two parity disks, maximizing usable storage.

Cons:

Paid License – Costs range from $49 to $109 depending on the number of drives.
Subscription – Need to pay an annual subscription or opt for the $249 Lifetime License
Limited Enterprise Features – Primarily designed for home and media users.
Single-Written Disk at a Time – Slower write speeds compared to RAID arrays. However, This can be overcome by using a cache disk.

Notes:

The cost of UNRAID has always been a major deterrent for me, preventing me from even considering it. When they recently switched to a subscription-based pricing model, it confirmed that UNRAID wasn’t the right fit for me. That said, many users love UNRAID and swear by its ease of use and flexibility.

If you’re looking for a user-friendly NAS solution that seamlessly integrates Docker and virtual machine support, UNRAID is definitely worth exploring. They offer a 30-day free trial, so you can test its features and see if it meets your needs before committing.

3. TrueNAS Core

TrueNAS Core is a powerful, open-source NAS operating system built on FreeBSD and powered by the ZFS file system. Formerly known as FreeNAS, it is designed to provide high reliability, data integrity, and advanced storage management for home and enterprise users. ZFS ensures robust data protection with features like snapshots, checksums, and automatic self-healing, making TrueNAS Core one of the most secure NAS solutions. It supports a wide range of storage protocols, including SMB, NFS, iSCSI, and AFP, allowing seamless file sharing across different platforms.

In addition to its strong storage capabilities, TrueNAS Core includes a web-based management interface that simplifies configuration while offering deep customization options for power users. It also supports plugins and jails, enabling users to run applications like Jellyfin, Sonarr, Radarr, and backup solutions directly on their NAS. While TrueNAS Core requires more hardware resources than some alternatives—especially ECC RAM for optimal ZFS performance—TrueNAS Core remains a top choice for those who prioritize the integrity of their data, enterprise-grade features, and long-term reliability in their NAS setup.

Pros:

ZFS File System – Superior data integrity, snapshots, and compression.
Enterprise-Grade Features – Supports iSCSI, SMB, and NFS.
Web-Based Management – Comprehensive interface for configuration.
Free and Open Source – No licensing costs.
Virtualization Support – Can run Virtual Machines and Jails.

Cons:

Hardware Demanding – Requires ECC RAM and more resources than other NAS solutions.
ZFS Pools - Make adding new drives slowly overtime inefficient.
BSD-Based – Not as user-friendly as Linux-based solutions.
Learning Curve – ZFS and FreeBSD require more technical knowledge.
Not as Flexible with Storage Expansion – Traditional ZFS pools require planning.

Notes:

If I could afford to purchase the majority of my storage upfront and had a system that supported ECC memory, TrueNAS Core or Scale would be an easy choice. However, buying six to eight large hard drives at once is not financially feasible. Even with an unlimited budget, I still don’t think I would choose TrueNAS Core over TrueNAS Scale. The added flexibility, Linux compatibility, and containerization support in Scale make it a more appealing choice for my needs.

4. TrueNAS Scale

TrueNAS Scale is an open-source NAS operating system based on Debian Linux, designed to offer high scalability, containerization, and virtualization capabilities. Unlike its FreeBSD-based counterpart, TrueNAS Core, Scale is built for users who need a more flexible and modern approach to storage management. It retains the powerful ZFS file system, ensuring data integrity, snapshots, and self-healing while adding native support for Kubernetes, Docker, and virtual machines. This makes TrueNAS Scale an excellent choice for users who want a NAS solution that can double as an application server or a lightweight hypervisor.

The web-based management interface provides an intuitive way to configure storage, networking, and applications, making it accessible to beginners and advanced users. With its Linux foundation, TrueNAS Scale supports a range of hardware and software integrations, allowing users to build highly adaptable storage solutions for home labs, media servers, or enterprise deployments. Whether you need a high-availability clustered storage system or a powerful yet easy-to-use NAS with cloud-native capabilities, TrueNAS Scale offers the flexibility to scale with your needs.

Pros:

Linux-Based – Offers better hardware and software compatibility for many users.
ZFS Support – Provides excellent data protection and redundancy.
Enterprise-Ready – Ideal for business use with robust redundancy.
Supports Kubernetes & Docker – Excellent for running containers and microservices.
Scalability – Designed for clustered storage and high availability.

Cons:

Still Developing – Some features are newer compared to TrueNAS Core.
Hardware Demands – Requires ECC RAM and strong CPU/memory resources.
ZFS Pools - Make adding new drives slowly overtime inefficient.
Learning Curve – More challenging for beginners to configure compared to OMV or UNRAID.
Not as Flexible for Storage Expansion – ZFS limitations on adding drives to existing pools.

Notes:

Again, If I could afford to purchase the majority of my storage upfront and had a system that supported ECC memory, TrueNAS Core or Scale would be an easy choice. However, buying six to eight large hard drives at once is not financially feasible. I would pick TrueNAS Scale over Core because of the added flexibility, Linux compatibility, and containerization support make it a more appealing choice for my needs. But, the upfront cost keeps me away.

5. Build Your Own NAS (DIY Solution)

Building your own NAS (DIY NAS) is the ultimate solution for users who want complete control over their hardware, software, and storage configuration. Unlike pre-built NAS operating systems like TrueNAS, Unraid, or OpenMediaVault, a DIY NAS allows you to choose your preferred operating system. Whether it is Ubuntu Server, Debian, Arch Linux, or a custom FreeBSD setup. This flexibility lets you optimize for performance, power efficiency, or specialized use cases such as media streaming, cloud backups, or enterprise-grade storage. With the ability to configure your own RAID arrays, file systems like MergerFS, ZFS, or Btrfs, and network protocols, a DIY NAS offers endless possibilities tailored to your specific needs.

However, building a NAS from scratch comes with added complexity and requires a solid understanding of Linux, networking, and storage management. Unlike turnkey solutions with web-based management interfaces, a DIY NAS often relies on command-line tools and manual configuration. While this approach demands more effort, it provides unparalleled customization, cost savings, and the ability to repurpose existing hardware. Whether you need a simple home file server or a high-performance storage array for virtualization and containers, a DIY NAS empowers you to build a system that fits your exact requirements without the limitations of proprietary software.

Pros:

Completely Customizable – Choose any OS, hardware, and software setup.
No Licensing Fees – Can be built entirely with free open-source software.
Maximum Control – Can implement advanced RAID, MergerFS, ZFS, or Btrfs.
Best for Power Users – Ideal for those comfortable with Linux and storage systems.

Cons:

Steeper Learning Curve – Requires significant technical knowledge.
No Web UI by Default – Unless using software like Webmin, OpenMediaVault, or Cockpit.
More Maintenance – Requires manual updates, security patches, and troubleshooting.
No Official Support – Rely on community forums and personal expertise.

Notes:

You might have guessed that this is the option I chose for my media server NAS. In my setup, I didn’t see the need for redundancy in my media storage since my priority was maximizing capacity rather than mirroring data. Instead, I monitor my disks closely and replace them when I notice bad blocks. If I ever experience a catastrophic drive failure, it’s not a major issue. I can re-rip my missing movies or shows as needed.

For critical data like family photos and important documents, I take a different approach. These files are backed up locally and in the cloud, ensuring they remain safe. This setup allows me to strike a balance between cost efficiency and data protection, prioritizing redundancy only where it truly matters.

Conclusion: Which NAS Solution is Best for You?

For Beginners & Home Users: OpenMediaVault or UNRAID (for easy setup and flexibility).
For Media Enthusiasts & Virtualization: UNRAID (for Docker and VM support).
For Enterprise & Data Integrity: TrueNAS Core (ZFS, redundancy, and enterprise features).
For Advanced Users & Tinkerers: DIY NAS (for maximum control and customization).
For a Balance Between Features & Performance: TrueNAS Scale (best mix of flexibility and enterprise capabilities).

Ready to build the perfect NAS for your needs? Explore the options, assess your priorities, and choose the solution that best fits your storage, virtualization, and application requirements. Whether you prefer a turnkey system or a fully customized setup, there is a solution that can help you store, protect, and manage your data efficiently. Get started today and take control of your storage.

Master the Basics - The 10 Most Important Linux Commands and How to Use Them

Sun, 26 Jan 2025 07:34:05 -0700

If you’ve just installed Linux on your new server to host your locally stored media, you’re probably staring at a command prompt like this:

john@mediaserver:~$

A blinking cursor and no idea where to start—if you’re new to Linux, the terminal can feel like an intimidating black box. With cryptic commands, strange symbols, and endless possibilities, it’s easy to feel overwhelmed. But here’s the good news: mastering Linux isn’t about memorizing hundreds of commands. It’s about learning the essentials that give you the confidence to understand and control your system.

Think of it like learning a new language. You don’t need to know every word in the dictionary to start speaking; you just need the most useful words and phrases. In the same way, a few key Linux commands will unlock the power to navigate, manage, and troubleshoot your system like a pro.

In this post, we’ll break down 10 of the most important Linux commands—what they do, why they matter, and how to use them. By the end, you’ll have a solid foundation to tackle whatever the terminal throws at you. Let’s dive in.

1. `ls` – List Directory Contents

The ls command is one of the first Linux commands every user should learn. It allows you to see the contents of a directory—essentially, it’s the Linux version of peeking inside a folder in a graphical file manager. Whether you’re looking for a specific file, checking for hidden files, or trying to understand the structure of your directories, ls is your go-to tool.

Here’s why it’s important:

Basic Usage:

Typing ls in the terminal will list the files and folders in your current working directory.

Useful Options:

ls -l: Shows detailed information, such as file permissions, ownership, size, and last modification date.
ls -a: Includes hidden files and directories (those starting with a dot, like .config).
ls -h: Outputs file sizes in a human-readable format (e.g., KB, MB, GB).

Practical Examples:

View a directory’s structure:
If you’re organizing your media, you’ll often need to see what’s in a directory. For example, running ls media/Movies shows all the files in your Movies folder.

Identify hidden files:
Hidden files often contain configuration settings. Use ls -a to reveal them when troubleshooting or customizing software.

Check file details:
When permissions or sizes matter (e.g., checking if a script is executable or whether a file is too large), ls -lh provides all the details in one readable output.

Why It Matters:

Knowing what’s in your directories is the first step to managing your Linux system effectively. The ls command helps you understand your environment, locate files, and stay organized.

2. `cd` – Change Directory

The cd command is your key to navigating the Linux file system. It stands for “change directory,” as the name suggests, and it allows you to move between folders in your system. Think of it like double-clicking a folder in a graphical interface but using the power and speed of the command line.

Basic Usage:

cd <directory>: Moves you into the specified directory.

For example, if you want to move to the “Movies” folder in your media directory, you’d type:

cd /media/Movies

Useful Shortcuts:

Home Directory: cd by itself takes you back to your home directory, no matter where you are.

Parent Directory: cd .. moves you one level up in the file hierarchy.

Root Directory: cd / takes you to the root directory (the base of your file system).

Practical Examples:

Move into a specific directory:
To access your media folder from any directory:

cd /media

Navigate multiple levels at once:
To jump directly to a subdirectory without going step by step:

cd /media/Shows

To move up one level in the hierarchy: If you’re in /media/Shows and want to go back to the /media folder:

cd ..

Why It Matters:

Efficient navigation is crucial when working in the Linux terminal. The cd command enables you to quickly reach the directory you need, whether you’re accessing files, running scripts, or modifying system configurations. Knowing how to use both relative and absolute paths ensures you can move around your system seamlessly.

Troubleshooting Tips:

If cd doesn’t work, double-check the directory name. Linux file systems are case-sensitive, so “media” and “Media” are treated as different folders. Use the ls command before cd to ensure the directory exists and to see available options.

3. `pwd` – Print Working Directory

The pwd command is one of the most essential Linux commands. It stands for “print working directory” and does exactly that: it tells you the full path of the directory you are currently in. This command is a constant companion when navigating the Linux file system, especially in environments with complex directory structures. Think of it as a map with a “You are here” arrow.

Basic Usage:

Type pwd in the terminal, and it will output the absolute path of your current working directory.

For example, if you’re in your Movies folder, running pwd might return:

/media/Movies

Practical Use Cases:

Know Where You Are:
When working in nested directories or switching between multiple terminals, it’s easy to lose track of your location. pwd gives you clarity, ensuring you know exactly where you are in the file system.

Script Writing:
When writing scripts, you often need to confirm the current directory to set relative paths for your files. pwd ensures you’re working in the correct location.

Debugging Navigation Issues:
If a file or command isn’t working as expected, pwd can help verify whether you’re in the right directory to execute the task.

Why It’s Important:

While pwd might seem like a small tool, its simplicity is its strength. Knowing your current working directory is fundamental to navigating and managing your Linux system effectively. It’s particularly useful when combined with other commands like ls and cd.

Example Workflow:

Here’s a quick scenario where pwd proves its worth:

You log into a remote server via SSH and are unsure of your starting directory. Run pwd to confirm your location.
After changing directories several times using cd, run pwd again to ensure you’re where you need to be before performing actions like copying or deleting files.

Tips for Using `pwd`:

Combine it with other commands in scripts to dynamically record or confirm the directory path. For example:

echo "You are currently in $(pwd)"

Use it to verify paths when creating symbolic links or setting environment variables.

In Linux, knowing your current location in the file system is half the battle, and pwd is the trusty compass that keeps you oriented. Whether you’re a beginner or an experienced user, this simple command is one you’ll use constantly.

4. `mkdir` – Make Directory

The mkdir command is your go-to tool for creating new directories (folders) in Linux. Whether you’re organizing media files or creating new locations for backups, mkdir is simple, efficient, and essential for maintaining a tidy file system.

Basic Usage:

The simplest form of the command:

mkdir <directory-name>

This creates a directory in your current location.

For example, running:

mkdir media

creates a new folder named ‘media’ in the directory you’re currently in.

Practical Use Cases:

Organizing Media:
When starting a new media storage structure, you can quickly create folders for Movies, Shows, and Music:

mkdir -p /media/{Movies,Shows,Music}

This creates the media folder (if it does not already exist), and the Movies, Shows, and Music subfolders inside it.

Setting Up Temporary Locations:
When testing or running scripts, you might need a dedicated folder for temporary files:

mkdir temp_files

Useful Options:

-p (Parent): Creates parent directories as needed, avoiding errors if parts of the path don’t already exist.

-v (Verbose): Outputs confirmation messages as directories are created, useful for understanding what’s happening in complex operations.

For example:

mkdir -pv /media/{Movies,Shows,Music}

Outputs:

mkdir: created directory 'media'  
mkdir: created directory 'media/Movies'  
mkdir: created directory 'media/Shows'
mkdir: created directory 'media/Music'

Troubleshooting Tips:

If mkdir gives you a “Permission denied” error, it means you don’t have the rights to create a folder in that location. Use sudo mkdir to create directories in restricted areas, like system folders.
Double-check the directory name for typos—Linux file systems are case-sensitive, so “media” and “Media” are not the same.

Why It’s Important:

Creating directories is one of the most fundamental tasks in organizing and managing your Linux environment. Whether setting up a personal media server, deploying software, or scripting automated tasks, mkdir is a tool you will rely on constantly. Its flexibility with options like -p makes it invaluable for creating complex folder structures in seconds.

The mkdir command isn’t just about creating folders—it’s about bringing structure and order to your Linux system. With a bit of creativity and practice, it becomes a cornerstone of efficient file management.

5. `rm` – Remove Files or Directories

The rm command is a powerful tool for deleting files and directories in Linux. It stands for “remove” and is essential for keeping your system clean by getting rid of unwanted files, temporary data, or old backups. However, with great power comes great responsibility—rm can permanently delete data without confirmation, so it’s crucial to use it carefully.

Basic Usage:

To remove a file:

rm <file-name>

For example:

rm old_document.txt

This deletes the old_document.txt file from your current directory.

Deleting Multiple Files:

You can remove several files in one command:

rm file1.txt file2.txt file3.txt

Removing Directories:

By default, rm only removes files. To delete directories, you’ll need to use specific options:

rm -r (Recursive): Removes a directory and all its contents (files and subdirectories).

rm -r folder_name

rm -rf (Recursive + Force): Deletes everything in a directory without asking for confirmation.

rm -rf /path/to/directory

Be very careful with this command—it’s often referred to as the “nuclear option” because it can wipe out data irreversibly.

Practical Use Cases:

Delete Temporary Files:
Clean up temporary or cache files after troubleshooting or testing:

rm -r /tmp/my_temp_files

Delete Media You No Longer Want/Need:
Remove unneeded files to free up disk space:

rm -r /media/Movie/Movie_I_No_Longer_Need

Useful Options:

-i (Interactive): Asks for confirmation before deleting each file, reducing the risk of accidental deletion:

rm -i important_file.txt

-v (Verbose): Shows details of what’s being deleted:

rm -rv /path/to/directory

-f (Force): Ignores warnings and deletes files or directories without asking for confirmation. Use with caution.

Safety Tips for Using `rm`:

Double-Check Paths: Before running rm, confirm the path to avoid unintended deletions. If you are not careful, you can sometimes delete more than you intended.
Avoid sudo Unless Necessary: Running rm as a superuser (sudo) can delete system-critical files. Use it sparingly.
Simulate with ls: Use ls to preview the files you’re about to delete:

ls /path/to/directory

Why It’s Important:

The rm command is a cornerstone of Linux file management. It ensures that your system doesn’t get cluttered with unnecessary files, helping you maintain an organized and efficient environment. However, because deletions are irreversible by default, understanding and respecting its power is crucial.

Example Workflow:

Delete a Single File:

rm Movie_I_Hate.mkv

Remove a Directory with Files:

rm -r ~/Downloads/temp_folder

Clean All .tmp Files in a Directory:

rm *.tmp

6. `cp` – Copy Files and Directories

The cp command in Linux is used to copy files and directories from one location to another. It’s one of the most versatile and commonly used commands, whether you’re creating backups, duplicating files for edits, or moving content between directories. With a range of options to enhance its functionality, cp is a powerful tool for efficient file management.

Basic Usage:

Copy a File:

cp <source-file> <destination>

For example:

cp config.conf backup_config.conf

This copies config.conf to a new file named backup_config.conf in the current directory.

Copying Multiple Files:

To copy multiple files into a directory:

cp file1.txt file2.txt /path/to/destination/

Copying Directories:

By default, cp doesn’t copy directories unless you include the recursive -r option:

Copy an Entire Directory:

cp -r /source/directory /destination/directory

This creates a duplicate of the directory and all its contents, including subdirectories and files.

Practical Use Cases:

Backup Files:
Before editing a critical file, create a backup:

cp config.yaml config_backup.yaml

Move Files to External Drives:
Copy files to another folder :

cp /home/user/downloads/movie.mkv /media/Movies/Movie_Name/

Useful Options:

-i (Interactive): Prompts for confirmation before overwriting existing files:

cp -i file1.txt /destination/

-v (Verbose): Displays details of each file being copied, helpful for tracking large operations:

cp -v file1.txt file2.txt /destination/

-u (Update): Copies files only if the source file is newer or doesn’t exist in the destination:

cp -u file1.txt /destination/

-p (Preserve): Retains the original file’s metadata (timestamps, permissions, etc.):

cp -p file1.txt /destination/

Tips for Using `cp`:

Preview Before Copying: Use the ls command to check your source and destination paths before running cp.

Avoid Overwriting: Use the -i option to prevent accidental overwriting of files. Alternatively, use -n (no-clobber) to skip overwriting entirely.

Why It’s Important:

The cp command is indispensable for anyone managing files in Linux. Its versatility allows you to copy everything from individual files to entire directory structures. Whether backing up critical data, reorganizing your file system, or preparing project templates, cp ensures you can duplicate your work without error.

Mastering the cp command will add a vital tool to your Linux arsenal. One that keeps your files safe, organized, and easy to manage.

7. `mv` – Move or Rename Files and Directories

The mv command in Linux is a dual-purpose powerhouse. It’s used to move files and directories from one location to another, but it also functions as a tool to rename them. This versatility makes mv an essential command for file management, whether reorganizing directories, renaming files, or moving data to another location.

Basic Usage:

Move a File:

mv <source-file> <destination>

For example:

mv movie.mkv /media/Movies/Movie_Name/

This moves the file movie.mkv to the Movie_Name directory.

Rename a File:

mv <old-name> <new-name>

For example:

mv Movie_Name.mkv Movie_Name_2022.mkv

This renames the file Movie_Name.mkv to Movie_Name_2022.mkv in the current directory.

Moving Multiple Files:

To move several files to a new directory:

mv file1.txt file2.txt file3.txt /destination/directory/

Moving Directories:

Move an Entire Directory:

mv /source/directory /destination/

This moves the directory and its contents to the new location.

Useful Options:

-i (Interactive): Prompts for confirmation before overwriting a file in the destination:

mv -i file.txt /destination/

-v (Verbose): Displays the details of the files being moved or renamed:

mv -v file.txt /destination/

-n (No-Clobber): Prevents overwriting existing files in the destination:

mv -n file.txt /destination/

Tips for Using `mv`:

Preview Before Moving: Use ls or find to preview files before moving them to avoid mistakes.

Avoid Overwriting: Use the -i or -n option to prevent accidental overwrites.

Be Careful with sudo: When moving system-critical files, running mv with sudo can have significant consequences if done incorrectly. Double-check your paths.

Why It’s Important:

The mv command is indispensable for organizing your Linux system. Its ability to move and rename files in one step makes it a versatile and efficient tool. Whether you’re tidying up your home directory, reorganizing project files, or preparing data for a backup, mv helps you manage your files quickly and effectively.

By mastering mv, you’ll gain the flexibility to manipulate files and directories seamlessly, making your Linux workflow smoother and more organized.

8. `chmod` – Change File Permissions

The chmod command is an essential tool for managing file and directory permissions in Linux. It allows you to control who can read, write, and execute files, ensuring your system is secure. And that users only have the access they need. By mastering chmod, you safeguard sensitive files and enable proper collaboration across users.

Understanding File Permissions:

Before diving into chmod, it’s important to understand the structure of Linux file permissions, which can be viewed using ls -l:

-rwxr-xr--  1 user group 4096 Jan 23 10:00 script.sh

Here’s what the fields mean:

r (read): Allows viewing the file’s contents.
w (write): Allows modifying the file.
x (execute): Allows running the file as a program or script.

Permissions are grouped into three categories. In the above exaple this is how it breaks down:

Owner (rwx) - Full access to the file
Group (r-x) - Read and Execute for the members of the group
Others (r--) - Everyone else can read the file

Basic Usage:

Change Permissions Using Symbolic Notation:

chmod <permissions> <file>

For example, to give the owner execute permissions for a file:

chmod u+x script.sh

Here’s a breakdown of symbolic permissions:

u (user): The file’s owner.
g (group): Users in the file’s group.
o (others): All other users.
a (all): Applies to u, g, and o.

Modifiers:

+ (add): Adds a permission.
- (remove): Removes a permission.
= (set): Sets a permission exactly.

Example:

Add read and write permissions for the group:

chmod g+rw file.txt

Remove execute permission for others:

chmod o-x script.sh

Change Permissions Using Octal Notation:

Octal values provide a shorthand for setting permissions:

4 (read): r--
2 (write): -w-
1 (execute): --x

Combine these to set multiple permissions (e.g., 7 = rwx, 6 = rw-).

To set permissions directly:

chmod 755 script.sh

This sets:

Owner: Read, write, execute (7 = rwx).
Group: Read, execute (5 = r-x).
Others: Read, execute (5 = r-x).

Practical Use Cases:

Make a Script Executable:
When creating a new script, you need to make it executable:

chmod +x my_script.sh

Secure Sensitive Files:
Restrict access to a private file so only the owner can read or write it:

chmod 600 private_file.txt

Allow Group Collaboration:
Grant a group read and write permissions to a shared file:

chmod g+rw shared_file.txt

Useful Options:

-R (Recursive): Apply permissions to a directory and all its contents:

chmod -R 755 /path/to/directory

--reference: Copy permissions from one file to another:

chmod --reference=source_file target_file

Example Workflow:

Check Current Permissions:
Use ls -l to see the current permissions:

ls -l file.txt

Modify Permissions:
Grant read and write permissions to the owner and group, but deny all permissions to others:

chmod 660 file.txt

Make a Directory and Its Contents Accessible:
Ensure a web project directory is accessible to everyone:

chmod -R 755 /media/Movies

Tips for Using `chmod`:

Test Before Automating: Avoid running chmod commands recursively without testing on a single file or directory.

Avoid Over-Permissive Settings: Always follow the principle of least privilege. Grant only necessary permissions. While setting permissions to 777 might seem convenient, it can create serious security risks by giving everyone full access to your files. Instead, take the time to set appropriate permissions based on your needs. For example, I use 770 permissions. This setup allows the owner and group full access to the files. While completely restricting access to others. With 770, not only is the content protected from unauthorized access, but it’s also hidden from users outside the group, enhancing both security and privacy.

Check Permissions Regularly: Use ls -l to ensure files have the correct permissions.

Why It’s Important:

File and directory permissions are at the heart of Linux security and system management. The chmod command gives you precise control over access, allowing you to protect sensitive files, enable collaboration, and maintain proper functionality for applications and scripts.

By mastering chmod, you’ll be equipped to secure your system, manage user access, and ensure the smooth operation of your Linux environment. It’s not just a command—it’s a key to effective and secure system management.

9. `chown` – Change File Ownership

The chown command in Linux allows you to change the ownership of files and directories. Ownership defines who can access, modify, or manage a file. Every file in Linux has two primary ownership attributes: the user (owner) and the group. By using chown, you can assign files to the appropriate owner and group, which is especially critical for managing multi-user systems and ensuring security.

Basic Usage:

Change the Owner of a File:

chown <new-owner> <file>

For example:

chown kryptikwurm movie.mkv

This sets the owner of movie.mkv to the user kryptikwurm.

Change Both Owner and Group:

chown <new-owner>:<new-group> <file>

Example:

chown kryptikwurm:media movie.mkv

This changes the owner to kryptikwurm and assigns the file to the media group.

Changing Ownership of Directories:

To change the ownership of a directory and all its contents, use the -R (recursive) option:

chown -R kryptikwurm:media /media

This changes the ownership of /media and everything inside it to user kryptikwurm and group media.

Useful Options:

-R (Recursive): Apply ownership changes to directories and all their contents:

chown -R kryptikwurm:media /media

-v (Verbose): Displays information about what chown is changing:

chown -v kryptikwurm:media movie.mkv

Checking File Ownership:

Use ls -l to check ownership details of files and directories:

ls -l file.txt

The output shows the owner and group:

-rw-r--r--  1 user group 4096 Jan 23 12:00 file.txt

Here, user is the owner, and group is the group.

Safety Tips for Using `chown`:

Be Careful with sudo: Always double-check the file or directory path when using sudo with chown, as incorrect paths can cause system-wide permission issues.

Don’t Use Wildcards Recklessly: Avoid commands like chown -R user:group /* as they could affect critical system files.

Preview Changes: Use ls -l to inspect file ownership before making changes.

Why It’s Important:

Proper ownership management is vital for system security and functionality. With chown, you can:

Ensure only authorized users can access or modify files.
Enable collaboration by assigning files to specific groups.
Maintain system integrity by assigning correct ownership to configuration and system files.

By mastering chown, you’ll have the power to manage access and keep your Linux system secure and efficient. It’s an indispensable command for anyone managing multi-user environments or working on shared systems.

10. `df` – Display Disk Space Usage

The df command in Linux is used to display information about the available and used disk space on file systems. Short for “disk free,” df provides a quick overview of your system’s storage capacity, helping you monitor and manage disk usage effectively. It’s an essential tool for system administrators and users who need to ensure there’s enough space for files, logs, and applications.

Basic Usage:

To display disk usage for all mounted file systems, simply type:

df

Example output:

    Filesystem     1K-blocks     Used       Available  Use%   Mounted on
    /dev/sda1       500000000    250000000  250000000   50%   /
    tmpfs           4000000      0          4000000      0%   /dev/shm

Key Fields in the Output:

Filesystem: The name of the disk or storage device (e.g., /dev/sda1).

1K-blocks: Total storage space on the filesystem in 1KB blocks (default).

Used: Disk space currently in use.

Available: Disk space available for use.

Use%: The percentage of disk space in use.

Mounted on: The directory where the filesystem is mounted.

Useful Options:

-h (Human-Readable): Display sizes in a more readable format (e.g., MB, GB):

df -h

Example output:

    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sda1       500G  250G  250G  50% /

-T (Show Filesystem Type): Include the type of filesystem (e.g., ext4, xfs):

    df -T

Example output:

    Filesystem     Type     1K-blocks     Used       Available  Use%  Mounted on
    /dev/sda1      ext4     500000000     250000000  250000000   50%  /

Practical Use Cases:

Monitor Disk Space on Servers:
Regularly check disk space usage to ensure critical services don’t fail due to lack of storage:

df -h

Identify Full or Nearly Full Filesystems:
Use the Use% column to quickly spot filesystems nearing capacity, such as:

    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sda1       500G  490G   10G  98% /

Check Mounted External Devices:
Verify the available space on USB drives, external hard drives, or network shares:

    df -h /media/usb

Tips for Using `df`:

Use -h for Human-Readable Output: The default df output can be hard to interpret; always use -h unless you need raw block sizes.

Monitor Regularly: Run df periodically on servers or systems with limited storage to prevent unexpected failures.

Check Mounted Points: Use df to verify that external devices or network shares are mounted correctly.

Why It’s Important:

The df command provides critical insights into your system’s disk space usage. With it, you can:

Proactively manage storage to avoid full filesystems that could disrupt services.
Diagnose performance issues caused by lack of space.
Monitor external devices and ensure sufficient capacity for backups or large data transfers.

By mastering df, you’ll be equipped to monitor and manage your system’s storage effectively, ensuring optimal performance and stability. It’s a simple yet powerful tool that every Linux user should have in their arsenal.

In Conclusion:

Mastering Linux commands gives you the keys to fully control your system. From using ls to navigate directories to chmod for managing security, these commands empower you to interact with your Linux environment confidently and efficiently. By getting comfortable with these 10 essential commands, you’ll be able to manage files, troubleshoot issues, optimize performance, and keep your system secure—all from the terminal.

Linux can seem intimidating at first, but with practice, these commands will become second nature. They’re more than just tools, they’re your gateway to unlocking the full potential of Linux and taking control of your system like a pro.

Don’t just read about these commands—practice them! Open your terminal, try creating files, managing permissions, and searching for data. The best way to learn is by getting your hands dirty. And if you’re ready to push your skills even further, start experimenting with combining these commands to write scripts or automate tasks.

Mastering Linux starts with the basics. So take that first step today. Your journey to becoming a Linux power user is just beginning.

Turn an Old Computer Into a Media Server Part 4 How to Configure Jellyfin

Mon, 20 Jan 2025 08:05:12 -0700

Introduction

Awesome progress on transforming your old PC into a powerful home media server! You’ve already tackled some big steps—installing Ubuntu Server 24.04 LTS, setting up and configuring storage, getting those SMB shares ready for seamless file transfers, and even installing Jellyfin. Now it’s time to pull it all together by configuring Jellyfin and crafting your personalized streaming experience.

In this post, we’ll go through everything you need to get Jellyfin up and running, from completing the setup wizard and adding your media libraries to customizing settings and testing playback. By the end, your media server will be fully operational, ready to stream movies, TV shows, music, and more to any device on your network.

Ready to bring all your hard work together into a seamless streaming experience? Let’s dive in and configure Jellyfin!

Section 1: Accessing the Jellyfin Web Interface

Step 1: Connect to Jellyfin

Open a web browser on a device connected to your network.

Enter the server’s IP address followed by the port number :8096.

Example: http://192.168.1.100:8096

This will take you to the Jellyfin setup wizard. It should look like this:

If it is not working refer to this post: Troubleshooting - Jellyfin Server Access Issues

Section 2: Running the Jellyfin Setup Wizard

Step 1: Choose Your Language and Region

Select your preferred language.

Step 2: Create an Admin Account

Creating a strong admin username and password for managing your Jellyfin server is essential for ensuring the security and integrity of your media server.

Tips for Creating a Strong Username and Password

Use Unique Credentials: Avoid common usernames like “jellyfin” and passwords like “123456.” Instead, use a unique username, and for the password use a combination of letters, numbers, and special characters.
Make It Long: Passwords should be at least 12 characters long for maximum security.
Avoid Predictable Words: Don’t use easily guessed information like your name, birthday, or server name.
Use a Password Manager: If remembering complex passwords is challenging, a password manager can generate and store them securely for you.

Step 3: Add Media Libraries

Click “Add Media Library."

Select the content type (Movies, TV Shows, Music, etc.).

Click the + next to “Folders” Browse to the folder where the media is stored (e.g., /mnt/media/Movies).

The default setting are good to start with there is no need to change anything on this initial setup.

Repeat for /mnt/media/Shows and /mnt/media/Music.

Step 4: Configure Metadata Options

Metadata enhances your media server experience by automatically adding details like cover art, plot summaries, cast lists, and ratings to your movies, TV shows, and music. This transforms your media library into a visually appealing and easy-to-navigate interface, making it feel like a professional streaming service.

For now, accept the default settings.

Step 5: Remote Access (Optional)

Not recommended but, To enable remote access, you need to configure your router to forward the Jellyfin server’s port (default is 8096) to the server’s internal IP address, allowing external devices to connect. For added security, consider using a VPN or enabling HTTPS with a valid SSL certificate to protect your data during remote access.

Step 6: Finish the Wizard

Click “Finish,” and the server will start scanning media files to populate the libraries.

If everthing went well here your should now see the web interface with your media added.

Section 3: Testing Your Jellyfin Setup

Step 1: Open the Jellyfin Client

To access your media from various devices the Jellyfin app or client needs to be installed on each device or you can access it from a web browser.
Note: Right now this is only accessible while connected to your Local network
Jellyfin apps: Download and install apps for mobile devices, TVs, or streaming sticks.

Step 2: Test Playback

Play a sample movie or TV show to confirm that your Jellyfin server is functioning correctly. You can do this directly from the Jellyfin home screen in your web browser. However, some browsers may encounter CODEC compatibility issues during playback. For the best results, I recommend you test your media within the official Jellyfin client app, which is optimized for a seamless streaming experience.
Client Apps can be downloaded from your app store or here: Jellyfin Client Downloads

Conclusion

Congrats! You’ve got Jellyfin up and running with user accounts, metadata, and media libraries, all set up to deliver a seamless streaming experience. Your media server is ready to stream movies, TV shows, music, and more to any device on your network.

But this is just the start! Jellyfin has a ton of features waiting to be explored—from customizing themes and adding plugins to enabling advanced settings like remote access. Take some time to fine-tune your server and see how you can make your media experience even better.

Now, it’s time to kick back, grab some popcorn, and enjoy the payoff of all your hard work. Your home media server journey is just beginning.

Troubleshooting - Jellyfin Server Access Issues

Mon, 20 Jan 2025 07:44:15 -0700

Setting up a home media server with Jellyfin is exciting, until you hit a snag. One of the most common issues is not being able to access Jellyfin in your browser after entering the server’s IP address followed by :8096. The good news? This is a common issue with straightforward solutions. Let’s walk through the steps to diagnose and resolve the problem.

1. Double-Check the IP Address

The first step is making sure you’re entering the correct IP address for your server. An incorrect IP is a simple mistake but an easy fix.

To find the server’s IP, open a terminal on the server and run:

ip a

Look for the inet address under your active network interface (like eth0 or wlan0). It’ll look something like this: 192.168.1.100.

Double-check that you’re using this address in your browser.

2. Ensure the Jellyfin Service Is Running

If Jellyfin isn’t running, it won’t respond in your browser. Check the service status with:

sudo systemctl status jellyfin

Look for the line that says Active: active (running). If it isn’t running, start it manually:

sudo systemctl start jellyfin

To ensure Jellyfin starts automatically when your server boots, enable the service:

sudo systemctl enable jellyfin

3. Test Connectivity

Next, confirm that your client device can reach the server. Open a terminal or command prompt on the client device and run:

ping <server-ip>

Replace <server-ip> with your server’s address (e.g., 192.168.1.100). If you see replies, the connection between your devices is working.

4. Reboot the Server

Sometimes, a simple reboot can work wonders. Restarting clears temporary networking issues and restarts all services. Run:

sudo reboot

After the server reboots, try accessing Jellyfin again in your browser.

5. Check Browser Compatibility

Jellyfin’s web interface works best with modern browsers like Chrome, Firefox, or Edge. If you’re using an outdated or unsupported browser, try updating it or switching to one that works seamlessly with Jellyfin.

When All Else Fails: Check the Logs

If none of the above steps work, Jellyfin’s logs can be a treasure trove of information about what’s going wrong. To view the logs, run:

sudo journalctl -u jellyfin

Look through the logs for any errors or warnings. These might indicate configuration issues, service failures, or other problems.

By working through these steps one by one, you’ll likely pinpoint and fix the issue preventing you from accessing Jellyfin. A little troubleshooting can go a long way toward getting your home media server up and running.

Turn an Old Computer Into a Media Server Part 3 Installing Jellyfin and Its Dependencies

Sat, 18 Jan 2025 07:00:43 -0700

Recap: Your Journey So Far

In the previous posts, we breathed new life into your old, dusty PC by turning it into a powerful server running Ubuntu Server 24.04 LTS. Along the way, we:

Explored why starting with an old PC is a smart choice, it’s budget-friendly, eco-conscious, and perfect for beginners.
Reviewed the minimum hardware requirements for running Jellyfin, showing that you don’t need cutting-edge technology to build a media server.
Provided step-by-step instructions for installing Ubuntu Server, from creating a bootable USB drive to completing the installation process.
Added and configured storage for your media, including partitioning and formatting new drives for optimal use.
Set up a Samba share, which makes it easy to transfer files to your server from other devices on your network.

With your server prepped and ready, it’s time to bring it to life by installing Jellyfin. In this next phase, we’ll guide you through setting up Jellyfin and its dependencies so you can begin building your very own media library. Let’s get started!

What Is Jellyfin?

Jellyfin is a free, open-source media server that lets you organize, manage, and stream your media collection to any device, anywhere. Think of it as your personal Netflix, but completely under your control. Whether it’s movies, TV shows, music, or photos, Jellyfin allows you to build a centralized media hub that you can access from your phone, smart TV, computer, or even a web browser.

This post will guide you step-by-step through:

Preparing Your Ubuntu Server:
- Ensuring your server is fully updated for stability and security.
- Installing essential tools like curl for downloading and configuring software.
Adding the Jellyfin Repository:
- Adding the official Jellyfin repository to your server so you can download the latest stable version.
- Explaining why repositories are important and how they keep your server software up to date.
Installing Jellyfin:
- Using Ubuntu’s package manager (apt) to install Jellyfin easily.
- Starting and enabling the Jellyfin service so it runs automatically whenever your server starts.
Accessing Jellyfin for the First Time:
- Verifying that Jellyfin is installed and running correctly.
- How to find your server’s IP address and access Jellyfin’s web interface via a browser.

Section 1: Preparing Your Server for Jellyfin

SSH Into Your New Server

Not sure how to use SSH? Refer to this post: Master the Basics - How to SSH Into a Linux Server

Steps to Connect Using SSH

Open PowerShell on Windows:

The command for SSH:

ssh <username>@<server-ip>

Example From Part 1:

ssh kryptikwurm@172.27.0.200

Authenticate:

Enter your server password when prompted. (Don’t worry if you don’t see any characters while typing—that’s normal for security reasons.)

Once logged in, you’ll have full access to your server remotely, ready to start installing Jellyfin!

Install System Updates and Curl

Update the system:

System updates are crucial because they ensure your server has the latest security patches, protecting it from vulnerabilities that could expose your data or compromise your setup. Additionally, updates improve system stability and performance, reducing the likelihood of crashes or compatibility issues with new software like Jellyfin.

Commands to update the server:

sudo apt update && sudo apt upgrade -y

Install essential tools:

Curl is a command-line tool to transfer data from or to a server, making it a popular choice for downloading files or interacting with APIs directly from the terminal. It’s lightweight, versatile, and supports many protocols like HTTP, HTTPS, and FTP, making it essential for tasks like adding repositories or fetching configuration files on Linux systems.

Install Curl (Might already be installed, verify anyway):

sudo apt install curl -y

Section 2: Adding the Jellyfin Repository

Adding the Jellyfin repository to your server ensures you can download the latest stable version of Jellyfin directly from its official source. This not only guarantees you up-to-date features and security fixes but also makes it easier to manage updates through Ubuntu’s package manager (apt).

Command to add the repository (copy and paste each into the command prompt):

The following command securely fetches and stores the GPG key needed to verify Jellyfin packages during installation or updates.

curl -fsSL https://repo.jellyfin.org/ubuntu/jellyfin_team.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/jellyfin.gpg

The following command creates a file in /etc/apt/sources.list.d/ to register the Jellyfin repository with Ubuntu, ensuring your system can download Jellyfin and future updates from the correct source.

echo "deb [signed-by=/usr/share/keyrings/jellyfin.gpg] https://repo.jellyfin.org/ubuntu noble main" | sudo tee /etc/apt/sources.list.d/jellyfin.list

sudo apt update doesn’t install or upgrade any software—it simply updates your system’s knowledge of available packages, ensuring you can install the latest versions. It’s a necessary step before running commands like sudo apt install or sudo apt upgrade.

sudo apt update

If it was successful your should see this line:

https://repo.jellyfin.org/ubuntu noble InRelease

Section 3: Installing Jellyfin

Use the apt package manager to install Jellyfin:

sudo apt install jellyfin -y

Enable the Jellyfin service so it starts at boot:

sudo systemctl enable jellyfin

Start the Jellyfin service without rebooting:

sudo systemctl start jellyfin

Verify it is running:

sudo systemctl status jellyfin

You should see output indicating the service is active and running. Look for a line like this:

Active: active (running) since <date and time>

Section 4: Creating Groups and Permissions

To allow Jellyfin to access your /mnt/media/ folder, we need to create a dedicated group, add the jellyfin user to it, and include your default user as well for convenience.

To create the group:

sudo groupadd media

Add users to the group:

sudo usermod -aG media jellyfin
sudo usermod -aG media $(whoami)

Change the group owner of the media folders:

sudo chown -R :media /mnt/media

Section 5: Accessing Jellyfin for the First Time

With your server running and the IP address in hand, you can now access Jellyfin from a web browser:

Open a Web Browser:

On your main computer, phone, or tablet connected to the same network as the server, open any modern browser like Chrome, Firefox, or Edge.
Enter the Address:

In the address bar, type the following, replacing <server-ip> with your server’s IP address:

http://<server-ip>:8096

Example:

http://172.27.0.200:8096

Verify the Jellyfin Interface Loads:

You should see the Jellyfin setup wizard screen, confirming the server is running and accessible.

What’s Next?

Once you’ve verified that Jellyfin is running and accessible, you’re ready to configure it! In the next post, we’ll walk through setting up Jellyfin, adding your media libraries, and customizing it for the best streaming experience.

Ready to configure Jellyfin and start streaming? Head to Part 4 of this series to complete your setup!

Turn an Old Computer Into a Media Server Part 2 Adding a Storage Drive and Setting Up SMB Shares

Fri, 17 Jan 2025 07:41:16 -0700

Recap: Your Journey So Far

In the previous post, we took your old, dusty computer and gave it a new purpose by turning it into a powerful server running Ubuntu Server 24.04 LTS. We covered:

Why starting with an old PC is a smart move—it’s cost-effective, beginner-friendly, and environmentally conscious.
The minimum hardware specs needed to run a Jellyfin server, proving you don’t need the latest and greatest hardware to get started.
Step-by-step instructions for installing Ubuntu Server—from creating a bootable USB drive to completing the installation process.

With Ubuntu Server installed and ready to go, your old PC has been transformed into a dedicated server. Ready to take on its next task: hosting your own Jellyfin media library. Before we get to Jellyfin, the next step is to add storage drives and set up an SMB share. This will allow you to access your server’s media storage directly from a Windows or other Linux computer, which is essential for tasks like ripping Blu-rays and DVDs using software on a separate machine.

Section 1: Adding Storage to Your Server

Power Off the Server and Add Drives

Step 1: Physically Connect the Storage Drive(s) to Your Server

Power off command:

sudo shutdown -h now

For internal drives, install the drive into a free slot and connect it using SATA power and data cables.
For external drives, plug it into a USB port (powering off is not necessary).
Power on the server to ensure the drive is recognized.

SSH Into Your New Server

Not sure how to use SSH? Refer to this post: Master the Basics - How to SSH Into a Linux Server

Steps to Connect Using SSH

Open PowerShell on Windows:

The command for SSH:

ssh <username>@<server-ip>

Example From Part 1:

ssh kryptikwurm@172.27.0.200

Authenticate:

Enter your server password when prompted. (Don’t worry if you don’t see any characters while typing—that’s normal for security reasons.)

Partition and Format the New Drive

Step 2: Check if the Drive is Detected

Use the lsblk command to list all block (storage) devices:

lsblk

Identify the new drive (e.g., /dev/sdb or /dev/sdc) based on its size.

Note the name of the device (e.g., /dev/sdb), as you’ll use it in the next steps

Details on how to partition and format a hard drive in Linux can be found here: Master the Basics - How to Use parted to Create Partitions

Step 3: Creating the Basic Folder Structure of Your Media Library

As explained in this post your folder structure for Jellyfin should look like this:

    mnt/media/
    ├── Movies/
    ├── Shows/
    └── Music/

To create these folders in the /mnt/media use this command:

sudo mkdir -p /mnt/media/Movies /mnt/media/Shows /mnt/media/Music

To verify this worked:

ls -l /mnt/media

It should look something like this:

drwxr-xr-x 2 root root 4096 Jan 17 13:47 Movies
drwxr-xr-x 2 root root 4096 Jan 17 13:47 Music
drwxr-xr-x 2 root root 4096 Jan 17 13:47 Shows

The permissions of root:root will not work let’s make sure your user has access to these folders.

Change ownership of the folders:

sudo chown -R <username>:<username> /mnt/media

Example:

sudo chown -R kryptikwurm:kryptikwurm /mnt/media

To verify the ownership change worked:

ls -l /mnt/media

It should now look like this:

drwxr-xr-x 2 kryptikwurm kryptikwurm 4096 Jan 17 13:47 Movies
drwxr-xr-x 2 kryptikwurm kryptikwurm 4096 Jan 17 13:47 Music
drwxr-xr-x 2 kryptikwurm kryptikwurm 4096 Jan 17 13:47 Shows

Now grant Read, Write, and Execute to this user:

sudo chmod -R 770 /mnt/media/

To verify the permission change worked:

ls -l /mnt/media

It should now look like this:

drwxrwx--- 2 kryptikwurm kryptikwurm 4096 Jan 17 13:47 Movies
drwxrwx--- 2 kryptikwurm kryptikwurm 4096 Jan 17 13:47 Music
drwxrwx--- 2 kryptikwurm kryptikwurm 4096 Jan 17 13:47 Shows

Section 2: Setting Up SMB (Samba) Shares

Step 1: Install Samba and Nano

To share folders and files between your Linux server and other devices (including Windows systems), you will need Samba. Think of Samba as the bridge that connects different operating systems so they can easily exchange files.

You will also need Nano, a simple and beginner-friendly text editor for Linux. It is perfect for quickly editing configuration files without fuss.

To install both Samba and Nano in one step, run the following command:

sudo apt install samba nano -y

This command tells your server to download and install the required packages automatically. The -y flag saves you a step by confirming the installation for you.

Open the Samba configuration file for editing:

sudo nano /etc/samba/smb.conf

Add the following section at the end of the file to define the media share:

    [Media]
    path = /mnt/media
    browseable = yes
    read only = no
    guest ok = no
    valid users = your-username

Save and exit Nano:

Press Ctrl+O to save changes.
Press Enter to confirm.
Press Ctrl+X to exit.

I bet you are thinking ok but, what does this do? let’s break it down:

`[Media]`

This is the name of the share. When accessing Samba from a client device, this will appear as the share’s name in the network. You can change it to something meaningful for your setup, like [Movies] or [Files].

`path = /mnt/media`

This specifies the directory on your server that will be shared. In this example, the folder /mnt/media is being shared. Replace /mnt/media with the actual path of the directory you want to share.

`browseable = yes`

Setting this to yes allows the share to be visible when browsing the network. If set to no, users would need to know the share’s name to access it manually.

`read only = no`

This allows users to write (add, modify, or delete) files in the share. If set to yes, the share would be read-only, preventing users from making changes.

`guest ok = no`

This prevents unauthenticated users (guests) from accessing the share. Only users with valid credentials will be allowed access.

`valid users = your-username`

This restricts access to the share to the specified username. Replace your-username with the actual username you set up on the Ubuntu server. This ensures only authorized users can access the share.

Step 3: Create a Samba User

Add your server user as a Samba user:

sudo smbpasswd -a your-username

Follow the prompts to create a password for the Samba user.

Step 4: Restart Samba Service

Restart the Samba service to apply the changes:

sudo systemctl restart smbd

On Windows

Open File Explorer and type the server’s IP address in the address bar, prefixed with \\:

\\<server-ip>\<share-name>

Example: \\192.168.1.100\media

Enter your Samba username and password when prompted.

The shared folder should now be accessible, and you can drag and drop files into it.

On macOS or Linux

Open your file manager and choose “Connect to Server” (or a similar option).
Enter the SMB address:

smb://<server-ip>/Media

Example: smb://192.168.1.100/Media.

Conclusion

Adding storage to your server and setting up SMB shares might seem daunting at first, but breaking it down step by step makes it totally manageable. By the end of this guide, you’ve learned how to add new drives, set up a structured media library, and share files across devices with Samba. Now, your home media server is well on its way to becoming the ultimate hub for all your digital content.

Remember, this is just the beginning. Every new feature you add builds on what you’ve already accomplished. So, take a moment to celebrate—you’ve just leveled up your tech skills! Keep experimenting, keep learning, and don’t hesitate to reach out with questions.

Now that your storage is ready and accessible, it’s time to bring your media server to life! Head to Part 3 of this series to install Jellyfin and start organizing your collection.

Master the Basics - How Proper Organization Helps Jellyfin Automatically Fetch Metadata and Display Content Correctly

Sun, 12 Jan 2025 09:47:56 -0700

What Is Jellyfin Folder Structure and Why Does It Matter?

Jellyfin folder structure is the specific way you organize media files so Jellyfin can automatically fetch metadata, display posters, and group content correctly. Getting this wrong can cause blank posters, duplicate movies, and scattered TV episodes. Using the proper folder structure makes everything work automatically, no manual intervention needed.

Remember: it’s almost never Jellyfin’s fault. It’s your folder structure and file naming.

I know what you’re thinking, “But it worked fine in Kodi!” or “My folders make perfect sense to me!” I’ve been there too. When I migrated from Kodi to Jellyfin, I thought my organization was solid. It mostly was. But “mostly” meant duplicate movies, missing shows, and entire seasons that refused to group correctly. Once I fixed the structure and naming? Everything just worked.

Jellyfin’s actually really good at automatically fetching posters, descriptions, cast info, and episode data from TMDB and TheTVDB. But it needs your help. It can’t read your mind. It reads your folder names and filenames, then matches them against online databases.

This guide will show you exactly how to organize your media so Jellyfin’s metadata magic actually works.

The Three Rules That Break Everything

Before we dig in, there are about the three mistakes that cause 90% of metadata problems:

1. Missing release years on movies

Without the year, Jellyfin’s playing a guessing game. “The Thing” could be the 1982 classic or the 2011 prequel. Guess which one it picks? Usually the wrong one.

2. Wrong season/episode format

Use S01E01, not 1x1 or Season 1 Episode 1 or whatever creative variation you’ve got going on. Jellyfin expects a specific format, and anything else confuses it.

3. Mixed content types in one library

Movies and TV shows need separate libraries. Mix them, and you’ll get generic metadata, broken browsing, and a headache.

Get these three right and most of your problems disappear.

Why Folder Organization Actually Matters for Jellyfin

I bet you have thousands of files that work fine in your file browser. So, why does Jellyfin care how they’re named?

Because Jellyfin doesn’t know what your files are. It looks at folder names and filenames, then tries to match them against online metadata providers. When your media organization is correct, Jellyfin can automatically:

Downloads posters and background art
Groups TV episodes into seasons
Sorts movies correctly
Displays accurate titles, summaries, and cast info

When it’s wrong? You get blank posters, duplicate movies, TV episodes listed as individual videos, and missing or mismatched metadata.

That flat folder with 500 randomly-named movie files might work for you, but it’s a nightmare for automated metadata. And honestly, it’ll become a nightmare for you too once your library hits a few hundred items.

Seagate Barracuda 24TB Internal Hard Drive Large, reliable storage is essential for organizing and storing a well-structured media library that Jellyfin can index and fetch metadata from accurately; however, this drive is best for single-drive or light-duty setups, not high-availability NAS arrays.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Start With the Right Top-Level Folder Structure

Before you worry about individual filenames, get your top-level structure right. Jellyfin works best when each media type lives in its own library.

Here’s what I recommend:

/media
├── movies
├── shows
└── music

Each of these folders should be added to Jellyfin as a separate library, with the correct library type selected. Don’t mix movies and TV shows in the same library. I know it seems convenient, but it breaks everything. Mixed content gets generic metadata and kills browsing features.

How to Organize Jellyfin Library: Movies

Movies need one movie per folder, with the movie name and release year clearly visible. That’s it. That’s the secret.

The Correct Movie Folder Structure

/movies
└── Inception (2010)
    ├── Inception (2010).mkv
    ├── Inception (2010).srt
    └── poster.jpg

Critical rules:

One folder per movie
Include the release year in parentheses
Movie file name should match the folder name

Why Years Actually Matter

Remember “The Thing” example? Without the year, Jellyfin picks one version, often the wrong one. “The Thing (1982)” eliminates the guesswork entirely. Same goes for “True Grit” (1969 vs 2010), “Halloween” (1978 vs 2018), and dozens of other remakes.

Five seconds adding a year saves you ten minutes of manual metadata fixing later.

Extras and Bonus Content

If you’ve got deleted scenes or behind-the-scenes content, Jellyfin supports that:

Inception (2010)
├── Inception (2010).mkv
└── Extras
    └── Behind the Scenes.mkv

When you open the movie in Jellyfin, you’ll see an Extras section. It’s pretty cool.

What About Deep Folder Structures?

Some people organize like /movies/Christopher Nolan/Inception/. It can work if everything’s named perfectly, but honestly? It adds complexity without much benefit. The official Jellyfin documentation recommends keeping movies directly under the movies root for reliability.

Fractal Design Define R5 A quiet, flexible mid-tower case helps keep your homelab or media server tidy and organized, making it easier to manage drives and maintain the folder/file structure recommended in the guide; however, it may be overkill for very small or prebuilt systems.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

TV Show Folder Structure for Jellyfin

TV shows are where things get finicky. You need season folders and strict episode naming.

The Correct TV Show Structure

/shows
└── Breaking Bad
    ├── Season 01
    │   ├── Breaking Bad - S01E01.mkv
    │   └── Breaking Bad - S01E02.mkv
    └── Season 02
        └── Breaking Bad - S02E01.mkv

Episode Naming Rules

Use SXXEYY format for episodes
Always use leading zeros: S01, not S1
Episode numbers matter more than episode titles

You can include episode titles if you want (Breaking Bad - S01E01 - Pilot.mkv), but the S01E01 part is what Jellyfin actually cares about.

Multi-Episode Files

Got one file that contains multiple episodes? No problem:

Breaking Bad - S01E01-E02.mkv

Jellyfin understands this and will split the metadata correctly. You’ll see two episodes in the interface, both pointing to the same file.

Music Folder Organization

Music works differently. Embedded metadata matters more than filenames.

Recommended Music Structure

/music
└── Daft Punk
    └── Random Access Memories
        ├── 01 - Give Life Back to Music.flac
        ├── 02 - The Game of Love.flac
        └── 03 - Giorgio by Moroder.flac

Important: Artist and album folders help with browsing, but embedded tags (artist, album, track number) drive the metadata. If your music metadata is messy, use a tag editor like MusicBrainz Picard before importing. Jellyfin can’t fix bad tags, it just displays them.

Adding Your Media to Jellyfin Libraries

Alright, your folders are organized. Now let’s actually add them to Jellyfin:

Open the Jellyfin dashboard
Go to Libraries
Click Add Media Library
Select the correct type: Movies, TV Shows, or Music
Add the matching folder path
Enable metadata providers (TMDB for movies, TheTVDB for TV)
Save and scan

⚠️

Warning: Double-check that the library type matches the content. A movie library pointed at TV folders will never behave correctly. I’ve done this. It’s confusing as hell.

When the scan finishes, you should see posters appearing, episode counts looking right, and metadata filling in. If you see that, you’re golden.

Scan, Verify, and Fix Early

After the first scan, don’t just assume everything worked. Spot-check a few movies and shows:

Confirm posters and summaries appear
Look for duplicates or missing items
Check that TV seasons are grouping correctly

When I first migrated from Kodi, I assumed my structure was fine. The missing years and inconsistent episode naming caused duplicates and ignored seasons. Fixing filenames solved it way faster than any manual metadata edit would have.

Catch problems early when you’ve got 50 items, not after you’ve imported 5,000.

Advanced Tools and Automation

For large libraries, manual renaming is painful. Tools like Filebot or Sonarr can automate proper naming using the same patterns I’ve shown here.

But here’s the thing: automation is powerful, but mistakes scale quickly. Always test changes on a small batch first. I once accidentally renamed 200 movies incorrectly because I didn’t check the pattern. Don’t be like me.

NVIDIA SHIELD Pro Nice to have, not required. Why it fits this post: As a premium streaming client, it reliably displays organized Jellyfin libraries and supports advanced playback features, but it’s not required if you already have a capable streaming device.

Amazon Price: Loading...

Availability: Checking...

Amazon Newegg

Contains affiliate links. I may earn a commission at no cost to you.

Troubleshooting Common Jellyfin Organization Issues

Jellyfin Shows Blank Posters

Check the folder and filename format
Add the release year for movies
Refresh metadata after fixing names (right-click the item, Refresh Metadata)

Movies Appear Twice

Same movie exists in multiple folders
Different naming variations creating duplicate matches (like “Inception (2010)” and “Inception”)

TV Episodes Not Grouped Into Seasons

Episode names missing SXXEYY format
Season folders incorrectly named or missing
Episodes placed at the show root instead of season folders

This one drove me nuts for a week before I realized I had episodes sitting directly in the show folder instead of in Season folders.

Music Albums Mixed or Incorrect

Embedded tags are wrong or missing
Fix tags with a music tagger before rescanning
Jellyfin can’t guess music metadata from filenames alone

Library Scans but Nothing Appears

Wrong library type selected (movies scanning TV content)
Pointing to the wrong folder path
File permissions preventing Jellyfin from accessing the files

Check the Jellyfin logs if you’re stuck. They’ll usually tell you exactly what’s wrong.

Get Your Jellyfin Folder Structure Right Once

Proper Jellyfin folder structure is the foundation of a great Jellyfin experience. When your folders and filenames follow these patterns, metadata works automatically. Posters appear, seasons group correctly, and your library becomes something you actually enjoy browsing instead of something that makes you want to throw your server out a window.

Take the time to organize Jellyfin library correctly once. It’ll save you countless hours of manual fixes later and make Jellyfin feel polished instead of frustrating.

If you’re just starting out, organize first, then scan. Your future self will thank you. And if you’ve already got a messy library? Yeah, it’s painful to fix, but it’s worth it. I promise.

Master the Basics - How to Use Fdisk to Create Partitions Format Them and Add a Mount Point

Sun, 12 Jan 2025 08:34:30 -0700

So, you bought that multi-terabyte hard drive and want to add it to your server, but you’re not quite sure where to start. Don’t worry—I’ve got you covered with an easy-to-follow guide.

Setting up storage on Linux can be intimidating, especially when you’re dealing with tools like fdisk and fstab. But it’s not as complicated as it seems. By the end of this guide, you’ll know how to use fdisk to create partitions, format them, and set them up to automatically mount at boot using fstab. Let’s get started!

The Power of Partitions (and Why They Matter)

Think of your hard drive as a giant, empty filing cabinet. Without partitions, your system doesn’t know how to organize or access all that space. Partitions break your drive into smaller sections, each with a specific purpose—whether it’s for storing data, running programs, or setting up backups, partitions keep everything running smoothly.

With fdisk, you can easily create and manage these partitions. It’s a powerful tool that comes with almost every Linux distribution. In this guide, I’ll walk you through each step, whether you’re setting up a brand-new storage drive or reorganizing an existing one.

Step-by-Step Guide to Using `fdisk`, Formatting Partitions, and Configuring `fstab`

Step 1: Identify the Target Disk

Before creating partitions, you need to identify which drive you’re working with. Use the lsblk command to list all available disks and partitions:

lsblk

This will display something like:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   500G  0 disk
├─sda1   8:1    0   1M    0 part
├─sda2   8:2    0   2G    0 part /boot
└─sda3   8:3    0   498G  0 part /
sdb      8:16   0   12.7T 0 disk

Here, sda is your main disk, and sdb is an empty 14TB drive. For this tutorial, we’ll work with sdb.

⚠️ Caution: Double-check the disk name to avoid accidentally overwriting important data!

Step 2: Launch `fdisk`

Run the following command to open fdisk for your target disk:

sudo fdisk /dev/sdb

You’ll see a prompt like this:

Command (m for help):

Type m to view the available commands.

Step 3: Create a New Partition

1. Delete Old Partitions (Optional)

If the disk has existing partitions you want to remove, type d and follow the prompts to delete them.

2. Create a New Partition

To create a new partition, type n and press Enter. fdisk will ask:

Partition type: Choose p for primary or e for extended (choose p for most use cases).
Partition number: Press Enter to accept the default (usually 1).
First sector: Press Enter to accept the default (start of the disk).
Last sector: Press Enter to use the entire disk or specify a size (e.g., +100G for 100GB).

After completing this, you’ll see the new partition listed.

3. Write Changes to Disk

Type w to save the changes and exit fdisk. This writes the partition table to the disk.

Step 4: Format the Partition

Now that you’ve created the partition, it’s time to format it with a filesystem. A common choice is ext4. However, for a media server that hosts several large files, I recommend XFS.

sudo mkfs.xfs /dev/sdb1

This command formats the first partition (/dev/sdb1) on the sdb disk with the XFS filesystem. Replace xfs with your preferred filesystem (e.g., ext4 or btrfs) if needed.

Running lsblk again should look simmalar to this if everything worked:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   500G  0 disk
├─sda1   8:1    0   1M    0 part
├─sda2   8:2    0   2G    0 part /boot
└─sda3   8:3    0   498G  0 part /
sdb      8:16   0   12.7T 0 disk
└─sda1   8:17   0   12.7T 0 part /

Step 5: Create a Mount Point

A mount point is where your system will access the partition. For example, if you want to use it for storing media files, you might create a directory like this:

sudo mkdir -p /mnt/media

The -p flag ensures the command creates the directory, even if parent directories don’t exist.

Step 6: Mount the Partition (Temporary Test)

Before configuring fstab, test mounting the partition:

sudo mount /dev/sdb1 /mnt/media

Verify the mount by running:

df -h

You should see /dev/sdb1 listed with /mnt/media as its mount point.

Step 7: Add the Partition to `fstab`

To ensure the partition mounts automatically at boot, add it to the /etc/fstab file. Start by retrieving the partition’s UUID:

sudo blkid /dev/sdb1

You’ll see output like this:

/dev/sdb1: UUID="1234-5678-90AB-CDEF" TYPE="xfs"

Copy the UUID and open the fstab file for editing:

sudo nano /etc/fstab

Add the following line at the end of the file:

UUID=1234-5678-90AB-CDEF /mnt/media xfs defaults 0 2

Here’s what the options mean:

UUID=1234-5678-90AB-CDEF: Unique identifier for the partition.
/mnt/media: Mount point.
xfs: Filesystem type.
defaults: Standard mount options.
0 2: Dump and fsck options (usually safe to leave as-is).

Save the file and exit.

Step 8: Test the `fstab` Configuration

To verify your changes, unmount the partition and remount all entries in fstab:

sudo umount /mnt/media
sudo mount -a

If no errors appear, your configuration is correct.

Wrapping It All Up Congrats! You’ve successfully created a partition, formatted it, and set it up to mount automatically using fstab. Whether you’re adding a new drive to your home media server or managing existing storage, these steps will be your go-to guide.

Just remember—mistakes happen. Always double-check your disk names and back up important data before making any changes. With a bit of practice, managing partitions and mount points will become second nature.

Ready to level up? Put these skills to use by setting up dedicated partitions for media storage, backups, or even Docker containers. The possibilities are endless.

Master the Basics - How to SSH Into a Linux Server

Sun, 12 Jan 2025 07:33:02 -0700

Do you need to keep a monitor and keyboard connected to your server? Nope. SSH lets you access your server’s command prompt directly from your Windows, Mac, or Linux computer. You’ve probably heard about SSH in tech forums or tutorials—it’s a powerful tool that allows you to control your server from anywhere on your local network.

But before we dive in, there’s one crucial rule to remember: Do not expose your SSH connection to the internet unless you’re absolutely sure of what you’re doing and have a solid reason for it.

So, what exactly is SSH, and how can you use it? Let’s break it down step by step.

What Is SSH, and Why Should You Care?

SSH stands for Secure Shell, a protocol that allows you to securely access and manage a server over a network. Imagine being able to control your server from your laptop while sitting on the couch—no monitor or keyboard required. That’s the power of SSH.

With SSH, you can run commands, transfer files, and troubleshoot issues without ever touching your server physically. It’s a game-changer when setting up a media server or managing other home-based projects.

Why You Shouldn’t Expose SSH to the Internet

Before we get into the details, let’s talk about a crucial security concern. Exposing your SSH server to the internet can be risky. Bots and hackers are constantly scanning for open SSH ports. If they find yours, they’ll try to brute-force their way in by guessing your username and password.

Here’s why it’s safer to keep SSH local:

Reduced Risk: When SSH is only accessible on your local network, only devices connected to your home network can attempt to access the server.
Peace of Mind: You won’t have to worry about configuring firewalls or securing your server against online threats.
Ease of Use: No need for complicated setups like VPNs, PKI certificates, or port forwarding.

Keeping your SSH access local keeps things simple and secure. Let’s move on to setting it up.

Step-by-Step Guide to SSH into Your Linux Server

1. Check Your Server’s IP Address

Before you can SSH into your server, you need its local IP address. You can find this by logging into the server directly and running:

ip addr

Look for the section labeled inet. The number will look something like 192.168.x.x. That’s your server’s IP address.

Example:

2. Install an SSH Client on Your Computer

Windows: Use the built-in PowerShell tool or download a program like PuTTY.
Mac/Linux: Your terminal already has an SSH client installed.

3. Connect to the Server via SSH via PowerShell

Press the Start button on your keyboard and type PowerShell - Click the icon that says Windows PowerShell.

ssh username@192.168.x.x

Replace username with your Linux user account and 192.168.x.x with your server’s IP address.

For example:

ssh john@192.168.1.100

4. Enter Your Password

After you hit enter, the server will ask for your password. Type it in carefully (you won’t see the characters as you type for security reasons) and press enter.

If the connection is successful, you’ll see a prompt that looks something like this:

KryptikWurm@mediaserver:~$

Congrats! You’re now remotely connected to your server.

5. Troubleshooting Common Issues

“Connection Refused”: Make sure the SSH service is running on your server. Run:

  sudo systemctl start ssh

“Permission Denied”: Double-check your username and password.
Can’t Find IP: Ensure your server and computer are on the same local network.

Keep It Local, Keep It Safe SSH is an incredibly powerful tool, but with great power comes great responsibility. Keeping your SSH access local minimizes security risks while still giving you all the perks of remote server management.

So, open up your terminal, connect to your server, and start navigating the world of Linux like a pro. Just remember, safety third!

Ready to Level Up? Now that you’ve nailed the basics, you’re well on your way to mastering your home media server. Keep learning, keep experimenting, and don’t be afraid to take on new challenges. You’ve got this!

Turn an Old Computer Into a Media Server Part 1 Hardware and Installing Linux

Fri, 10 Jan 2025 09:07:02 -0700

Do you have an old computer collecting dust in the closet—the one you kept around thinking it might be useful someday? Well, today is the day it finally gets its moment to shine. Instead of dropping hundreds (or even thousands) on brand-new hardware, you can turn that old machine into a fully functional media server. It’s a great way to explore the world of home media servers without spending a lot of money.

The best part? It doesn’t take much to get started. With just a little effort and some free software, you’ll be streaming your favorite movies, TV shows, and music right from that old computer. Let’s go through what you’ll need and how to get your server up and running in no time.

Why Start With an Old Computer?

When getting into home media servers, there’s one golden rule: Start small and upgrade later. A common mistake is jumping straight into expensive, custom-built setups, only to realize it’s more than they bargained for. Using an old computer is a low-risk way to learn the basics and see if this hobby is right for you.

Think of it like using training wheels. You can learn how to install software, organize your media, and troubleshoot issues—all without worrying about wasting money on high-end hardware. Plus, it’s eco-friendly. Instead of throwing out that old PC, you’re giving it a new purpose.

Minimum Specifications: What Does Your Old Computer Need?

To run a basic Ubuntu-based Jellyfin server, you don’t need the latest gaming rig or high-end processors. Both Ubuntu Server and Jellyfin are lightweight and versatile, so your old machine can likely handle it. Here’s the bare minimum you’ll need to get started:

Bare Minimum Hardware Requirements:

Processor (CPU): Intel Core i3 2nd Gen or AMD equivalent
RAM: 4 GB
Storage: At least 100 GB of free space (more if you plan to store lots of media locally).
Operating System: Ubuntu Server 24.04 LTS
USB Stick: 32 GB for the OS installation
Network: An Ethernet connection (wired or Wi-Fi)

This setup is more than enough to get started with Jellyfin. As your media library grows or if you want to add more features, you can always upgrade later.

Best Experience Recommended Hardware

Processor: No change
RAM: 8 GB
OS Storage: 200 GB of SSD storage

Kingston 240GB SSD

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg
Media Storage: 8 TB or more depending on the size of your media collection

Seagate Barracuda 24TB Internal Hard Drive

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg
Network: Wired ethernet connection is best

If your computer meets these requirements, you’re ready to go. If it doesn’t, you might still be able to make it work with a few tweaks, especially if you don’t need heavy-duty transcoding (converting video files on the fly). Transcoding will be covered in a later post.

Proof Old Computers Will Work

To show you that this can absolutely be done using old hardware, I’m going to build a media server with the following components:

Processor: i5-2500k – This CPU was released back in 2011.
RAM: 16 GB
OS Storage: 500 GB SSD
Media Storage: Two 2 TB Hard Drives
Video Card: NVIDIA 750ti (Only needed for the installation)

Now that you’ve found an old computer suitable for this project, it’s time to turn it into a fully functional media server by installing Ubuntu Server 24.04 LTS. This version of Ubuntu is designed for robust, secure, and efficient server performance—even on older hardware. Let’s dive into the installation process and bring your old computer back to life as a high-performing media server.

And yes, you could use Debian or pretty much any other Linux distro for this. I chose Ubuntu because it’s popular, well-documented, and widely supported.

Installing Ubuntu Server 24.04 LTS

Now it is time for the fun part: Bringing your media server to life. Follow these steps to get Ubuntu 24.04 installed and running:

1. Prepare Your Old Computer and Thumb Drive

Find a monitor, keyboard, and mouse to temporarily hook up for the setup.
Download the Ubuntu Server 24.04 LTS ISO file from Ubuntu.com.
Use a tool like Rufus (on Windows) or Etcher (on macOS/Linux) to create a bootable USB drive with the ISO.

2. Use Rufus to Create a Bootable Thumb Drive

Download the portable version of Rufus
Open Rufus
Press SELECT to select the Ubuntu Server ISO you just downloaded and press START
Select write in DD Image mode when prompted
Press OK to format you USB stick
- This will erase everything on the drive

You should now have a bootable USB Stick with Ubuntu Server on it.

3. Boot from USB

Insert the bootable USB into the computer you’re installing Ubuntu on.
Power on the computer and enter the BIOS/UEFI settings (usually by pressing F2, F12, Del, or Esc during boot).
Make sure the boot order places USB before the hard drive. This way if a USB is detected it will boot off of it first.
Save and exit the BIOS settings. Your system will reboot and load the Ubuntu Server installer.

4. Begin the Installation

GNU Grub Menu - When prompted press enter
Select your default language
Select your keyboard layout
Choose the type of installation - Select Ubuntu Server (minimized) and Search for third-party drivers
Network Config - Because this is a server, we need to set a static IP (one that doesn’t change) Tab up to the location that lists the network device name (yours will be different) and press enter
You will now see this menu - Select Edit IPv4 and press enter
Select Manual from the menu and press enter
My network config will be different than yours. Chances are your network is on the 192.168.0.0/24 or 192.168.1.0/24 network. If you don’t know what your network is, you can open PowerShell on your Windows system and run this command:

ipconfig -all

the ipconfig command will give you everything need for the IPv4 config page.
However, something that will be different is how the subnets are displayed. On windows you will likely see 255.255.255.0 for Linux you will need to your IP address but change the last number to a 0 and add /24 like this:

192.168.0.0/24
or
192.168.1.0/24

Proxy Config - Leave this blank unless you know you are using a proxy.
Guided Storage Configuration - For this initial setup leave everything default. I’ll cover a more advanced storage layout in another post.
Storage Config Summary
Confirm Destructive Action - This will wipe everything from the selected drive.
Profile Configuration
- Your name - This is not the username. I tend to make my username and name field match.
- Your server name - What do you want to call your server?
- Pick a username - I use what is in the Your name block.
- Password - Please make this a strong password.
Upgrade to Ubuntu Pro - Skip for now
SSH Config - Make sure to select Install OpenSSH server
Third-party drivers - If you have any to install you can do so from here.
Featured Server Snaps - Leave all of these blank
The installation will only take a few minutes. Once completed, remove the USB stick and reboot the system.
Login - Verify you can log in with the username and password you set during installation.
Update the server - Use this command to install any updates. I recommend doing this about once a week to make sure your server stays up to date on any security patches.

sudo apt update && sudo apt upgrade -y

Reboot - From the command line

Reboot

Some of you may have a keen eye and can see that I’m installing this on a VM and not my i5-2500k. This was so I could capture the screenshots above. I’ll install Ubuntu on my physical computer and use it going forward.

Congratulations you have set up an Ubuntu server.

Ready to bring your media server to life? Head to Part 2 to install Jellyfin and be one step closer to streaming your favorite content.

Stop Winging It - Use Obsidian to Master Your Server and Network Notes

Sat, 04 Jan 2025 07:22:27 -0700

Ever feel like the more you dive into self-hosting and home labs, the more overwhelming it gets? Managing Proxmox, Docker, Jellyfin, and the ARR suite can get complicated fast, and it’s all too easy for crucial details to slip through the cracks. That’s where Obsidian comes in. Think of it as your personal command center for all the notes, ideas, and guides you need to keep this complex hobby organized.

Honestly, I wish I had started using it sooner. For years, I worked on my home server setup without documenting anything. Now, I’m stuck retracing my steps, trying to remember how I configured certain things or fixed specific issues. It’s been frustrating, and I’ve learned the hard way just how valuable well-organized notes can be.

Let’s take a look at how Obsidian can save you from that same frustration and help you level up your home server documentation.

Why Documenting Your Journey Matters

Building a home server isn’t a one-time project—it’s an ongoing adventure. From setting up your first Proxmox server to fine-tuning your backup and notification automation, there’s a ton to learn and even more to remember. Documenting your progress helps you:

Remember what you did: That one-off command that fixed Docker or your NFS share? It’s easy to forget unless you write it down.
Save time later: When it’s time to upgrade hardware or troubleshoot an issue months down the line, having notes handy can save you hours of Googling.
Learn from your mistakes: Keeping track of what worked and what didn’t helps you refine your setup and avoid repeating frustrating mistakes.

I wish I had started documenting my setup from day one. It would’ve saved me so much time now that I’m trying to piece together commands, configurations, and solutions I figured out years ago. It might feel unnecessary to write things down as you go, but trust me—your future self will thank you.

Why I Like Obsidian

Here’s why Obsidian is my go-to for documenting my home server setup:

Everything in One Place: With Obsidian, I can keep all my notes, commands, and guides in one central spot, avoiding the chaos of scattered files and sticky notes.
Linked Notes: I love how Obsidian lets me link notes together—like connecting my “Docker Setup” note to my “Sonarr Configuration.” It makes it easy to see how everything ties together.
Markdown: Obsidian uses Markdown, which is lightweight and easy to write, organize, and export without needing extra tools.
Personal Knowledge Base: Over time, my Obsidian Vault has turned into a custom knowledge base tailored specifically to my home server, full of everything I’ve learned and documented.
Offline Access: If I accidentally break my internet connection while messing around with my server, no problem—Obsidian works entirely offline. And if I sync my Vault with OneDrive or Google Drive, I can access my notes on any computer.
Visual Representation of Notes: Obsidian’s graph view maps out how all my notes are connected, giving me a visual overview of my documentation and helping me see the bigger picture.

These features have been game-changers for me. If I had started using Obsidian sooner, I would’ve saved myself a ton of frustration and made my home server journey a lot smoother.

Here’s what my graph view looks like after just 2 months:

Getting Started with Obsidian

Obsidian Download Link

Here’s how I use Obsidian to document my home server setup:

Create a Vault: In Obsidian, a Vault is where all your notes are stored. I made one just for my home server setup and named it something fun like “Home Data Center.”
Organize with Categories: I set up folders or tags for key topics like “Proxmox,” “Docker,” “Jellyfin,” and “Usenet.” It keeps everything organized from the start.
Document as You Go: Whenever I solve a problem, set up a new tool, or try something new, I write it down. I also include screenshots or links to helpful guides for future reference.
Link Related Notes: If I have a note on “Radarr Setup,” I link it to my “Docker Compose” note so I can easily see how they’re connected.
Add a Daily Log: Using Obsidian’s Daily Notes feature, I keep a journal of my progress. I jot down what I worked on, what I learned, and any issues I ran into.

The best part about Obsidian is how flexible it is. Whether you like writing detailed guides or just quick bullet points, it’s the perfect space to organize your thoughts and make sense of everything.

Practical Examples of Using Obsidian

Here’s how I use Obsidian to take my home server setup to the next level:

Proxmox Setup Notes: I keep a step-by-step guide for setting up virtual machines, complete with commands, screenshots, and links to the official documentation.
Troubleshooting Logs: Whenever I run into errors—like Sonarr not connecting to SABnzbd—I document the issue and how I fixed it. This saves me from having to troubleshoot the same problem twice.
Wish Lists: I keep a running list of features I want to add, like a VPN or reverse proxy, along with links to guides on how to implement them. (Bonus points if they link to diymediaserver.com! 😉)
Personal Wiki: Over time, my Obsidian Vault has evolved into a custom knowledge base for my home server setup. As I add more services or tweak configurations, my notes grow with me.

These examples have saved me so much time and frustration. If you’re building or maintaining a home server, Obsidian is a game-changer.

Stick With It

If there’s one lesson I’ve learned the hard way, it’s that good documentation is priceless. Trying to piece together my home server setup from memory has been nothing but frustrating and time-consuming. But you don’t have to go through the same hassle.

Start documenting your journey now with Obsidian. Spending just a few minutes jotting down what you’ve done can save you hours—or even days—of effort down the road. Plus, you’ll have a record of your progress to look back on with a sense of accomplishment.

Don’t put off documentation—your future self will thank you. Download Obsidian today and start building your second brain for your media server adventure!

Kodi vs Plex vs Jellyfin vs Emby the Ultimate Media Playback Software Showdown

Fri, 03 Jan 2025 06:21:40 -0700

Imagine this: You’ve spent hours setting up the perfect home media server. Your movies, TV shows, and music are all neatly organized and ready to go. But now you’re faced with a big question: What software should you use to actually enjoy all that content? Kodi, Plex, Jellyfin, and Emby are some of the most popular options—but which one is right for you?

I’ve been there, and after trying them all, I landed on a hybrid approach that works great for me. I use Kodi as my media player because I love how customizable the interface is. It lets me see exactly what I want—no clutter, no nonsense. But I also pair Kodi with the Jellyfin plug-in, which gives me all the backend perks of Jellyfin, like media syncing and watched status tracking across all my devices. This combo gives me the best of both worlds.

The Basics: What Do These Programs Do?

Kodi, Plex, Jellyfin, and Emby all have the same core purpose: to organize, play, and stream your media library. But even though they share this goal, each one offers a unique mix of features, philosophies, and user experiences.

Some prioritize ease of use, while others focus on customization. Some lock premium features behind a paywall, while others are completely free and open-source. Let’s take a closer look at how they compare and why I chose my own setup.

Feature Comparison: At a Glance

Here’s a quick comparison table to show how Kodi, Plex, Jellyfin, and Emby stack up against each other:

Feature	Kodi	Plex	Jellyfin	Emby
Cost	Free	Free (Premium for advanced features)	Free	Free (Premium for advanced features)
Open Source	Yes	No	Yes	No
Offline Playback	Yes	Yes (with premium)	Yes	Yes (with premium)
Live TV/DVR Support	Yes (via add-ons)	Yes (with premium)	Yes	Yes (with premium)
Streaming Outside Home	Limited	Yes (with premium)	Yes	Yes (with premium)
Customization	Very High	Limited	Moderate	Moderate
Ease of Setup	Moderate (more technical)	Easy	Moderate	Moderate
Client Support	Wide range of devices supported	Wide range of devices supported	Growing list of supported devices	Wide range of devices supported

Why I Chose Kodi + Jellyfin

After experimenting with each of these programs, I ultimately chose Kodi as my front-end media player for one main reason: its customization.

Kodi lets me tailor the viewing experience exactly to my liking. There are no recommended shows I don’t care about, no ads, and no unnecessary features cluttering up the interface. Everything is clean, simple, and set up exactly how I want it. If you like having full control over your media experience, Kodi is hard to beat.

But Kodi does have its limitations. It doesn’t handle watched status syncing, streaming to multiple devices, or media transcoding on its own. That’s where Jellyfin comes in. By running Jellyfin as my backend server and using the Jellyfin plug-in for Kodi, I get the best of both worlds:

Watched Status Syncing: I can start watching a movie in the living room and pick up exactly where I left off in the bedroom. Everything stays synced across all my devices.
Media Syncing Across Devices: My entire media library is organized and accessible on every device throughout my home.
Remote Streaming: Jellyfin lets me stream my content outside of my home network without paying for a subscription.
Media Transcoding: If a device can’t play a certain file format, Jellyfin transcodes it on the fly. This keeps my media compatible with all my devices without the hassle of manually converting files.

This combination gives me Kodi’s unmatched customization with Jellyfin’s powerful syncing, streaming, and transcoding features. It’s a perfect setup that offers complete control without sacrificing functionality. I’ll be posting a detailed guide on how to set this up soon.

The Pros and Cons of Each Platform

Kodi: The Customizer’s Dream

Pros:

Unmatched Customization: Kodi’s open-source nature lets you customize nearly every aspect of the interface. You can choose from hundreds of skins, build custom menus, and install add-ons to expand its functionality.
Wide Device Support: Kodi runs on just about anything—Windows, macOS, Linux, Android, Raspberry Pi, and more. It’s a great way to repurpose older devices as media players.
Offline Playback: Unlike streaming-focused platforms, Kodi is built for local playback. As long as your media is stored locally or on a network share, Kodi can play it without any issues.
Free and Open Source: Every feature is free, and its open-source community keeps the platform constantly evolving and improving.

Cons:

Steep Learning Curve: All that customization comes with complexity. If you’re new to Kodi, figuring out add-ons, optimizing playback, or setting up network shares can be a bit challenging.
Limited Remote Streaming: Kodi isn’t designed for streaming outside your home network. While there are plugins and workarounds, they’re not as user-friendly as solutions from Plex or Jellyfin.
Lacks Backend Features: Kodi doesn’t natively sync watched status or manage media libraries across devices. But when paired with a server like Jellyfin or a service like Trakt, you can get these features working seamlessly.

Best For: Those who love to tinker, customize, and build a personalized interface for local playback. If you enjoy full control over your media experience, Kodi is the way to go.

Kodi Download Link

Plex: The Streaming Superstar

Pros:

Ease of Use: Plex is hands down the most beginner-friendly option. It’s easy to set up and automatically organizes your media with rich metadata like cover art, descriptions, and even trailers—all with minimal effort.
Remote Access: Plex makes streaming outside your home network a breeze. Whether you’re at work or on the go, you can access your entire library on any supported device.
Friend Sharing: Want to share your media with friends or family? Plex lets you do that easily, with options to control who sees what.
Wide Device Support: Plex is available on almost every platform, including smart TVs, gaming consoles, and mobile devices.
Premium Features: With a Plex Pass subscription, you get extras like offline downloads, hardware transcoding, and live TV/DVR support.

Cons:

Paywall for Premium Features: Some of Plex’s best features—like offline playback and advanced transcoding—require a paid Plex Pass subscription.
Limited Customization: While Plex’s interface is polished and user-friendly, it doesn’t offer the deep customization options that Kodi provides.
Closed Source: Plex is proprietary software, meaning you’re reliant on the company for updates, support, and feature development.

Best For: Those who prioritize ease of use, remote streaming, and a polished experience—and don’t mind paying for premium features.

Plex Download Link

Jellyfin: The Open-Source Hero

Pros:

Completely Free: Jellyfin is 100% free and open-source, offering features like remote streaming, live TV support, and watched status syncing—all without subscriptions or paywalls.
Privacy-Focused: Unlike Plex, Jellyfin doesn’t rely on external servers or track your usage. Your data stays on your server, giving you full control over your media and privacy.
Server-Client Architecture: Jellyfin uses a centralized server to manage your media library, while client apps—including third-party options like Kodi—connect to the server for playback.
Transcoding Capabilities: Jellyfin handles on-the-fly transcoding, ensuring compatibility across various devices and formats without needing to manually convert files.
Active Community Development: As an open-source project, Jellyfin is constantly evolving thanks to a dedicated community of developers.

Cons:

Setup Complexity: Although not as complex as Kodi, Jellyfin does require some technical knowledge to set up a server and configure client devices.
Growing Ecosystem: Jellyfin’s client apps are still catching up to the polish and platform support of Plex. While it runs on most major devices, some features can be limited depending on the app.
Not as Polished: Since Jellyfin is community-driven, its interface isn’t as sleek or refined as Plex or Emby.

Best For: Those who value open-source software, privacy, and getting premium features for free—and don’t mind a bit of extra setup to get things running smoothly.

Jellyfin Download Link

Emby: The Middle Ground

Pros:

Balanced Feature Set: Emby offers a good mix of ease of use and flexibility. It’s not as customizable as Kodi or as straightforward as Plex, but it strikes a nice balance between the two.
Remote Streaming: Just like Plex and Jellyfin, Emby lets you stream your media outside your home network, although this feature requires a paid subscription.
Live TV/DVR Support: Emby shines when it comes to live TV and DVR functionality, offering robust tools for recording and managing live broadcasts.
Wide Device Support: Emby is available on most major platforms, including smart TVs, gaming consoles, and mobile devices.
Premium Features: With an Emby Premiere subscription, you get access to features like hardware transcoding, offline downloads, and live TV—similar to what Plex Pass offers.

Cons:

Subscription Costs: Many of Emby’s standout features, like remote streaming and advanced transcoding, are locked behind the Emby Premiere paywall.
Not Open Source: Although Emby started as an open-source project, it has since gone closed-source, meaning the company now controls development and support.
Less Community Development: Unlike Jellyfin, Emby doesn’t benefit from open-source community contributions, so updates and new features depend entirely on its developers.

Best For: Those looking for a middle ground between Kodi’s customization and Plex’s polished interface—and who don’t mind paying for advanced features.

Emby Download Link

Which One Should You Choose?

The best media playback software depends on what matters most to you:

Choose Kodi if you love customization and want complete control over your interface.
Choose Plex if you want a polished, user-friendly experience and don’t mind paying for premium features.
Choose Jellyfin if you value open-source software and want advanced features for free.
Choose Emby if you’re looking for a middle ground between Plex’s polish and Jellyfin’s open-source flexibility.

For me, the combination of Kodi and Jellyfin is the ultimate setup. Jellyfin manages the backend—syncing media, tracking watched status, and enabling remote streaming—while Kodi provides a beautiful, fully customizable front-end experience.

Final Thoughts

All of these platforms are excellent choices, each with unique strengths to fit different needs. Whether you prioritize ease of use, customization, or cost, there’s an option that’ll work for you. I recommend experimenting with them, or even mixing and matching like I did, to find the perfect setup for your media server.

Ready to build your ideal media setup? Jump in, explore, and make it your own—your movies and shows will thank you!

The Best Devices to Play Your Locally Stored Media with Kodi Plex Jellyfin or Emby

Wed, 01 Jan 2025 06:36:03 -0700

Have you ever downloaded a movie or ripped your favorite Blu-ray, only to wonder how to enjoy it on your TV or tablet? With media server software like Kodi and Jellyfin, your locally stored media collection can be transformed into a Netflix-like experience. But there is a catch: you need a device to bring your media to life. The good news? There are many options for every budget. Whether you’re looking for a living room powerhouse or something portable, chances are there’s a device perfect for you. Let’s look at the best ones to get you streaming your media like a pro.

1. Android TV Devices: Simple and Affordable

If you want something dead easy to set up and that is budget-friendly, Android TV boxes like the NVIDIA Shield TV or Chromecast with Google TV are great choices.

Why they work: These devices run Android, making them compatible with both Kodi and Jellyfin apps right out of the box. There is no complicated installation process.
Performance: The NVIDIA Shield is surprisingly powerful, handling 4K HDR and even AI upscaling. Chromecast with Google TV is great for HD and 4K on a tighter budget.
Bonus: Both are capable of handling other streaming apps like Netflix and YouTube, so they double as an all-in-one entertainment device. Additionally, they both offer casting from your laptop, phone, or tablet.

NVIDIA SHIELD Pro

The NVIDIA SHIELD is my go-to device. It is easy to use and just works.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

Google Chromecast

This is a great runner up if you can’t find the Shield as a goo price.

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

2. Raspberry Pi: For Those Who Love To Tinker

For DIY enthusiasts, the Raspberry Pi is a solid option for running Kodi.

Why it’s cool: It’s cheap, customizable, and fun to set up. You can install LibreELEC (a lightweight Kodi-based operating system) or run Jellyfin through Docker.
Performance: The latest Raspberry Pi 4 can play 1080p and 4K content, though it’s best with wired Ethernet for smoother streaming.
Who it’s for: If you enjoy tinkering and want a hands-on project, this is a great option. Plus, you’ll learn a lot about media servers along the way.

RaspberryPi 4GB

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

3. Amazon Fire TV: A Budget-Friendly Option

Amazon’s Fire TV Stick 4K and Fire TV Cube are popular choices for those who are more budget-conscious.

Why they shine: Both devices support Kodi installation and Jellyfin via sideloading or the app store (depending on region).
Performance: These devices handle 4K content well and integrate easily with Alexa voice controls.
Limitations: You may need to sideload apps like Kodi if they are not yet available in your region, but there are guides for how to accomplish this.

Amazon Fire TV Stick 4K

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

Amazon Fire TV Cube

Contains affiliate links. I may earn a commission at no cost to you.

Amazon

4. Dedicated HTPCs (Home Theater PCs): The Hardcore Solution

For the most hardcore home media experience, nothing beats a dedicated Home Theater PC (HTPC). This could be a prebuilt mini PC, an old desktop repurposed for media playback, or a fully decked-out custom PC.

Why they’re unmatched: With an HTPC, you have a full Windows or Linux PC hooked up to your TV and have all of the benefits that come with it. Because of their superior hardware specifications, they are much faster and provide a good user experience. HTPCs You also get better hardware for decoding high-quality files like Blu-ray rips or 4K HDR.
Customizable: Whether you want Windows, Linux, or even a lightweight option like LibreELEC, you’re in control.
Drawbacks: This is the priciest and most space-consuming option, but it’s worth it if you want the best.

5. Game Consoles: Dual-Purpose Media Players

Already own a gaming console? Good news—you might not need anything else!

Xbox: Xbox consoles support the Jellyfin app natively. You can also use Kodi on some models with a bit of effort.
PlayStation: While Jellyfin doesn’t have native support yet, you can use the web app via the PS browser.
Why it’s great: These devices are already plugged in and configured to use your TV they also support streaming in HD or 4K. It’s a simple solution if you’re a gamer.

6. Smartphones and Tablets: Portable Media Champs

Don’t forget about your handheld devices. Jellyfin and Kodi have apps for Android and iOS, letting you stream your library on the go.

Why they work: Perfect for on-the-go viewing or casting to a bigger screen.
Features: You can download files for offline playback or stream directly from your server over Wi-Fi.
Best use case: These devices are great secondary players when not in front of your main TV.

7. Smart TVs: Built-In Convenience

If you own a smart TV, check to see if Kodi or Jellyfin has a native app in the app store. Samsung and LG TVs, for example, can run Jellyfin via their web browsers or dedicated apps.

Why it’s convenient: No extra devices, no extra remotes—everything’s already on your TV.
Limitations: Older TV models may struggle with newer codecs like H.265, so it’s worth checking your specs.

Final Thoughts: Pick Your Perfect Device

No matter your budget or tech skills, there’s a device that will fit your needs for playing locally stored media on Kodi or Jellyfin. From the powerful NVIDIA Shield to the flexible Raspberry Pi, each option offers unique perks. The key is matching the device to your lifestyle and media setup.

So what are you waiting for? Grab the remote or a screwdriver and start enjoying your media on the big screen. Your perfect streaming setup is just a few steps away!

Ready to dive in? Start small with an affordable Fire Stick, or go big with a custom HTPC. The choice is yours—your media, your way.

How to Rip DVDs and Blu Rays for Your Home Media Server

Sat, 28 Dec 2024 07:11:39 -0700

When you rip your DVDs and Blu-Rays, you can store all your media in one centralized location. No more digging through stacks of discs to find your favorite movie or TV show—you can browse your entire collection digitally from any device connected to your media server. This makes it easy to:

Search Quickly: Use metadata like titles, genres, and cast to find movies in seconds.
Organize Effectively: Group content by genre, director, year, or any custom structure that suits your style.
Stream to Multiple Devices: With media server tools like Jellyfin or Plex, you can access your library on smart TVs, laptops, tablets, and smartphones anywhere in your home—or even remotely.

Physical DVDs and Blu-Rays wear out over time. Discs can get scratched, warped, or lost, putting your movie and show collection at risk. Ripping your discs lets you create digital backups, so you can enjoy your collection for years without worrying about:

Scratched Discs: No more frustration when a favorite movie freezes or skips.
Storage Challenges: Free up space and avoid clutter by getting rid of bulky disc cases and shelves.
Discontinued Titles: Preserve rare or out-of-print movies that might be impossible to replace.

The Process is Simpler Than You Think

If ripping DVDs and Blu-Rays sounds intimidating, don’t worry—you’re not alone. Many people think it’s overly technical or requires advanced computer skills, but with the right tools, it’s surprisingly straightforward.

Today’s software solutions are built for simplicity, often requiring just a few clicks to get started. Tools like MakeMKV and HandBrake are user-friendly, with intuitive interfaces that guide you step by step. You don’t need to be a tech expert—if you can install software and follow basic instructions, you’re good to go.

I’ll walk you through everything you need, from choosing the right hardware and software to organizing and storing your ripped files. And if you run into any challenges, don’t worry—I’ve got tips and troubleshooting advice to help you out. This is a learning process, and with a bit of patience and practice, you’ll feel confident in no time.

By the end of this guide, you’ll see that ripping your DVDs and Blu-Rays is not only doable but also incredibly rewarding. You’ll have a digital library you can enjoy whenever and wherever you want—no more dealing with physical discs. So take it one step at a time, and let’s get started!

What You’ll Need

Hardware Requirements
- A DVD/Blu-Ray drive (internal or external).
  - OWC Mercury Pro 16X Blu-ray
- A computer with sufficient storage space for the ripped files.
  - DVDs about 10GB of free space
  - Blu-Ray 1080p about 40GB of free space
  - Blu-Ray 4k UHD about 100GB of free space
- Optional: Large external / internal hard drives, or NAS for additional storage.

Seagate Barracuda 24TB Internal Hard Drive

Contains affiliate links. I may earn a commission at no cost to you.

Amazon Newegg

How to Install Sonarr in Docker

Software Options
- MakeMKV: MakeMKV is a simple yet powerful tool for ripping Blu-rays into MKV files. It’s available for both Windows and macOS and focuses on doing one thing really well—no unnecessary features, just straightforward ripping. While MakeMKV technically offers a free 30-day beta trial, there’s a catch: you can either download the latest version each month or use the updated beta key posted in the forums to keep it active. This effectively lets you use the software for free indefinitely. Even though it’s labeled as “beta,” MakeMKV has been in beta for years and shows no signs of changing. For now, there’s no reason to pay for it.
- HandBrake: When you use MakeMKV to rip a Blu-Ray, it creates an MKV file that’s an exact copy of the movie as it exists on the disc—which often means a file size of 20 to 30GB or more. To make these files smaller and easier to manage, you can use HandBrake to compress them without noticeably losing quality. This step isn’t mandatory, but storing, playing, and streaming such large files can be inefficient and waste resources if smaller, high-quality versions will do the job just as well.

Step 1: Rip your DVD / Blu-Ray With MakeMKV

First things first—you’ll need to rip your Blu-Ray to get a digital copy of the movie. MakeMKV is perfect for this because it focuses on one thing: creating a full-size 1080p or 4K MKV file from your Blu-Ray disc. Once the movie is ripped, you’ll have an MKV file that you can shrink, convert, or modify as needed. You can also watch it as-is, but compressing it later is a good idea to save space.

Here’s how to rip your Blu-Ray:

Insert the DVD or Blu-Ray disc into your Blu-Ray drive.
Open MakeMKV. After a few moments, you’ll see a large DVD or Blu-ray drive icon appear on the screen.
Click the icon to begin scanning the titles on your disc.

After MakeMKV scans the disc, you’ll see a list of titles on the left. This list includes everything on the disc, like the main movie, special features, deleted scenes, and other extras. If you only want the main movie, look for the largest track—usually around 20–30GB. Select the track(s) you want and leave out the rest. It might take a bit of trial and error to identify the right one, but the largest track is almost always the main movie.

On the right-hand side of the window, choose the folder where you want to save the MKV file. Make sure to pick a hard drive with plenty of space. Although the Info section shows an estimated file size, it’s smart to have at least 20GB of extra space available. Once everything is set, click the Make MKV button (the one with the green arrow) to start the ripping process.

MakeMKV will take about 20 to 30 minutes to rip your movie, depending on your drive speed and the size of the movie. You’ll see a green progress bar showing how far along it is. If you need to stop the rip for any reason, just click the orange stop icon to cancel the process.

Once the rip is complete, MakeMKV will show a pop-up confirming that it’s finished. You can safely eject the disc and, if needed, insert another one to start a new rip.

At this point, if you’re eager to watch your movie, you can open the MKV file with a media player like VLC, Plex, Kodi, or any other app that supports MKV files. If you’re not worried about saving hard drive space, you’re good to go!

However, if you want a cleaner, more organized, and space-efficient media library, the next step is to compress the file. We’ll cover that in the next section.

Step 2: Compress Your Rip to a Manageable Size with HandBrake

To compress your freshly ripped MKV file, open HandBrake and select File if you’re working on a single video. If you’ve got multiple rips to convert, you can choose Folder (Batch Scan) to scan several files at once. Don’t worry—this step only scans the files and gathers details about them, so it’s safe to select an entire folder containing all your rips. You’ll be able to decide how to convert each file individually later.

For this example, I’m going to keep it simple and drag and drop my new MKV file directly into HandBrake.

Next you will need to select the quality.

Choosing the Right Quality Settings in HandBrake

Now comes the tricky part: selecting the right quality settings for video compression. HandBrake offers a variety of presets that make it easier to balance video quality and file size. The best preset depends on how much detail you want to keep for each movie. For example:

For a visually stunning movie like Transformers: Rise of the Beasts, you’ll want to preserve every detail of the robot battles and special effects.
On the other hand, compressing Monty Python and the Holy Grail won’t lose much since it’s a low-budget comedy, and the humor doesn’t rely on high visual fidelity—those jokes are funny at any resolution!

With that in mind, here are three compression options tailored to different needs:

1. Ultra High Quality, UHD (4K)

Best for: Movies with detailed special effects, breathtaking visuals, or films where 4K resolution is crucial to the viewing experience.
Recommended Preset: Super HQ 2160p60 4K HEVC Surround
- This preset keeps the full 4K UHD resolution while compressing the file, significantly reducing its size without any noticeable loss in quality. It’s perfect for action-packed blockbusters, visually rich films, or nature documentaries where every detail counts.
Audio Tip: To maintain the original high-quality audio, go to the Audio tab and change the codec from “AAC” to “DTS Passthru,” “TrueHD Passthru,” or “AC3 Passthru,” depending on the source audio format. This keeps the audio as crisp and immersive as it was on the original disc.

2. High Quality, High Resolution (1080p)

Best for: Movies with detailed special effects, beautiful visuals, or films you want to keep looking sharp.
Recommended Preset: Super HQ 1080p30 Surround
- This preset keeps the full 1080p resolution while significantly reducing the file size without sacrificing much quality. It’s ideal for visually rich movies where you want to maintain detail without the massive file size of a full rip.
Audio Tip: To preserve the original audio quality, go to the Audio tab and change the codec from “AAC” to “DTS Passthru” or “AC3 Passthru,” depending on the disc’s original audio format.

3. High Quality, Lower Resolution (720p)

Best for: Movies where visuals aren’t as crucial or older films that don’t really benefit from high-definition resolution.
Recommended Preset: Super HQ 720p30 Surround or HQ 720p30 Surround
- Dropping from 1080p to 720p may sound like a big downgrade, but the difference is often barely noticeable—especially with a high-quality preset that uses minimal compression.
- This is a great option for comedies, older movies, or films where you’re not worried about preserving every tiny detail. A well-compressed 720p file can look better than an overly compressed 1080p version.

4. Low Quality, Lower Resolution (720p or Below)

Best for: Movies where saving space is the priority, and video quality isn’t a big concern.
Recommended Preset: Very Fast 720p30
- This setting drastically reduces file size, making it perfect for your “guilty pleasure” collection or movies you’re not worried about keeping in high quality. It’s the go-to choice when you need to maximize storage space.

What to Consider

Visual Importance: If the movie relies heavily on visuals (like sci-fi or action films), choose a higher-quality preset to preserve detail.
Storage Needs: For comedies, older films, or “background” movies, opting for lower resolution or quality presets can save a lot of hard drive space.
Case-by-Case Flexibility: The best part is you don’t have to use a one-size-fits-all approach. You can adjust the quality settings for each movie based on how much you value its visuals versus how much storage space you want to save.

Using these presets helps you find the right balance between quality and storage, so your media library looks great without wasting space.

For most people, the basic presets will work just fine, delivering a good mix of quality and file size. But if you’re comfortable with advanced settings and want more control, you can tweak options in the Video, Audio, and Subtitles tabs.

For example:

Video Tab:
- If the preset’s video quality isn’t high enough, adjust the RF (Rate Factor) to a lower value. The default is usually 18, but lowering it to 16 increases quality (at the cost of a larger file size).
- Change the Framerate setting from “30” to “Same as Source” to match the original framerate of your rip for smoother playback.

Don’t hesitate to experiment with these settings to find the perfect balance of quality and file size for your needs!

Choosing the Right Container: MP4 vs. MKV

Under the “Container” setting, you’ll need to choose between MP4 and MKV:

MKV is more flexible and feature-rich, supporting multiple audio tracks, subtitles, and slightly higher video quality. It’s a great choice for media servers and modern devices that support MKV playback.
MP4 is more universally compatible, especially with mobile devices like iPhones and iPads, as well as older hardware.

Choose MKV if you want maximum flexibility and quality, or MP4 if you need broader compatibility across different devices.

To decide, check the device you plan to use for playback (There is a table at the bottom of this post with the pros and cons of each ):

If your device supports MKV, choose MKV to take advantage of its features and superior quality.
If MKV isn’t supported, go with MP4 for maximum compatibility across different devices.

Pick the format that best fits your needs.

When you’re ready, click the green Start Encode button to begin the conversion. If you’re working with multiple rips, click Add to Queue after setting up the current video, then move on to the next title. Once you’ve configured presets for all your movies, click the green Start Queue button to process them all at once. This batch processing feature is a huge time-saver if you have several files to convert.

Once your files are done converting, you’ll notice they’re significantly smaller—how much smaller depends on the settings you chose. Make sure to play the converted files to check the quality. If everything looks good, you can safely delete the original rips to free up storage space. Your movies are now ready to be added to your media library, and you can start enjoying your collection!

Comparison Table: MP4 vs. MKV

Feature	MP4	MKV
File Size	Smaller, typically used for compressed files.	Larger, especially when storing lossless, uncompressed rips.
Quality	Often compressed, which may result in some loss of quality.	Supports lossless storage, retaining the full quality of video, audio, and subtitles.
Audio Tracks	Limited support for multiple audio tracks.	Fully supports multiple audio tracks (e.g., different languages, commentary tracks).
Subtitle Support	Limited; embedding multiple subtitle tracks can be tricky.	Excellent support for multiple subtitle tracks, including soft (toggleable) subtitles.
Compatibility	Universally supported across most devices and platforms, including older hardware.	Widely supported on modern media players, but not always natively compatible with older devices.
Advanced Features	Basic; lacks advanced features like chapter markers and high-end audio codecs.	Supports advanced features like chapters, menus, and high-resolution audio formats (e.g., DTS-HD, Dolby Atmos).
Ease of Use	Great for simple playback on most devices without any special configurations.	More feature-rich but may require specific software (e.g., Jellyfin, VLC, or Plex) for optimal playback.
Compression	Ideal for compressed files when storage space is limited.	Best for lossless files or preserving full-quality rips of DVDs/Blu-Rays.
Future-Proofing	Sufficient for standard-definition or compressed high-definition video.	Better suited for high-resolution formats (e.g., 4K UHD) and high-quality audio codecs.
Recommended Use Case	For smaller, portable files or when compatibility with older devices is required.	For archiving DVDs/Blu-Rays or building a high-quality media library.

Building Your Own Legal Media Collection

Wed, 25 Dec 2024 06:51:55 -0700

Building a home media server lets you create your own personal Netflix, but it’s important to stay within legal boundaries when adding shows and movies. Sure, you might be tempted to don your pirate hat and sail the high seas for content, but it’s crucial to understand the risks that come with that choice.

Legal Implications of Pirating Media

Civil Lawsuits: Copyright holders can sue individuals or entities that illegally distribute their content. These lawsuits often result in hefty financial penalties.

Criminal Charges: In serious cases—especially those involving large-scale piracy or financial gain—criminal charges can be filed, leading to significant fines and even jail time.

Statutory Damages: Under U.S. copyright law, penalties for infringement can range from $750 to $30,000 per work. If the court finds the violation was willful, that amount can shoot up to $150,000 per work.

Examples of Fines and Penalties

Recording Industry Association of America (RIAA) Lawsuits: In the mid-2000s, the RIAA filed thousands of lawsuits against people who illegally downloaded music through peer-to-peer networks. Settlements often ranged from a few thousand to several thousand dollars per person.

Movie Studios and Copyright Groups: Like the RIAA, movie studios and copyright enforcement groups have gone after individuals and piracy websites. Settlement amounts vary but typically cover lost revenue and legal fees.

High-Profile Case Examples:

BMG v. Cox Communications: In this landmark case, Cox Communications was found liable for copyright infringement by its users, resulting in a $25 million judgment in favor of BMG.

Capitol Records v. Thomas-Rasset: Jammie Thomas-Rasset was fined $222,000 for downloading and sharing 24 songs on Kazaa. After multiple appeals, the fine amount fluctuated but served as a cautionary tale about the high cost of piracy.

Legal Methods to Add Content to Your Media Server

Digital Marketplaces

Buy or rent movies and shows from platforms like Amazon Prime Video, Google Play Movies, and iTunes. Some allow offline downloads, but they’re typically DRM-protected, meaning you can’t easily move them to your media server. Always check the terms of service for DRM-free options.

Physical Media (DVDs and Blu-rays)

Buying physical DVDs and Blu-rays is a straightforward way to legally obtain content. You can use tools like MakeMKV and HandBrake to rip and compress them for your media server. This is generally legal for personal use, but be sure to check your local laws to stay compliant.

Public Domain and Creative Commons

Some movies and TV shows are in the public domain, meaning they’re free to use without permission. Websites like Public Domain Movies and the Internet Archive offer these films. Additionally, some creators release their work under Creative Commons licenses, allowing free legal distribution under specific conditions.

Special Offers and Bundles

Look for deals on digital marketplaces. Services like Humble Bundle sometimes offer digital movies and documentaries at pay-what-you-want prices, making it a cost-effective way to legally acquire content.

Free Streaming Services

Platforms like Pluto TV, Tubi, and Crackle offer free, ad-supported streaming. Although they typically don’t allow downloads, they’re a legal and free way to enjoy content. Some services offer temporary downloads for offline viewing.

Library Services

Platforms like Hoopla and Kanopy partner with local libraries to provide free streaming of movies and TV shows. You’ll need a library card from a participating library. Although you can’t download files directly to your server, these services expand your legal viewing options for free.

Second-Hand (Used) Media

Buying used DVDs and Blu-rays is a cost-effective and legal way to grow your collection. Here are some great places to find second-hand media:

Local Thrift Stores and Garage Sales

These are goldmines for finding DVDs and Blu-rays at low prices. You might even come across rare or out-of-print titles. Just make sure to check the discs for scratches before buying.

Online Marketplaces

Websites like eBay, Craigslist, and Facebook Marketplace are great for buying used media. You can often find large collections at reasonable prices. Make sure to check seller ratings and reviews for reliability.

Used Bookstores and Media Shops

Many used bookstores also sell DVDs and Blu-rays, often inspecting them for quality. Specialty shops focusing on used media also provide peace of mind by guaranteeing that the discs are in working order.

Library Sales

Sometimes libraries sell off older DVDs and Blu-rays to make room for new inventory. These sales are great for finding cheap movies while supporting your local library.

Tips for Buying Second-Hand Media

Inspect Before Buying: Check the disc for scratches or defects.
Check for Completeness: Make sure the original case, cover art, and inserts are included if they matter to you.
Be Patient: Finding specific movies can take time, so check regularly.
Negotiate: Especially at garage sales or on online platforms, negotiating can save you even more money.

Once you’ve bought your second-hand media, you can rip the content using MakeMKV and compress it with HandBrake if needed. This gives you a legal, personal collection for your media server.

Best Practices

Always Check the License: Make sure any digital content is either DRM-free or that you’re allowed to convert it for personal use.

Stay Informed: Copyright laws vary by country and can change, so stay up to date on what’s legal in your area.

Support Creators: Buying content directly from creators or through official channels ensures they get compensated, helping to sustain the industry and encourage more great content.

By following these guidelines, you can build an impressive and legal collection for your home media server. Remember, the goal isn’t just to gather a massive library—it’s about curating and organizing your collection, discovering new favorites, and revisiting classics while respecting copyright laws and supporting the creators you love.

Embark on the Ultimate Home Media Journey

Fri, 20 Dec 2024 06:10:50 -0700

Are you tired of scrolling through endless streaming services only to find that your favorite show has disappeared? Or maybe you’re concerned about privacy and how these platforms handle your data? If you’ve ever dreamed of having a personalized entertainment hub where all your media lives in one place—accessible anytime without the prying eyes of subscription services—then you’re in the right spot.

Whether you’re a seasoned tech enthusiast or just curious about getting started, my mission is to guide you through the process with ease. We’ll dive into setting up and fine-tuning your home media server, transforming the way you store, access, and enjoy your digital media library.

What is a Home Media Server?

A home media server is a dedicated computer or Network Attached Storage (NAS) device that stores all your digital media—movies, music, photos, and more. It acts as a central hub on your home network, letting you organize, stream, and share your media across multiple devices. Unlike streaming services that host content on remote servers, a home media server gives you complete control over your collection, allowing offline access, no subscription fees, and the freedom to customize your setup however you like.

Why Set Up a Home Media Server?

Centralized Storage: Keep all your media in one place instead of having files scattered across different devices like phones, laptops, and external drives. This makes it much easier to organize, access, and back up your content.

Stream Anywhere in Your Home: With a home media server, you can stream your content to any device on your network, from smart TVs and smartphones to tablets and computers. You’re not limited by the file formats supported by popular streaming services since you can transcode (convert) files to work with any device.

Customization and Control: You decide how your media is organized, displayed, and accessed. Set up user profiles, parental controls, and more. Plus, you’re not subject to the changing catalogs or restrictions of streaming platforms.

Cost-Effective: After the initial setup (which can vary depending on your choices), running a home media server is extremely cost-effective. There are no monthly fees unless you choose to pay for specific premium services or apps.

Offline Access: Because your content is stored locally, you can access your media even when the internet is down. Your entertainment is always at your fingertips.

Building a home media server can be as simple or as complex as you want. Whether you’re repurposing an old computer or Raspberry Pi with external hard drives or setting up a dedicated NAS with advanced media management software, the journey is rewarding and a great way to learn more about networking, Linux, and digital media management.

My Mission: Making Home Media Servers Accessible

Over the past 15 years, I’ve gained a lot of knowledge on this topic, and my goal is to share that experience in a way that’s easy to understand and follow. From picking the right hardware to choosing the best software for your needs, I’ll provide step-by-step guides, useful tips, and my best practices to help you build a media server that meets your expectations.

Are my methods the only or absolute best way to do things? Maybe not—but they work, and the beauty of building your own media server is that you can tailor everything to fit your unique needs.

Easy to Read, Easy to Understand

I’ll break down complex technical concepts into easy-to-digest bits. I’ll translate jargon into plain English, ensuring everything is clear, concise, and practical. Whether it’s understanding the basics of networking or diving into the specifics of media server software, I’ll make sure the information is accessible and straightforward.

Flattening the Learning Curve

I still remember my first attempt at setting up a home media server—the steep learning curve almost made me quit. But don’t worry. I’ve been through all the challenges, and my goal is to make your journey much smoother. By breaking the process into clear, logical steps and addressing common questions upfront, I want to give you the confidence to tackle this project successfully.

Let’s Get Started!

In upcoming posts, we’ll cover everything from setting up a home media server using platforms like Linux, Proxmox, and Docker to optimizing your setup with apps like Jellyfin for media management and Kodi for playback. We’ll dive into using the Arr suite for automated media management, how MergerFS can simplify your storage strategy, and the benefits of Usenet for content acquisition.

This journey is about taking control of your digital media experience, protecting your privacy, and enjoying the satisfaction of a DIY tech project. Whether you’re aiming for a simple setup to stream your movie collection or a sophisticated server with all the bells and whistles, I’m here to guide you every step of the way.

Stay tuned, and let’s embark on this exciting adventure together!

About Me

Mon, 01 Jan 0001 00:00:00 +0000

So you want out of Big Streaming and their constant price increases? Good. You’re in the right place.

I’m Steve - online, you’ll find me as KryptikWurm, and I’ve been building, breaking, and rebuilding home media servers since before most people knew what Kodi, Jellyfin, and Plex were. This blog is the cheat sheet I wish I had when I started. No fluff. Just real-world homelab advice from someone who’s been in the trenches.

It all started in 2010. Cable TV sucked. Streaming was a mess. I wanted a clean setup where my media actually worked for me. So I built it. Then I rebuilt it. Then dockerized it. Then Proxmoxed LXC’d it. Then dockerized it again. And now? It runs like a dream (mostly).

This site exists so you don’t have to make the same mistakes I did. Or at least not all of them.

What This Blog’s Really About

DIYMediaServer is your blueprint for ditching the noise and building a home media empire that’s:

Private
Powerful
Fully under your control

I cover everything from the essentials to the edge cases:

Proxmox and virtualized media stacks
Docker, containers, and self-hosted apps
Plex, Jellyfin, and the full Arr suite
Usenet, torrents, and automation
Storage strategies with MergerFS, SnapRAID, and ZFS
Networking, VPNs, and remote access, without selling your soul to Google

If you’ve ever screamed at Snap for breaking your stack or sat through a 3AM “why won’t Sonarr start” panic, welcome. You’ve found your people.

My Philosophy

Keep It Simple, Stupid.

You don’t need enterprise gear or 12 certs to run a killer setup. You need the right tools, some guidance, and a system that makes sense for your life.

I’m not here to sell you on “one right way.” I’m here to help you find your way and ensure you don’t throw a perfectly good computer out the window in the process.

Why I Built This

Because I spent way too many hours piecing together forums, Reddit rants, and YouTube half-truths. I wanted a place that cut through the noise. A place that teaches real solutions, not just dry how-tos. This is that place.

Whether you’re setting up your first NAS or refining your 12-container media stack, my goal is simple: Help you take control, avoid landmines, and enjoy the ride.

Join the Mission Got a better way to run Sonarr in Docker? Want to nerd out about BTRFS vs. ZFS? Cool. This site isn’t just me on a soapbox—it’s a community of digital tinkerers who actually use their setups and aren’t afraid to break stuff along the way.

Let’s build smarter. Let’s build together.

Search

Mon, 01 Jan 0001 00:00:00 +0000