Posted on by richay

Mounting NAS Shares in LXC Containers on Proxmox

Status: CURRENT
Last reviewed: 31 August 2026
Applies to: Proxmox VE 8/9, LXC containers, host-mounted SMB/CIFS or NFS shares

This is the clean way I mount NAS storage into my Proxmox LXC containers: mount the network share once on the Proxmox host, then pass that host directory into whichever containers need it using a Proxmox bind mount.

When I rebuilt my Proxmox setup, one of the first things I needed was access to the same NAS shares from multiple LXC containers.

You can try mounting SMB/NFS directly inside each container, but I much prefer doing it once on the Proxmox host and then bind-mounting the result into the LXCs.

That gives me one place for NAS credentials and mount behaviour, while each container just sees a normal Linux directory. Fewer moving parts, fewer opportunities for something to go cactus.

The layout is basically:

NAS / SMB / NFS
       ↓
Proxmox host mounts share
       ↓
/mnt/nas/media
       ↓
Proxmox bind mount
       ↓
LXC sees /mnt/media
       ↓
Plex / Docker / whatever needs it


1. Mount the share on the Proxmox host first

The network share needs to be working on the Proxmox host before we pass it into the container.

For SMB/CIFS I use /etc/fstab. I have a separate guide for that here:

Mount a Windows / SMB Share in Linux with fstab

For this guide I’ll assume the NAS share is already mounted on the Proxmox host at:

/mnt/nas/media


Before touching the LXC, confirm that path really is the network mount and not just an empty local directory:

findmnt -T /mnt/nas/media
ls -lah /mnt/nas/media


This check matters. If the NAS mount is broken but the empty local mount-point directory still exists, you can accidentally bind that empty directory into the LXC. Worse, an application may start writing into the Proxmox host’s local disk thinking it’s writing to the NAS. That’s a fun one to discover after the root filesystem fills up 😅.

2. Pick where the share should appear inside the LXC

The host path and container path do not need to be the same.

For example:

Proxmox host:
  /mnt/nas/media

Inside LXC:
  /mnt/media


Personally I like keeping container paths simple. The LXC doesn’t need to know that the files came from some NAS sitting elsewhere on the network.

3. Stop the LXC

I’ll use container 103 in the examples:

pct stop 103


4. Add the bind mount with pct

Proxmox officially supports bind mounts for exposing arbitrary host directories inside an LXC.

Add the NAS path as the first mount point:

pct set 103 -mp0 /mnt/nas/media,mp=/mnt/media


Check the resulting container configuration:

pct config 103


You should see something similar to:

mp0: /mnt/nas/media,mp=/mnt/media


Under the hood that lives in:

/etc/pve/lxc/103.conf


You can edit the config directly, but I prefer pct set for something this simple. Less chance of fat-fingering the container config because I’ve decided I suddenly know better than the tooling.

Read-only mount for media

If the container only needs to read the files — a Plex container is a good example — make the bind mount read-only:

pct set 103 -mp0 /mnt/nas/media,mp=/mnt/media,ro=1


If Plex can stream the media without needing to modify it, there is no bloody reason to give it write access to the whole library.

5. Start the container and test it

pct start 103
pct exec 103 -- ls -lah /mnt/media


Or enter the container normally:

pct enter 103
ls -lah /mnt/media


If you can see the NAS files, the actual bind mount is done.

Unprivileged LXC permissions

This is normally the bit where a perfectly good mount suddenly becomes Permission denied.

Proxmox creates new LXCs as unprivileged containers by default. That’s a good thing for security, but it means UIDs inside the container are mapped to different unprivileged UIDs on the Proxmox host.

With the usual default Proxmox mapping:

LXC UID 0      → host UID 100000
LXC UID 1000   → host UID 101000
LXC UID 1001   → host UID 101001
...


So if an application runs as UID 1000 inside an unprivileged LXC, the bind-mounted files need to be accessible to the corresponding mapped host UID — normally 101000 with the default map.

Check whether the container is unprivileged:

pct config 103 | grep -E 'unprivileged|lxc.idmap'


Don’t blindly assume the 100000 offset if you’ve configured custom ID mappings. The example above is the normal/default arrangement. Custom lxc.idmap entries change the maths.

If the host share is SMB/CIFS

This is actually handy because CIFS lets you control the UID/GID that Linux presents for the mounted files.

