On this page
For the first month I owned a NAS, it did exactly one job: it held files. It sat on the shelf, quietly serving one folder, while my cluster backed up to nowhere and my media server streamed off a USB drive. The box that was supposed to be the backbone of my homelab was, functionally, a very expensive external drive with an Ethernet port.
This is the guide I wish I’d had that month. A NAS earns its keep doing four jobs at once — serving shared storage into Proxmox VE, catching your backups every night, feeding your media server, and pushing one copy of everything out of the building. We’ll wire up all four.
If you’re still deciding which NAS — commercial box, DIY build, or a share served from Proxmox itself — start with What Is a NAS? and come back. And if you’d rather build the file server as a container on Proxmox instead of buying a separate box, that whole path is covered in Shared Storage for Your Homelab. This post assumes the NAS already exists on your network and gets straight to the wiring.
Before you start
You’ll need:
- A NAS on the same network as your Proxmox host, with an IP you know (mine will be
10.0.0.10throughout) - Admin access to the NAS’s web interface
- Root shell access on your Proxmox host
Every value below that looks specific to one machine is a placeholder, not a literal to copy. Swap in your own before running anything: 10.0.0.10 (the NAS IP), 10.0.0.0/24 (the lab subnet), /volume1/lab and /volume1/media (NAS export paths — Synology-style here; a TrueNAS pool looks like /mnt/tank/lab), nas-backup and nas-media (storage names — pick anything), 101 (the container ID), youradmin (the NAS username), and offsite-box (the offsite machine’s Tailscale hostname). Rule of thumb: if a value looks specific to one machine, it’s a placeholder to change.
Job 1: Share the NAS into Proxmox
The first job is making the NAS visible to Proxmox as storage. Proxmox speaks two share protocols natively: NFS (Network File System — the Linux-native way to share folders over a network) and SMB (the Windows-native protocol, also called CIFS; Microsoft’s own overview is the canonical reference). Between two Linux-speaking machines — and your NAS is a Linux machine in a nice case — NFS is the simpler choice, so that’s what we’ll use.
In your NAS’s web interface, create a shared folder for lab use (I call mine lab) and enable the NFS service. Then edit the share’s NFS permissions so your Proxmox hosts are allowed to mount it: grant read/write access to your lab subnet (10.0.0.0/24) or to each host IP individually. Every NAS brand buries these switches somewhere different — on Synology DSM it’s under Shared Folder → Edit → NFS Permissions; TrueNAS calls them Shares → UNIX (NFS) Shares.
If your NAS is a DIY Linux box, the same thing is one line in /etc/exports — the format is an export path followed by who may mount it, per the exports(5) man page:
echo '/volume1/lab 10.0.0.0/24(rw,sync,no_subtree_check)' >> /etc/exports
exportfs -ra
rw allows writes, sync makes the NAS confirm data actually hit disk before acknowledging it (slower, safer — what you want for backups), and no_subtree_check disables a legacy check the man page itself says “tends to cause more problems than it is worth.” exportfs -ra re-reads the file and applies it.
One gotcha worth knowing in advance: NFS servers often “squash” root by default — requests from root get remapped to an anonymous user, which is sensible on a corporate file server and a nuisance here, because Proxmox connects as root to create its directory layout. If Proxmox throws permission errors in the next step, find your NAS’s squash setting for this export and allow root, or grant the mapped user write access.
Over on the Proxmox side, first ask the NAS what it’s offering — a quick sanity check that the export and permissions actually took:
pvesm scan nfs 10.0.0.10
You should see /volume1/lab in the output. Now add it as storage — one command, and because storage definitions are cluster-wide, every node picks it up at once:
pvesm add nfs nas-backup --path /mnt/pve/nas-backup --server 10.0.0.10 --export /volume1/lab --content backup,iso,vztmpl --options soft
The --content list declares what this storage may hold: backup for vzdump backup files, iso for installer images, vztmpl for container templates. The --options soft flag is the Proxmox NFS storage docs’ own recommendation — it limits retries when the NAS is unreachable instead of letting processes hang forever waiting on a dead mount.
Prefer clicking? The same form lives at Datacenter → Storage → Add → NFS, and it’s the exact same fields:
The share now appears in the sidebar of every node, mounted under /mnt/pve/nas-backup. If your household leans on Windows shares, the SMB/CIFS storage type is one command in the same shape — pvesm add cifs nas-backup --server 10.0.0.10 --share lab --username youradmin --password — and Proxmox stores the password in a file only root can read. For the bigger picture of how NFS storage compares to local-lvm and ZFS, and which content should live where, the Proxmox Storage Guide goes deep.
Job 2: Point your backups at it
A separate box whose whole job is holding data is the natural first home for backups. Now that Proxmox can see it, this job is almost embarrassingly short — and its payoff, the first time a container dies, is enormous.
Before scheduling anything, prove the path works with a single backup. vzdump is Proxmox’s built-in backup tool (docs here) — point it at a small container and at the new storage:
vzdump 101 --storage nas-backup --mode snapshot
--mode snapshot backs the container up while it keeps running — the lowest-downtime mode. When it finishes, the backup file is sitting on the NAS under dump/, and you can see it in the web UI by clicking the storage.
In the web UI: Datacenter → Backup → Add. Pick the nas-backup storage, select all guests, choose a nightly schedule and snapshot mode, and set a retention policy so old backups get pruned automatically instead of quietly filling the NAS. That’s the whole job — from tonight onward, every container and VM you run lands on the NAS while you sleep.
Two honest caveats. First, a scheduled backup you’ve never restored is a hope, not a plan — I’d nudge you to at least click through one test restore this week (more on that at the end). Second, vzdump writes complete images every night; it’s simple and robust, but it doesn’t deduplicate. When your backups outgrow that, Proxmox Backup Server adds deduplication and incremental transfers — and the NAS keeps its role, just one layer further back.
Job 3: Feed your media server
Media is where a NAS shines: terabytes of files that need to be available, not fast. The wrinkle is that your media server probably runs in an unprivileged LXC container, and unprivileged containers can’t mount network shares themselves — that privilege stays with the host. The pattern that works — and the one the Proxmox container docs point to — is a relay: the Proxmox host mounts the share, then passes the folder into the container as a bind mount (a way of making one directory visible at a second path, no network involved).
Create a media share on the NAS the same way you made lab in Job 1, then mount it on the Proxmox host with an entry in /etc/fstab so it survives reboots:
mkdir -p /mnt/nas-media
echo '10.0.0.10:/volume1/media /mnt/nas-media nfs defaults,_netdev 0 0' >> /etc/fstab
mount -a
df -h /mnt/nas-media
The _netdev option marks this as a filesystem that needs the network, so the system won’t try to mount it before networking is up (it’s documented in mount(8)). The df check at the end should show the NAS’s capacity — if it shows the host’s root disk instead, the mount didn’t take.
Now hand the folder to the container. One command on the host, with the container’s ID:
pct set 101 -mp0 /mnt/nas-media,mp=/mnt/media
Restart the container, and /mnt/media inside it is the NAS’s media folder. Point your media server’s library there and you’re done — Plex and Jellyfin both treat it as a local folder. If you haven’t set one up yet, I’ve got full guides for Plex and Jellyfin.
One thing may bite: in an unprivileged container, user IDs are shifted — root inside the container is not root outside, so files can show up owned by nobody. For a media library the clean fix is on the NAS side: make the media files world-readable (they’re not secrets), and give write access to the one user your *arr stack or downloader actually runs as.
Job 4: Get one copy out of the building
Here’s the uncomfortable truth about Jobs 1 through 3: everything so far lives at one street address. A fire, a flood, a lightning strike, or a burglar takes out the cluster and the NAS in the same afternoon. That’s why CISA’s backup guidance pushes the 3-2-1 rule: three copies of anything important, on two different media, with one offsite.
You already have copies one and two: the live data on your cluster, and last night’s vzdump files on the NAS. The third copy is a sync job from the NAS to somewhere else — a small box at a family member’s house, a machine at the office, or cloud storage. The venerable tool for the first two is rsync, which copies only what changed:
rsync -az --delete /volume1/backups/ youradmin@offsite-box:/backups/lab/
Per the rsync man page: -a preserves permissions and timestamps, -z compresses in transit, and --delete makes the far side a true mirror by removing files you’ve deleted locally. Run it from your NAS’s scheduler (every mainstream NAS OS has one) or from a small container, nightly, an hour or two after the backup job finishes.
The easiest way to reach a machine in another building without opening ports is Tailscale — I covered the setup in the subnet router guide, and the offsite-box name above is the kind of stable address Tailscale gives every machine, wherever it lives. And a hard-won note from my own lab: when my offsite sync crawled at a tenth of the speed it should have, the culprit was a single kernel buffer setting — that hunt is its own story, and worth a read before you blame your internet connection.
What’s next
Your NAS now has all four jobs: it serves shares to the cluster, catches every guest’s backup nightly, feeds your media server, and ships a copy out of the building. The single highest-value next step is proving the loop closes: pick one backup on the NAS and restore it. A backup you’ve never restored is a guess — here’s how I measured mine, including the surprises.
Related posts:
- Paperless-ngx: OCR Every Document You Own, Searchable — a searchable document archive is a natural NAS resident
- SMART Disk-Health Trending for Your Whole Fleet — trend the health of the NAS bays your data lives on
- Home Assistant on a NAS: Why Placement Beats Hardware — put your always-on smart-home hub on the NAS — why site, not specs, decides
- What Is a NAS? (And Which Kind Your Homelab Actually Needs) — choosing the box this guide plugs in
- Shared Storage for Your Homelab: Samba and NFS Done Right — the DIY route: build the file server on Proxmox itself
- Proxmox Storage Guide: local-lvm, ZFS, NFS — how NAS storage fits among Proxmox’s storage backends
- The 99% Root Disk: Common Homelab Storage Issues and Fixes — the on-node storage crises that make an off-node backup target so attractive
- Proxmox Backup Server — the deduplicating upgrade to the vzdump job from this post
- How Fast Can You Actually Restore a Proxmox Backup? — proving the backups on your NAS actually come back
- Install Plex on a NAS or Proxmox LXC — the media server on the receiving end of Job 3
- Install Jellyfin on a NAS or Proxmox LXC — same job, free-software route
Recommended hardware for this setup:
- Synology DS224+ 2-bay NAS — the “it just works” pick; everything in this post works from its web UI
- UGREEN NASync DXP2800 — stronger hardware per dollar if you’re happy tinkering
- WD Red Plus 8TB NAS drive — CMR NAS-rated drive for the bays
- Seagate IronWolf 8TB — the other safe default; buy whichever is cheaper that week
Sources: Proxmox VE — Storage: NFS, Proxmox VE — Storage: CIFS, Proxmox VE — Linux Container, pvesm(1), vzdump(1), exports(5), rsync(1), CISA — Data Backup Options.
This post contains Amazon affiliate links (tag: buildahomelab-20). I earn a small commission on qualifying purchases at no extra cost to you.
Comments
Comments are powered by GitHub Discussions — sign in with a GitHub account to join the conversation.