Proxmox NAS: Build a ZFS Pool with SMB and NFS Shares

Turn a Proxmox VE node into a real home NAS by storing your files on ZFS datasets and serving them over SMB and NFS from a lightweight container — no separate TrueNAS box needed. This guide walks through building the pool, laying down the datasets, picking the right share protocol, and the specific ZFS mistakes that leave homelabbers with a slow pool or data they cannot recover.

Key Takeaways

• Pool layout: Choose a vdev shape (mirror or RAIDZ) up front because ashift and the number of disks are fixed the moment you create the pool.
• Dataset hygiene: Split documents, media, and backups into separate datasets so you can snapshot, reserve, and share each one independently.
• Share protocol: Use NFS for Linux clients and low overhead, SMB when Windows and macOS machines need to connect.
• Snapshots: Schedule daily ZFS snapshots and replicate them off-node before you ever need to roll back a bad delete or ransomware.
• UID mapping: In an unprivileged LXC, container root maps to host UID 100000, so plan ownership now or your shares will look wrong later.

Why Proxmox and ZFS for a home NAS

Running a NAS inside Proxmox VE 8 keeps everything on one box: your VMs, your containers, and your file shares all pull power and network from the same machine, which is exactly what most homelabs want. ZFS gives you datasets, compression, snapshots, and checksumming for free, which is hard to match with a plain ext4 partition and a Samba install.

If you are brand new to ZFS here, start with our overview of pools and datasets on Proxmox to get the mental model right before you run any commands.

The one thing to decide first is whether this pool should also host VMs. For a pure NAS, keep VM storage separate so a full disk never starves your operating system guests. If you do want to run VMs off the same pool, read the ZFS vs LVM-thin comparison to understand the backup and performance tradeoffs.

For this post I will build a dedicated pool purely for file data.

How to design the ZFS pool and datasets

Pick a vdev layout

Your vdev shape sets the rules for the life of the pool:

• Two disks: a mirror gives you fault tolerance and fast random I/O, at the cost of 50% capacity.
• Three or more disks: raidz1 tolerates one disk failure, raidz2 tolerates two, but each parity level costs you more usable space.

A common homelab starting point is a RAIDZ1 pool of four 4 TB drives, which leaves about 12 TB usable. That is a comfortable middle ground between a mirror (cheap but small) and RAIDZ2 (safer but you give up another whole disk).

Set the pool with the right flags

The single most irreversible decision is ashift, which must match your drive sector size. Use ashift=9 for 512-byte-native drives and ashift=12 for 4Kn or 512e drives. Get it wrong and you cannot change it later without recreating the pool.

zpool create -o ashift=12 \
  -O compression=lz4 \
  -O atime=off \
  -O mountpoint=/znas \
  znas raidz1 /dev/sdb /dev/sdc /dev/sdd /dev/sde

The -O flags set dataset properties on the pool root, so every child dataset inherits lz4 compression and disabled access times. Compression on is a no-brainer for a NAS: on mixed documents and media you will typically see 1.5–2:1, which effectively stretches that 12 TB to roughly 18–24 TB of logical data.

Split data into datasets

Do not dump everything into the pool root. Create one dataset per category so you can snapshot, share, and reserve space independently:

zfs create znas/documents
zfs create znas/media
zfs create znas/backups
zfs set reservation=100G znas/documents

Each dataset now lives under /znas/ on the host and inherits the pool's compression and atime settings automatically. The reservation on documents guarantees your important files space even if the media dataset fills up.

Tune the properties

The knobs you set here overlap with the ones in our Proxmox ZFS tuning guide, so the principles are identical whether you are tuning for VMs or for file shares:

zfs set compression=lz4 znas/documents
zfs set atime=off znas/documents
zfs set recordsize=128k znas/documents
zfs set recordsize=1m znas/media

Smaller recordsize suits random-access document storage; larger records suit big sequential media files. These are per-dataset, so you can tune each share to what it actually holds.

How to expose your data over SMB and NFS

Proxmox does not serve network shares itself, so you run an SMB or NFS server inside an LXC (or a small VM) that can see the /znas pool. The server talks to your laptop and phones over the LAN; ZFS does the storage.

SMB and NFS solve the same problem differently, and the right choice depends mostly on who is connecting:

Concern	SMB (Samba)	NFS
Best for	Windows and macOS clients	Linux/Unix clients and VM backing stores
Permissions	NTFS-style ACLs	POSIX UID/GID
Typical port	TCP 445	UDP/TCP 2049
File locking	Mature and forgiving	Needs NLM and careful caching
Network overhead	Higher	Lower

NFS: the low-overhead option