For example, if the application needs UID/GID 1000:1000 inside an unprivileged LXC using the default map, the host CIFS mount can present the files as:

uid=101000,gid=101000


An fstab mount might therefore contain:

//NAS/media /mnt/nas/media cifs credentials=/etc/samba/credentials-nas,uid=101000,gid=101000,file_mode=0660,dir_mode=0770,nofail,_netdev,x-systemd.automount 0 0


The NAS still controls the real SMB permissions. These UID/GID options just control how the files appear to Linux on the Proxmox host and therefore through the bind mount.

If the host share is NFS

NFS permissions are much more directly tied to numeric UID/GID values supplied by the NFS server, so make sure the IDs exported by the NAS line up with what the mapped LXC user needs.

This is one reason SMB can sometimes be easier for a simple media bind mount: I can explicitly choose the host-side presented UID/GID in the CIFS mount options.

Privileged containers are easier — but that’s not a reason to use one

In a privileged LXC, UID 1000 inside generally corresponds directly to UID 1000 on the host, which makes bind-mount permissions simpler.

That does not mean I’d convert a container to privileged just to make a NAS mount easier. Proxmox explicitly considers unprivileged containers the safer design.

Fix the ID/permission mapping rather than trading away container isolation because Linux permissions hurt your feelings for ten minutes 🙂

Multiple shares

You can add more mount points as mp1, mp2, etc.

pct set 103 -mp0 /mnt/nas/media,mp=/mnt/media,ro=1
pct set 103 -mp1 /mnt/nas/downloads,mp=/mnt/downloads
pct set 103 -mp2 /mnt/nas/backups,mp=/mnt/backups


That is essentially how I like to build service LXCs: give each one only the bits of storage it actually needs rather than mounting the entire NAS because apparently restraint is illegal.

Bind mounts are NOT included in normal LXC backups

Important: Proxmox does not include the contents of bind-mounted host directories in normal vzdump container backups.

For a 40 TB media share this is normally exactly what I want. Backing up a tiny Plex LXC should not suddenly decide it also needs to copy the entire bloody NAS.

But it means your backup plan needs to treat these as two separate things:

LXC backup
  → container OS/config/application data

NAS backup
  → the actual files inside the bind-mounted share


Don’t restore an LXC backup six months later and wonder why 20 TB of movies didn’t magically emerge from it.

Snapshots are the same story

Bind mounts are not managed container storage, so their contents are not part of normal Proxmox LXC snapshots either.

The NAS remains responsible for its own snapshots, ZFS protection, replication, backups, prayers to the storage gods, etc.

Don’t bind-mount random host system directories

Proxmox specifically warns against bind-mounting things such as /, /var or /etc into containers.

Use dedicated source directories for the data you’re intentionally sharing.

Also, the bind-mount source path must not contain symlinks.

A nice boring path such as:

/mnt/nas/media


is exactly what we want. Boring storage paths are good storage paths.

NAS unavailable when Proxmox boots

This deserves a mention because network storage occasionally decides it wants a sleep-in.

On the Proxmox host I use network-friendly fstab options such as:

nofail,_netdev,x-systemd.automount


The automount means the network share is mounted when the path is first accessed rather than forcing Proxmox to sit there during boot waiting for the NAS.

Before manually starting a container after a NAS outage, I still check:

ls /mnt/nas/media >/dev/null
findmnt -T /mnt/nas/media


If that doesn’t show the expected CIFS/NFS mount, fix the host mount first. Don’t let the container happily write into an empty local directory underneath the missing NAS mount. That’s how mystery disk usage is born.

Remove a bind mount

Stop the container first:

pct stop 103
pct set 103 -delete mp0


Then confirm:

pct config 103


My preferred setup

For NAS-backed LXC services I now keep the design pretty boring:

NAS
 ↓
SMB/NFS mounted once on Proxmox
 ↓
Dedicated /mnt/nas/... directories
 ↓
Proxmox mp0/mp1 bind mounts
 ↓
Unprivileged LXCs
 ↓
Read-only wherever possible


No SMB passwords copied into every container, no privileged LXC just because UID mapping was annoying, and no 40 TB surprise hiding inside a vzdump job.

Mount it once, pass through what each container needs, then leave the bastard alone while it’s working 🙂

References

Leave a Reply

Your email address will not be published. Required fields are marked *