I recently wanted to make storage from my TrueNAS SCALE system available to several Proxmox LXC containers.

The basic idea sounds straightforward:

TrueNAS
   ↓ NFS
Proxmox host
   ↓
One or more LXC containers

Naturally, the first attempt ended with a permission error.

The second attempt left behind a directory that Proxmox no longer wanted but also refused to recreate.

So here is the complete setup that worked for me, including the errors, the permission model, and the different ways to pass the NFS storage into one or more LXC containers.

My Environment

This guide is based on the following homelab setup:

Component	Value
TrueNAS SCALE	25.10
TrueNAS IP	`192.168.2.10`
Proxmox IP	`192.168.2.20`
TrueNAS pool	`WD16TB`
TrueNAS dataset	`/mnt/WD16TB/proxmox`
Proxmox storage ID	`TN-NFS`

Replace the addresses, pool name, and paths with the values from your own environment.

What I Wanted to Achieve

I wanted Proxmox to manage the NFS mount through its web interface rather than creating a manual /etc/fstab entry.

In Proxmox, NFS storage can be added under:

Datacenter
→ Storage
→ Add
→ NFS

Proxmox then mounts the export automatically below:

/mnt/pve/<STORAGE-ID>

In my case:

/mnt/pve/TN-NFS

For the initial setup, I selected Snippets as the content type.

This gives Proxmox a valid storage content type and causes it to create a directory named:

snippets/

The important distinction is that this only mounts the NFS share on the Proxmox host.

It does not yet make the storage available inside an LXC container. That is a separate step.

Create a Dedicated TrueNAS Dataset

Instead of reusing the existing multipurpose dataset, I created a dedicated dataset for Proxmox.

In TrueNAS:

Datasets
→ WD16TB
→ Add Dataset

I used:

Name:           proxmox
Dataset Preset: Generic

This created:

/mnt/WD16TB/proxmox

Using a dedicated dataset has several advantages:

permissions are easier to understand
existing SMB data is not affected
the NFS export has a clear purpose
future snapshots and replication can target the dataset separately

The Generic preset uses normal POSIX-style permissions and initially creates permissions equivalent to 755.

Create a Dedicated NFS User

Next, I created a local TrueNAS service user for the NFS share.

Navigate to:

Credentials
→ Users
→ Add

Configuration:

Username:       proxmox_nfs
Full Name:      Proxmox NFS Service
Primary Group:  Create new proxmox_nfs group
UID:            Next available
Home Directory: /var/empty

I left the interactive access options disabled:

[ ] SMB Access
[ ] TrueNAS Access
[ ] Shell Access
[ ] SSH Access

This account is not intended for logging in.

It is only used to:

own the dataset
own files created through NFS
receive the mapped NFS requests from Proxmox

The password is not used by NFS with SYS security.

Configure the Dataset Permissions

I then opened:

Datasets
→ WD16TB
→ proxmox
→ Permissions
→ Edit

I changed the ownership to:

Owner User:  proxmox_nfs
Owner Group: proxmox_nfs

I also enabled:

[x] Apply User
[x] Apply Group

The final permissions were:

Account	Read	Write	Execute
User	Yes	Yes	Yes
Group	Yes	Yes	Yes
Other	No	No	No

This is equivalent to:

The resulting dataset ownership was:

proxmox_nfs:proxmox_nfs

Because the dataset was new and empty, I did not apply the permissions recursively.

Recursive permission changes should only be used when existing files genuinely need to be changed. They are not a checkbox to enable simply because it looks thorough.

Create the TrueNAS NFS Share

Next, I created the NFS export.

Navigate to:

Shares
→ Unix Shares (NFS)
→ Add

Basic configuration:

Path:        /mnt/WD16TB/proxmox
Description: Proxmox LXC storage
Enabled:     Yes
Read Only:   No

Under Hosts, I added only the Proxmox host:

192.168.2.20

The allowed host is the system connecting to TrueNAS, so this must be the Proxmox IP address.

Leaving the Hosts and Networks fields empty would allow every reachable system to attempt to access the share.

Configure Mapall

Under the advanced NFS options, I configured:

Mapall User:  proxmox_nfs
Mapall Group: proxmox_nfs
Security:     SYS

I left Maproot empty.

Mapall causes all users arriving through this NFS share to be handled as:

proxmox_nfs:proxmox_nfs

This is especially useful when unprivileged LXC containers are involved.

An unprivileged container does not normally present the same user IDs to the Proxmox host that it sees internally.

For example:

LXC UID 0     → Proxmox UID 100000
LXC UID 1000  → Proxmox UID 101000

Without a deliberate permission strategy, this can quickly turn a shared folder into a small UID archaeology project.

The Generated NFS Export

In my installation, TrueNAS assigned UID and GID 3004 to the proxmox_nfs account.