NFS is the natural choice when your clients are Linux machines, containers, or VMs. You install the kernel NFS server in the share LXC and add an entry to /etc/exports:

/znas/media    192.168.1.0/24(rw,sync,no_subtree_check)
/znas/documents 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

Then reload the exports:

exportfs -ra

The sync option here is worth a closer look, and it ties directly into the SLOG discussion below. no_root_squash lets a root client write as root on the share — convenient on a trusted home LAN, but it means any compromised client account can write anywhere. Drop it if you want stricter isolation.

SMB: the universal option

SMB works everywhere a file explorer does, which is why it is the default for mixed households. Install Samba in the share LXC and define your shares in /etc/samba/smb.conf:

[documents]
    path = /znas/documents
    browseable = yes
    read only = no
    valid users = homelab
    create mask = 0664
    directory mask = 0775

[media]
    path = /znas/media
    browseable = yes
    read only = yes
    valid users = homelab

Create the login account and restart the services:

smbpasswd -a homelab
systemctl restart smbd nmbd

Mount the pool into the share container

The share LXC needs a path to the pool. Add a bind mount in the container options, or edit the config directly:

mp0: /znas, mp: /znas

That gives the container the whole pool under /znas, from which each share points at its own dataset.

The UID mapping gotcha

Here is the mistake that trips up the most people: in an unprivileged LXC, container root is not host root. It maps to host UID 100000, so any file Samba or NFS creates shows up on the pool as 100000:100000. That is harmless for a single-user lab, but it gets confusing fast if you also store Proxmox VM files on the same box.

The pragmatic fixes are to run the share container privileged so host and container root line up, or to chown the datasets to a UID you control and run the services as that user:

chown -R 1000:1000 /znas/documents

Pick one approach and apply it to every dataset before you start writing real data.

The ZFS-on-Proxmox mistakes that bite homelabbers

Beyond the UID trap above, a handful of ZFS choices quietly degrade a NAS over time.

Forgetting to disable atime. Access times update on every read and turn into write traffic. I set atime=off at pool creation precisely because re-creating a pool to fix it later is wasteful.

Enabling dedup without RAM. Dedup can halve space for highly duplicate data, but it needs roughly 5 GB of RAM per TB of stored data and can crater performance when you run out. Unless you have spare RAM and a dedup-heavy workload, skip it and lean on compression instead.

Wrong ashift. Covered above, but it bears repeating: a mismatched ashift leaks space and slows writes, and the only cure is to destroy and rebuild the pool.

Running VMs off the NAS pool. A VM doing a backup or a media transcode can saturate the pool and make your file shares feel sluggish. Keep VM storage on its own vdev or pool when you can.

Leaving sync in a bad state. The default sync=standard is fine for most file sharing. If you serve databases over NFS with synchronous writes and flip to sync=always, you will feel the pain without a SLOG — I have seen NFS write latency jump from a few milliseconds to tens of milliseconds on a large pool with no dedicated ZIL. A small NVMe as a SLOG brings it back under 5 ms, but that is a device you must budget for up front.

How do I keep your NAS data safe?

Snapshots are ZFS's superpower and they are essentially free because of copy-on-write. Create one and you can roll a dataset back in seconds:

zfs snapshot znas/documents@daily-2024-06-01
zfs list -t all -o name,creation -s name | grep znas/documents

Roll it back when you need to:

zfs rollback znas/documents@daily-2024-06-01

Snapshots only protect you locally, so schedule them and push copies off-node. A simple cron job keeps a week of daily snapshots and prunes the old ones:

30 1 * * * root zfs snapshot znas/documents@daily-$(date +\%F); zfs destroy -d znas/documents@daily-$(date -d '8 days ago' +\%F) 2>/dev/null || true

For a second copy on another node or a spare pool, use zfs send and zfs receive. This is the same stream-and-restore technique from our ZFS replication guide, and it is far faster and more reliable than copying files over the network:

zfs send znas/documents@daily-2024-06-01 | zfs receive -d znas-backup

If you already run Proxmox Backup Server for your VMs, you can point its filesystem backup at the datasets too, which gives you versioned, deduplicated, off-node copies alongside everything else. Pair that with a scheduled sync job and you have a recovery path that survives a lost disk or a ransomware hit.

Conclusion

With a RAIDZ1 pool, a handful of datasets, and an SMB or NFS server in a container, a single Proxmox node handles both your workloads and your home file storage without an extra box. The pay-off is real, but it depends on getting the pool flags, dataset boundaries, and UID mapping right before you load it with data. Your next step: build the pool on a spare set of drives, take one snapshot, and verify you can roll it back before you move anything important onto it.