SMB Bind Mounts in an Unprivileged LXC Container

Prep Work

We will need to do a bit of prep work on the Proxmox Host to have this work as intended in an Unprivileged LXC Container, but it’s worth it.

Understanding the IDs

First of all you should be aware that the host (Proxmox) and an Unprivileged LXC container have different ID guides for security sake. Simply put, the LXC containers have IDs that are numbered 100,000 higher than the host. This is for security to keep them from clashing with the host system. If you want to have bind mounts from the host and have it appear the proper user and group IDs into an LXC container the UID on mount within the Proxmox host has to be 100000 higher than the owning user. To look like root in the Unprivileged LXC container the UID for the mount on the host will need to be set as ID 100000.

Mount Point on the Host First

First mount the SMB share on the Proxmox host with a user ID 100000. The group is less important but still has to be GID + 100000 or just a the number you want providing it is no less than 100000. This will allow it to look right in the Unprivileged LXC container. I like to use a Group ID of 110000 on the Proxmox host so it shows up in the container as 10000 in the container.

Inside the LXC container I create a group with the ID 10000

groupadd -g 10000 lxc_shares

This is what users in the container get added to in order to gain access to the mount.

You will need to create the mount folder as per normal where you want it first in your Proxmox host. In the example below the share is mounted to /mnt/nas01/video

This is an actual line from an fstab file from one of my Proxmox hosts.

//10.169.212.135/video /mnt/nas01/video cifs credentials=/root/.crednas01,uid=100000,gid=110000,file_mode=0770,dir_mode=0770 0 0

Failing to create a mount with the correct IDs will give you a bind mount in the container that is owned by nobody/nogroup.

Passing the Mount Point to the LXC Container

When passing this into the LXC container (say 103.conf in /etc/pve/lxc) it looks like this. 

mp2: /mnt/nas01/video/,mp=mnt/nas01/video

The first part is the mount priority and has to be unique int he config file. The next part is two parts. The first is the host location. The second, after the comma is the location in the Container you want the mount to show up. You do not need to create this folder structure first.

The Mount Point configuration can be archived several ways. From the Proxmox web interface, from the Proxmox terminal 

pct set 103 -mp2 /mnt/nas01/video/,mp=mnt/nas01/video

or editing the container config file directly as shown above.

I prefer editing the config file for the container. Normally I would create several Bind Mounts at once. Perhaps for a backup destination (have to keep those docker persistent volumes safe) and other mounts as required for the purpose of what is going to be running in the container (Docker, Jellyfin, Emby, Plex, you name it)

Note: To Edit this file, the Container should be shut down while modifying the config. If it is running restart it for the changes to take effect.

After you are satisfied with the mounts, start the container (pct start 103)

Check the Mount Point your LXC Container

From a terminal inside the container, the mount point should look like this (if you created the group for the ID 10000 already).

drwxrwx--- 2 root lxc_shares 0 Aug 16 16:55 video

If you do not see the group name for the folder, refer to the section above

groupadd -g 10000 lxc_shares

Any user inside this Unprivileged container that you want to have read/write access to this location will have to part of the lxc_shares group

usermod -aG lxc_shares <username>

For example, the Jellyfin user will need to be included in this group to access the media in the location passed into the LXC Container.

If you do not want the container to be able to write to the location add ,ro=1 to the end of the mount clause in the config file

mp2: /mnt/nas01/video/,mp=mnt/nas01/video,ro-1

 

Hope that helps.

If you are going to be deploying Jellyfin/Emby/Plex and want to use hardware transcoding there are more steps to take to get the GPU/iGPU passed through. The biggest advantage with using a LXC container for this is you can have multiple container using the same hardware at a time without conflicts.