Your generated export will likely contain different numeric values.

My export looked like this:

"/mnt/WD16TB/proxmox"\
    192.168.2.20(
        sec=sys,
        rw,
        anonuid=3004,
        anongid=3004,
        all_squash,
        no_subtree_check
    )

The important parts are:

192.168.2.20   Only the Proxmox host is authorized
rw                Read and write access
all_squash        All client users are mapped
anonuid=3004      Example UID assigned to proxmox_nfs
anongid=3004      Example GID assigned to proxmox_nfs

I then enabled the NFS service and configured it to start automatically.

Add the NFS Storage in Proxmox

Back in Proxmox, I opened:

Datacenter
→ Storage
→ Add
→ NFS

Configuration:

ID:          TN-NFS
Server:      192.168.2.10
Export:      /mnt/WD16TB/proxmox
Content:     Snippets
Nodes:       proxmox
NFS Version: Default
Enabled:     Yes

After clicking Add, Proxmox mounted the share under:

/mnt/pve/TN-NFS

and created:

/mnt/pve/TN-NFS/snippets

At this point, the TrueNAS NFS share was successfully mounted on the Proxmox host.

Where the Setup Currently Stops

The configuration now looks like this:

TrueNAS dataset
    ↓
TrueNAS NFS share
    ↓
Proxmox-managed NFS storage
    ↓
/mnt/pve/TN-NFS

The share is set up on the Proxmox host but not inside the LXC container. Adding NFS storage to Proxmox and assigning it to an LXC container are separate steps. Here are some options to continue:

Option 1: Bind-Mount the Existing Share into an LXC

This is the best option when an LXC should access existing files and directories on the NFS share.

For example, for container 101:

pct set 101 \
  -mp0 /mnt/pve/TN-NFS/shared,mp=/mnt/shared

This maps:

Proxmox:
  /mnt/pve/TN-NFS/shared

to:

LXC:
  /mnt/shared

For read-only access:

pct set 101 \
  -mp0 /mnt/pve/TN-NFS/shared,mp=/mnt/shared,ro=1

Advantages

the container sees the existing NFS files directly
NFS is mounted only on the Proxmox host
TrueNAS only needs to authorize the Proxmox IP
the LXC does not need NFS client privileges
Mapall handles the shifted container IDs
a mount can be made read-only

Disadvantages

an arbitrary host-path bind mount normally requires pct or editing the container configuration
bind-mounted data is not included in normal LXC backups
the source path must also exist on another node before migrating the container
a missing NFS mount can expose an empty local directory at the same path if the setup is not checked carefully

Do Not Mount the Storage Root Unless Necessary

It would be possible to bind:

/mnt/pve/TN-NFS

directly into the container.

However, that also exposes Proxmox-created directories such as:

snippets/

A cleaner layout is to create a normal application directory on the share:

/mnt/pve/TN-NFS/shared

and bind only that directory into the container.

This keeps Proxmox storage metadata separate from application data.

Sharing the Same NFS Storage with Multiple LXCs

The bind-mount approach becomes even more useful when several containers need access to the same files.

The recommended design is:

TrueNAS NFS share
    ↓
One host-side NFS mount
    ↓
Bind mount into LXC 101
Bind mount into LXC 102
Bind mount into LXC 103

TrueNAS sees the Proxmox host as the authorized NFS client, regardless of how many containers use the mounted files.

That gives me:

one host-side NFS mount
one authorized IP address in TrueNAS
one Mapall identity
no separate NFS configuration in every LXC

Sharing One Common Directory

When several containers should work with the same files, I can create:

/mnt/pve/TN-NFS/shared

and pass it into each LXC:

Proxmox:
  /mnt/pve/TN-NFS/shared

LXC 101:
  /mnt/shared

LXC 102:
  /mnt/shared

LXC 103:
  /mnt/shared

All containers then see the same files and directory tree.

This is useful for:

media libraries
download directories
import folders
shared documents
application exchange directories
transcoding or processing workflows

For example:

Downloader LXC
    ↓
/mnt/shared/downloads

Media manager LXC
    ↓
/mnt/shared/downloads

Media server LXC
    ↓
/mnt/shared/media

Because every container accesses the same mounted directory, changes are visible immediately.

A file written by the downloader appears directly in the media manager or media server without copying, synchronization, or a second transfer between container volumes.

The data remains on TrueNAS, while the containers only receive access to the directories they require.

Separate Directories for Each Container

If the containers should use the same NFS export but not share all of their data, I can create separate directories:

/mnt/pve/TN-NFS/lxc-101
/mnt/pve/TN-NFS/lxc-102
/mnt/pve/TN-NFS/lxc-103

Each directory is then passed only into its matching container.

A mixed structure is also possible:

