If you've tried to set up a Proxmox Backup Server (or any other service) in an Incus container on TrueNAS SCALE 25.10 and attempted to mount an NFS share, you've likely encountered this frustrating error:
mount.nfs: mount(2): Operation not permitted
mount.nfs: Operation not permitted
This happens because Incus containers, like most container technologies, run with restricted security permissions by default. These restrictions prevent containers from performing privileged operations like mounting filesystems even when you're running as root inside the container.
Understanding the Setup
TrueNAS SCALE 25.10 introduced an experimental "Containers" feature under the Virtualization menu. Unlike the older Jails system or VM-based solutions, this feature uses Incus (the community-maintained fork of LXD) to manage lightweight system containers.
While containers are more efficient than VMs, they share the host kernel and have security restrictions in place. This is where our NFS mounting problem originates.
Why Run PBS on TrueNAS?
There are two main scenarios for running PBS in a TrueNAS container:
Best Practice (Recommended): Running PBS on a secondary TrueNAS to back up a primary TrueNAS or other infrastructure. This provides proper hardware separation while avoiding ZFS-on-ZFS inefficiency. PBS uses the secondary TrueNAS's ZFS storage directly via bind mounts.
Alternative Approach: Running PBS on the same TrueNAS you're backing up. While less ideal due to single-point-of-failure concerns, this avoids the performance issues of ZFS-on-ZFS. If PBS created its own ZFS pool on top of TrueNAS's ZFS, it would cause:
- Double checksumming overhead
- Duplicated memory caching (ARC)
- Unnecessary performance degradation
- Wasted resources
In both scenarios, the goal is to let PBS use TrueNAS's native ZFS storage directly, avoiding layered ZFS filesystems.
3 ways
There are actually three approaches to solve this and they're not all equal. For Proxmox Backup Server on TrueNAS, there's a clear winner.
Method 1: Direct ZFS Bind Mount (BEST for PBS on TrueNAS)
This is the optimal solution when running PBS on TrueNAS. Instead of using NFS (which adds network stack overhead even locally), bind mount a ZFS dataset directly into the container. This gives you:
- ✅ Native ZFS performance - no network overhead
- ✅ No ZFS-on-ZFS inefficiency
- ✅ Direct access to TrueNAS storage features
- ✅ Better security (no need to weaken container isolation)
Step 1: Create a Dedicated ZFS Dataset
On your TrueNAS server, create a dataset specifically for PBS backups:
# Replace 'tank' with your actual pool name
sudo zfs create tank/PBS-Backups
# Set a clean mount point
sudo zfs set mountpoint=/mnt/tank/PBS-Backups tank/PBS-Backups
# Optional: Set compression and other ZFS properties
sudo zfs set compression=lz4 tank/PBS-Backups
sudo zfs set atime=off tank/PBS-Backups
Step 2: Stop the Container
sudo incus stop PBS01
Step 3: Verify the Actual Mountpoint
Before adding the bind mount, verify where ZFS actually mounted the dataset:
# Check the actual mountpoint
sudo zfs get mountpoint tank/PBS-Backups
# Verify the directory exists
ls -la /mnt/tank/PBS-Backups
Important: If the mountpoint shows an unexpected path (like /mnt/mnt/tank/PBS-Backups with a double /mnt), use whatever path actually exists. You can fix it later if needed:
# If the mountpoint is wrong, fix it:
sudo zfs unmount tank/PBS-Backups
sudo zfs set mountpoint=/mnt/tank/PBS-Backups tank/PBS-Backups
sudo zfs mount tank/PBS-Backups
Step 4: Add the Dataset as a Bind Mount
Use the actual mountpoint from Step 3:
# Use the ACTUAL path where the dataset is mounted
sudo incus config device add PBS01 backup-storage disk \
source=/mnt/tank/PBS-Backups \
path=/mnt/datastore
If you got an error about "Missing source path", double-check that you're using the exact path from zfs get mountpoint.
This creates a direct bind mount - no NFS, no extra layers, just the raw ZFS dataset accessible inside the container.
Step 5: Start the Container
sudo incus start PBS01
Step 6: Configure PBS
Inside the PBS container (or via the web UI), configure your datastore to use /mnt/datastore as a directory-based datastore (NOT ZFS-based, since the ZFS management happens on the TrueNAS host).
Why This Method is Best:
When you use NFS, even to localhost (127.0.0.1 or the host IP), your data flows like this:
PBS Container → NFS Client → Network Stack → NFS Server → Filesystem → ZFS
With a bind mount, it's simply:
PBS Container → Filesystem → ZFS
No network overhead, no NFS daemon, no unnecessary serialization/deserialization of data.
Method 2: Enable NFS Mounting Inside the Container (If You Must Use NFS)
This method modifies the container's security profile to allow NFS mounting directly inside the container. While it reduces isolation, it's often necessary for backup solutions and similar services.
Step 1: Stop the Container
First, SSH into your TrueNAS server and stop the container:
sudo incus stop PBS01
Replace PBS01 with your container name. You can list all containers with:
sudo incus list
Step 2: Configure Container Security Settings
Now we need to adjust three security settings:
# Allow privileged operations
sudo incus config set PBS01 security.privileged true
# Enable nesting for additional capabilities
sudo incus config set PBS01 security.nesting true
# Disable AppArmor restrictions and allow necessary capabilities
sudo incus config set PBS01 raw.lxc "lxc.apparmor.profile=unconfined
lxc.cap.drop=
lxc.mount.auto=proc:rw sys:rw"
Let's break down what each setting does:
- security.privileged true: Allows the container to perform operations normally restricted to the host
- security.nesting true: Enables running nested containers and additional kernel features
- raw.lxc: Passes raw LXC configuration directives, including:
lxc.apparmor.profile=unconfined: Disables AppArmor restrictionslxc.cap.drop=: Doesn't drop any Linux capabilitieslxc.mount.auto=proc:rw sys:rw: Allows read-write access to proc and sys filesystems
Step 3: Start the Container
sudo incus start PBS01
Step 4: Install NFS Client
Enter the container and install the necessary NFS utilities:
sudo incus exec PBS01 -- bash
apt update
apt install nfs-common
Step 5: Mount the NFS Share
Now you can mount your NFS share. First, create the mount point if it doesn't exist:
mkdir -p /nfs/Backups
Then mount the share:
mount -t nfs 192.168.0.174:/mnt/DATA/BACKUP /nfs/Backups
Replace the IP address and path with your NFS server details.
Step 6: Make It Persistent
To ensure the NFS share mounts automatically after container restarts, add it to /etc/fstab:
echo "192.168.0.174:/mnt/DATA/BACKUP /nfs/Backups nfs defaults 0 0" >> /etc/fstab
You can verify it works by unmounting and testing:
umount /nfs/Backups
mount -a
df -h | grep Backups
Method 3: NFS Bind Mount from Host (Alternative Secure Approach)
If security is a higher priority, you can mount the NFS share on the TrueNAS host and then bind mount it into the container. This keeps the container more isolated.
Step 1: Mount NFS on TrueNAS Host
# Create mount point on host
sudo mkdir -p /mnt/nfs-backup
# Mount the share
sudo mount -t nfs 192.168.0.174:/mnt/DATA/BACKUP /mnt/nfs-backup
# Make it persistent in /etc/fstab
echo "192.168.0.174:/mnt/DATA/BACKUP /mnt/nfs-backup nfs defaults 0 0" | sudo tee -a /etc/fstab
Step 2: Add Bind Mount to Container
# Stop the container
sudo incus stop PBS01
# Add the bind mount
sudo incus config device add PBS01 nfs-backup disk source=/mnt/nfs-backup path=/nfs/Backups
# Start the container
sudo incus start PBS01
Now /nfs/Backups inside the container will show the NFS share contents, but the actual mounting happens at the host level.
Verification
Once everything is set up, verify your storage is working correctly:
For Method 1 (ZFS Bind Mount):
# Inside the container
df -h | grep datastore
ls -la /mnt/datastore
# You should see it as a regular directory, not an NFS mount
# Check ZFS dataset on the host
sudo zfs list | grep PBS-Backups
For Methods 2 & 3 (NFS):
# Inside the container
df -h | grep Backups
mount | grep nfs
ls -la /nfs/Backups
# You should see it listed as an NFS mount
Security Considerations
The three methods have very different security profiles:
Method 1 (Direct ZFS Bind Mount):
- ✅ Best security - no container isolation weakening required
- ✅ Container runs with default security settings
- ✅ No privileged mode or capability modifications needed
- This is the recommended approach for PBS on TrueNAS
Method 2 (NFS in Container):
- ⚠️ Reduces container isolation significantly
- AppArmor protection is disabled
- Container can perform privileged operations
- Only use this if you specifically need NFS and can't use bind mounts
- Acceptable for trusted workloads but avoid for untrusted applications
Method 3 (NFS Bind Mount):
- ✅ Better security than Method 2
- Container doesn't need elevated privileges
- NFS mounting happens at host level
- Still adds NFS overhead but keeps container isolated
The Ideal Setup
For production environments, PBS should ideally be:
- On physically separate hardware ✅
- In a different location (even a different room helps) ✅
- On a different network segment
- Not sharing any infrastructure with what it's protecting ✅
Real-World Example: Two-TrueNAS Architecture
Here's a practical example of the recommended setup:
Primary TrueNAS (192.168.0.10):
- Hosts Proxmox VMs or stores production data
- Serves data via NFS shares
- This is what you're protecting
Secondary TrueNAS (192.168.0.20):
- Runs PBS in an Incus container
- PBS datastore uses local ZFS (via bind mount - Method 1)
- PBS connects to primary TrueNAS via NFS to pull backup data
- Physically separate hardware, ideally in different location
Backup Flow:
1. PBS on secondary TrueNAS pulls data from primary TrueNAS via NFS
2. PBS stores deduplicated, compressed backups on secondary TrueNAS's ZFS
3. No ZFS-on-ZFS (PBS uses directory-based datastore on bind-mounted ZFS)
4. If primary TrueNAS fails, backups are safe on secondary TrueNAS
This architecture gives you:
- Hardware redundancy
- Network separation
- Efficient storage (single ZFS layer)
- Professional-grade backup infrastructure
While TrueNAS SCALE's Incus container feature is still experimental, it provides a lightweight alternative to VMs for running services like Proxmox Backup Server. The key to success is understanding the different storage integration methods and their trade-offs.
For PBS on TrueNAS, the clear winner is Method 1: Direct ZFS bind mounting. This avoids both the inefficiency of ZFS-on-ZFS and the overhead of NFS, giving you native performance while maintaining TrueNAS's ZFS features.
Use NFS mounting (Methods 2 and 3) only when:
- You need the storage to be on a different physical server
- You're integrating with existing NFS infrastructure
- You have specific network storage requirements
Most importantly, remember that while this setup is technically elegant and efficient, running backups on the same infrastructure you're protecting is a significant architectural risk. Plan accordingly, implement off-site replication and always test your restores.
The combination of TrueNAS SCALE, Incus containers and Proxmox Backup Server can create a powerful backup solution just make sure you're using it wisely and with appropriate redundancy.
