Access an NFS shared folder from an unprivileged proxmox LXC container
Posted on 2025-06-04
Categories: selfhosting
Tags: selfhosting homelab openmediavault proxmox nfs lxc
After reinstalling my NAS last week-end (using OpenMediaVault) due to mistakes on my part, I wanted to use some data stored on my NAS from an LXC container managed on my proxmox cluster. In my head, it was supposed to be very straight forward… But if I’m writing this now, it means it didn’t go as planned :D.
Creating the NFS shared directory was as simple as planned: Using the OMV web UI, I created in a few minutes a new NFS (v4) shared folder, with read-only permissions and limited to the IP of my container.
For simplicity, as the NFS storage is only available on my network, I added the following option to my shared folder: « all_squash, anongid=xxx, anonuid=yyy »:
- all_squash: Map all uids and gids to the anonymous user, which means all requests will be mapped to the anonymous user. This may not be what you want to do, but was the simplest yet secure for my read-only data accessed from only 1 specific server
- anongid=xxx (where xxx is a valid group id on the system): the group id to used for the anonymous user group
- anonuid=yyy (where yyy is a valid user id on your system): the user id to used for the anonymous user group
Then I went to my container, installed nfs-common and then tried to mount that directory without success: « Permission denied ». Hmm… Tried multiple things that are not useful for this post because none of them worked. Have I RTFM better, I would have known why: Proxmox create, by default, unprivileged LXC containers. I knew that but didn’t know the implications…
Unprivileged containers means that « all user id and group id are mapped to a different number range than on the host machine ». As an example, the root uid which is normally 0 becomes 100000. That’s due to the use of namespaces, a kernel feature. Doing so prevents that, for example, a malicious software managing to “escape” the container gets the host root permission. So important feature to secure any abuse on the host from an lxc container.
But in my particular case, it also meant I couldn’t mount any NFS folder from the host. This is also true for CIFS/SMB shared folders as well. I thought about using sshfs + autofs or switch to a VM (Virtual Machine). The later would have worked with NFS shared folder, but I prefer using LXC containers when possible as they don’t block the hardware resources like VM does. I keep VM only for servers running docker as it is more secure in that particular usage. The sshfs + autofs was a strong contender but was my plan B. Plan A was trying to make the NFS shared folder works as it avoided some extra config on my NAS to secure the folder for sshfs usage.
The proper way of mounting NSF (or CIFS/SMB) folders on an unprivileged lxc container is actually simple: first you mount the remote folder on the proxmox host and then you use the proxmox « bind mount » feature to basically mount the “mounted” storage on the host within the container.
This use case is actually writen in their wiki: « Bind mounts allow you to access arbitrary directories from your Proxmox VE host inside a container. Some potential use cases are: […] Accessing an NFS mount from the host in the guest ».
Main drawback is that the NFS folder is mounted on the host as well even though the host does not need it. Other VMs/Containers will not see it anyway (unless configured otherwise) and in any cases, the folder is mount in read only with no critical, private or important data anyway. So for my use case, I didn’t care about those drawbacks.
Also quick note: this bind mounted storage will not be included in the backups made by proxmox, which was ok to me for those data in particular.
Be careful with your NFS configuration, if you allowlisted your container IP address, don’t forget to change it to your host IP address instead as the host is the one connecting to the shared folder now and not the container.
For the rest of this post, let’s assume that:
- My NAS is reachable at the NASName.bacardi55.local FQDN. If you don’t have a local DNS in place like this, replace it by its IP. For this post, let’s assume it is 192.168.0.55
- I’m going to mount the NFS directory FolderName from the NAS (which is in /export/FolderName on the NAS, but I won’t go through that part)
- The host will mount the above directory here: /mnt/NASName/FolderName
- The LXC container will “bind mount” the directory here: /FolderName
- The LXC container has the 555 node id in proxmox
On the proxmox host, create the directory where you’re going to mount the NFS folder:
mkdir /mnt/NASName/FolderName
Then, add a line in the /etc/fstab to mount automatically the folder:
NASName.bacardi55.local:/FolderName /mnt/NASName/FolderName nfs defaults 0 0
If your server doesn’t have a local DNS entry, you can use its IP address instead, it will look like this:
192.168.0.55:/FolderName /mnt/NASName/FolderName nfs defaults 0 0
Use only one of the 2 line above, not both.
Then, systemD daemon must be reloaded:
systemctl daemon-reload
Then, let’s mount the directory on the host:
mount /mnt/NASName/FolderName
It should work now and you can confirm by checking the content of /mnt/NASName/FolderName that should display the content of what is shared from the NFS shared storage.
Last thing to do is add the bind mount to the LXC container. This is not doable from the proxmox UI, so you must do it from the command line:
pct set 555 -mp0 /mnt/NASName/FolderName,mp=/FolderName
You should now see the mounted storage without launching any command within the LXC container.
And voilà, your data shared via NFS are accessible from your unprivileged LXC container :). And if another LXC container needs to access this storage, all you need to do is reuse the pct command with the container node ID instead.
I would have saved a lot of time by actually reading the proxmox wiki first, but I finally got there. I would have prefer not to mount the NFS storage on the proxmox host, but I did what was necessary to avoid using a privilege lxc or a VM :).