/mnt/pve/TN-NFS/shared
/mnt/pve/TN-NFS/lxc-101
/mnt/pve/TN-NFS/lxc-102

A container can receive both:

its own application directory
the common shared directory

Multiple LXC mount points use incrementing indexes such as mp0, mp1, and mp2.

Reusing mp0 would replace the existing mount-point configuration rather than add another one.

For example:

pct set 101 \
  -mp0 /mnt/pve/TN-NFS/lxc-101,mp=/mnt/app-data \
  -mp1 /mnt/pve/TN-NFS/shared,mp=/mnt/shared

The resulting layout is:

LXC 101:
  /mnt/app-data
  /mnt/shared

Another container can receive its own private directory and the same shared directory:

pct set 102 \
  -mp0 /mnt/pve/TN-NFS/lxc-102,mp=/mnt/app-data \
  -mp1 /mnt/pve/TN-NFS/shared,mp=/mnt/shared

This gives each application a dedicated area while still allowing access to common files.

The Mapall Trade-Off

Mapall makes access from multiple unprivileged containers simple because every request is handled as:

proxmox_nfs:proxmox_nfs

The trade-off is that TrueNAS no longer distinguishes which LXC created a file through normal Unix ownership.

All containers using the share effectively write as the same user.

That means containers with access to the same directory can generally:

read each other’s files
modify each other’s files
rename each other’s files
delete each other’s files

For a shared media or download directory, that is usually the intended behaviour.

For stronger separation, the solution is to expose separate directories to each container rather than allowing every container to see the entire export.

Mapall simplifies identity management. It does not provide per-container ownership separation.

Option 2: Create a Proxmox-Managed LXC Volume

The NFS storage can also be configured to hold Proxmox-managed container volumes.

Edit:

Datacenter
→ Storage
→ TN-NFS
→ Edit

Add the following content type:

Container

Then open:

LXC
→ Resources
→ Add
→ Mount Point

Select:

Storage:     TN-NFS
Mount point: /mnt/data
Disk size:   As required

Proxmox then creates and manages a dedicated storage-backed volume for that container.

Advantages

configuration is available through the Proxmox GUI
Proxmox manages the volume
the mount point belongs clearly to one container
the volume can participate in Proxmox backup handling when configured accordingly
suitable for application data owned by one LXC

Disadvantages

it does not expose an existing ordinary directory directly
each LXC receives its own separate volume
it is not suitable when several containers need the same directory
the configured volume size must be managed

This is a good option for:

Application database
Application configuration
Container-specific persistent data

It is not the right option for:

One shared download directory used by several containers

Creating one managed volume per LXC provides isolation.

It does not provide shared access to the same files.

Option 3: Mount NFS Directly inside the LXC

The container can also act as the NFS client itself.

The layout then becomes:

TrueNAS
    ↓
LXC container

The container needs permission to mount NFS filesystems.

On Proxmox, this can be enabled with:

pct set 101 -features mount=nfs

Inside the container:

apt update
apt install nfs-common

mkdir -p /mnt/truenas

mount -t nfs \
  192.168.2.10:/mnt/WD16TB/proxmox \
  /mnt/truenas

With this design, TrueNAS sees the LXC IP as the NFS client.

The current export only allows:

192.168.2.20

which is the Proxmox host.

The LXC IP would therefore also need to be added to the TrueNAS Allowed Hosts list.

Advantages

the LXC controls its own NFS mount
mount options can be configured inside the container
the container is less dependent on the Proxmox storage configuration

Disadvantages

each LXC needs its own NFS configuration
each LXC IP must be authorized on TrueNAS
the container needs permission to mount NFS
the container becomes responsible for mount failures and NAS outages
allowing filesystem mounts inside containers reduces isolation
NFS operations from a container can affect host I/O

For one container with a specific requirement, this can be reasonable.

For several normal application containers, it multiplies the configuration and the possible failure points.

I would not use it merely because the application needs access to a shared media folder.

Option 4: Mount NFS Manually on the Proxmox Host

Instead of using the Proxmox NFS storage backend, the share can be mounted manually through /etc/fstab.

Example:

192.168.2.10:/mnt/WD16TB/proxmox \
/mnt/truenas-proxmox \
nfs \
rw,_netdev,nofail,x-systemd.automount \
0 0

The resulting host directory can then be bind-mounted into one or more containers.

Advantages

complete control over mount options
systemd automount can be used
no artificial Proxmox content type is required
useful for storage that should not be managed by the Proxmox storage backend

Disadvantages

shell access is required
the mount is managed outside the Proxmox GUI
configuration exists in another location
startup ordering and mount availability need careful handling

I chose the Proxmox NFS storage backend because it gives me visibility and control through the web interface.

Which Option Should I Use?

My decision table looks like this:

Requirement	Recommended option
Existing NAS files inside one LXC	Host NFS mount plus bind mount
Same files inside several LXCs	Host NFS mount plus shared bind mount
Separate directory for each LXC	Host NFS mount plus separate bind mounts
Dedicated volume owned by one LXC	Proxmox-managed container volume
LXC must manage NFS independently	Direct NFS mount inside the LXC
Custom host-side mount options required	`/etc/fstab` plus bind mount
Container only needs read access	Read-only bind mount

For my setup, the best design is:

TrueNAS NFS
    ↓
Proxmox-managed host mount
    ↓
Dedicated shared subdirectory
    ↓
Bind mount into the required LXCs

This gives every container the same real view of the files without turning every LXC into a separate NFS client.

Backup Considerations

There is one important difference between bind mounts and Proxmox-managed container volumes.

Bind-Mounted Data Is Not Included in the LXC Backup

A normal Proxmox LXC backup does not copy the contents of an arbitrary host bind mount.

The container configuration remembers that the mount point exists, but the files themselves remain on TrueNAS.

Those files must therefore be protected separately.

For example:

TrueNAS ZFS snapshots
TrueNAS replication
cloud backup
another NAS
external backup storage

In my case, this is not a disadvantage.

The data already belongs to TrueNAS, so TrueNAS should also be responsible for protecting it.

I would not want every LXC backup to duplicate the same shared media directory anyway.

Storage-Backed Mount Points Are Different

A Proxmox-managed container volume can be included in container backup handling, depending on its configuration.

That makes it more suitable for application data belonging exclusively to one LXC.

The distinction is:

Shared NAS data:
  Protect on TrueNAS

Container-owned volume:
  Protect through Proxmox backup

Migration and Cluster Considerations

In a Proxmox cluster, the NFS storage should be available on every node that might run the container.

For a bind mount, the source path must also exist under the same path on each destination node.

For example:

/mnt/pve/TN-NFS/shared

must resolve correctly on every relevant Proxmox node.

Marking storage as shared tells Proxmox that the storage is shared.

It does not configure:

TrueNAS permissions
allowed hosts
network connectivity
NFS service availability
identical bind-mount paths

Sadly, the shared checkbox does not include telepathy.

A Note About Child Datasets

TrueNAS treats every ZFS dataset as a separate filesystem.

If I create a child dataset below:

/mnt/WD16TB/proxmox

it is not automatically exposed simply because the parent dataset is exported.

For uncomplicated shared folders, normal directories are therefore often easier:

/mnt/WD16TB/proxmox/shared
/mnt/WD16TB/proxmox/lxc-101
/mnt/WD16TB/proxmox/lxc-102

If separate ZFS properties, snapshots, quotas, or replication policies are required, child datasets can still be useful.

They might then need their own NFS exports.

Security Considerations

This setup uses:

Security: SYS

SYS relies on user and group IDs and does not encrypt or cryptographically authenticate the NFS traffic.

For a trusted homelab network, this is often acceptable.

It should not be exposed directly to:

the internet
an untrusted Wi-Fi network
guest networks
hostile client systems

The basic protections in this setup are:

the NFS share is restricted to the Proxmox host
the dataset is dedicated to this purpose
access is mapped to a non-root service user
Other permissions are disabled
containers only receive selected subdirectories

For environments requiring stronger authentication or encryption, Kerberos-backed NFS security should be considered.

Final Design

My final TrueNAS configuration is:

Dataset:
  /mnt/WD16TB/proxmox

Owner:
  proxmox_nfs:proxmox_nfs

Permissions:
  770

NFS Allowed Host:
  192.168.2.20

Mapall:
  proxmox_nfs:proxmox_nfs

Security:
  SYS

The Proxmox configuration is:

Storage ID:
  TN-NFS

NFS Server:
  192.168.2.10

Export:
  /mnt/WD16TB/proxmox

Host mount:
  /mnt/pve/TN-NFS

The recommended LXC structure is:

/mnt/pve/TN-NFS/shared
    ↓
LXC 101: /mnt/shared
LXC 102: /mnt/shared
LXC 103: /mnt/shared

My Verdict

Mounting a TrueNAS NFS share on Proxmox is not particularly difficult once the ownership model is clear.

My first error wasn’t due to missing connectivity; Proxmox reached the share successfully. It just couldn’t create its content directory because dataset permissions and NFS user mapping blocked it.

The dedicated design fixes that cleanly:

Dedicated TrueNAS dataset
    ↓
Dedicated proxmox_nfs account
    ↓
770 dataset permissions
    ↓
Mapall user and group
    ↓
Restricted to the Proxmox host
    ↓
Proxmox-managed NFS storage
    ↓
Selected bind mounts into the LXCs

With the share mounted on Proxmox and permissions handled through Mapall, it’s now ready to be passed into whichever LXCs i need it.