File sharing from NAS to unprivledged containers

[zelig2]

Originally, all my *arr services were installed on a Synology NAS as Docker containers. Over time I found the updating process and stability to be lacking on the NAS so I wanted to move them over to my Proxmox cluster to help with future upgradability and maintainability. Each service is its own LXC on my cluster and thus each has its own Container ID. For my set up I have Plex @ 501, Sonarr @ 502, Radar at 503, Prowlarr @ 504 and Sabnzbd @ 505.

Sonarr was the first system to move over to Proxmox and resulted in multiple weeks of figuring out a good way for me to do permissions. Probably the best one to try because it had sonarr running from a non-root user, which ultimately I preferred.

Step 1: configure NAS

I found using SMB was the most ideal for this configuration as I could control who had access to what files as well as more easily see when a client messed up. So for your NAS make sure there's a specific user for each service you want to have access to the media/download files.

Step 2: create a specific *arr users on the host.

For each user I made the UID as 1+LXC_ID which will allow me to mount the network share for these users. The command id sonarr at the end will confirm the user name gets the right UID as well as the same GID. Repeat this for all the other users (radarr, prowlarr, sabnzbd, etc). Note: this likely won't work if containers need to move to a different node in a cluster.

useradd -u 1502 -m -s /usr/bin/bash sonarr
useradd -u 1503 -m -s /usr/bin/bash radarr
useradd -u 1504 -m -s /usr/bin/bash prowlarr
useradd -u 1505 -m -s /usr/bin/bash sabnzbd
usermod -aG sabnzbd radarr
usermod -aG sabnzbd sonarr
usermod -aG sabnzbd prowlarr

Next, add a line in /etc/subuid and /etc/subgid to account for these new users created above.

root:1501:100

Then with the new home folder created for sonarr I store a credentials file to be used by the CIFS/SMB mount as detailed here.
/home/sonarr/.cifs_creds

username=sonarr
password=sonarr-password-on-the-NAS

After the file has been created I changed the ownership and rights:

chown sonarr:sonarr /home/sonarr/.cifs_creds
chmod 600 /home/sonarr/.cifs_creds

Do this for all newly created users.

Step 3: remote folder mounting

Next I needed to mount the remote folder from my NAS to the Proxmox host, but unfortunately I couldn't use the Proxmox GUI as I needed the specific user I just created to own the files. I used the guide from here to help generate the right script to update the fstab so the mount will be automounted each time. The below example shows mounting the //NAS/video folder but using the sonarr credentials. I then did this same thing again for every arr container that needed access to that folder. It's very redundant but then I can tell which arr user is mucking around with the files if something should go wrong. I then also have a local SSD drive that I have a downloads folder in there that is owned by sabnzbd:sabnzbd.

{ echo '' ; echo '# Mount CIFS share on demand with rwx permissions for use in LXCs (manually added)' ; echo '//NAS/video/ /mnt/pve/sonarr-video cifs _netdev,x-systemd.automount,noatime,uid=1502,gid=1502,dir_mode=0770,file_mode=0770,credentials=/home/sonarr/.cifs_creds 0 0' ; } | tee -a /etc/fstab

Now that we have fstab updated we have to mount the folder. These commands assume no folder exists currently.

mkdir /mnt/pve/sonarr-video
systemctl daemon-reload
mount /mnt/pve/sonarr-video

Do this for every mount point you create like radarr-video, etc.

Step 4: Sonarr container (ID 502)

Now everything is ready to go on the host so we need to create the LXC with the service. As always, go to TTeck's Helper Scripts to get the right script for creating the LXC. After installing Sonarr stop sonarr before making all these changes.

systemctl stop sonarr

For sonarr, the main program is run by a non-root user, sonarr:sonarr which has the IDs of 103:1000. We want to map that LXC user to the host sonarr:sonarr user. This is done through binding. Then we also need to map the NAS folder into the container. User 1505 is for mapping of the download folder owner sabnzbd. Edit the configuration file located at /etc/pve/lxc/502.conf on the host and add this to the end of the file:

lxc.idmap: u 0 100000 103
lxc.idmap: u 103 1502 1
lxc.idmap: u 104 100104 1401
lxc.idmap: u 1505 1505 1
lxc.idmap: u 1506 101506 64029
lxc.idmap: g 0 100000 1000
lxc.idmap: g 1000 1502 1
lxc.idmap: g 1001 101001 504
lxc.idmap: g 1505 1505 1
lxc.idmap: g 1506 101506 64029

mp0: /mnt/pve/sonarr-video/,mp=/mnt/sonarr-video
mp1: /mnt/pve/SSD/downloads/,mp=/mnt/SSD-downloads

Any time a change is made to the configuration file you'll need to reboot the container to get the changes to show up.

Sonarr User Updates

Add user sabznbd to each LXC as there is a directory to be shared across all the arrs for downloads. Then I also added the local arr user to the sabnzbd group for file access.

useradd -u 1505 -m -s /usr/bin/bash sabnzbd
usermod -aG sabnzbd sonarr

Sonarr folder locations and ownerships

For my specific case, I want my backup files of sonarr to be pointing to the same directory locations in this container when I restore from backup. In order to do that I need to make a symbolic link to the actual folders with the right ownership. That's why the media needs to be in /video. Otherwise you could point your sonarr to the specific /mnt folder.

mkdir /video
chown sonarr:sonarr /video
ln -s /mnt/SSD-downloads /downloads
chown -h sabnzbd:sabnzbd /downloads
sudo -u sonarr /usr/bin/bash
ln -s /mnt/sonarr-video/TV /video/TV
ln -s /mnt/sonarr-video/Kids\ TV /video/Kids\ TV

There's a chance that some of the sonarr directories will end up with the wrong ownership. Especially if sonarr was originally run as root. To fix this problem you can run the following chown commands:

chown -R sonarr:sonarr /var/lib/sonarr
chown -R sonarr:sonarr /usr/lib/sonarr

Sonarr.service update

Noting for reference that tteck wants to change from sonarr:sonarr user to root:root in the container. I don't want that so here are the notes to get it back if an update breaks everything.
/lib/systemd/system/sonarr.service

[Service]
User=sonarr
Group=sonarr

Restart Sonarr

After all the changes you can restart sonarr. I would also suggest rebooting the container to ensure everything is working properly.

systemctl daemon-reload
systemctl start sonarr

Step 5: Radarr container (ID 503)

After installing Radarr from tteck's Helper Scripts then stop radarr before making all these changes.

systemctl stop radarr

I want to get radarr running from a specific user:group and not root:root. Edit /etc/systemd/system/radarr.service:

[Service]
User=radarr
Group=radarr

Need to create the specific user and group in the container and also change the ownership of the radarr config files:

useradd -u 1500 -m -s /usr/bin/bash radarr
chown -R radarr:radarr /var/lib/radarr
chown -R radarr:radarr /opt/Radarr

Other than sonarr, I am going to keep 1500:1500 as the internal UID:GID as well as including the sabnzbd user. The updated 503.conf file on the host looks like this now and will be similar for the other arrs:

lxc.idmap: u 0 100000 1500
lxc.idmap: u 1500 1503 1
lxc.idmap: u 1501 101501 4
lxc.idmap: u 1505 1505 1
lxc.idmap: u 1506 101506 64029
lxc.idmap: g 0 100000 1500
lxc.idmap: g 1500 1503 1
lxc.idmap: g 1501 101501 4
lxc.idmap: g 1505 1505 1
lxc.idmap: g 1506 101506 64029
mp0: /mnt/pve/radarr-video/,mp=/mnt/radarr-video
mp1: /mnt/pve/SSD/downloads/,mp=/mnt/SSD-downloads

Radarr folder locations and ownerships

Tailor this just like you might have needed to in the sonarr section above.

mkdir /video
chown radarr:radarr /video
useradd -u 1505 -m -s /usr/bin/bash sabnzbd
usermod -aG sabnzbd radarr
ln -s /mnt/SSD-downloads /downloads
chown -h sabnzbd:sabnzbd /downloads
sudo -u radarr /usr/bin/bash
ln -s /mnt/radarr-video/Movies /video/Movies
ln -s /mnt/radarr-video/Kids\ Movies /video/Kids\ Movies

Step 6: Sabnzbd container (ID 505)

I only need to mount the downloads directory. I originally tried having the download directory on the NAS and it resulted in two additional copies of the file moving around the network which really slowed things down unnecessarily. So I changed to using an internal SSD which drastically sped up post-processing. Need to share a downloads folder across all the LXCs. This is a little different so I've added a sabnzbd user to all the LXCs and mapped it back to the host. Then added the local user to the sabnzbd group.The local download directory needs to be shared and accessible by all arr containers.

In the other LXCs run these commands (change radarr below):

useradd -u 1505 -m -s /usr/bin/bash sabnzbd
usermod -aG sabnzbd radarr
ln -s /downloads /mnt/SSD-downloads
chown -h sabnzbd:sabnzbd /downloads

Step 7: Prowlarr container (ID 504)

No remote folder mounting is needed for prowlarr so you can skip all the crazy user binding or folder mapping if you like. I the user binding so I can see the prowlarr user easily in a ps -aux command on the host. But it's really not needed. I created a prowlarr user on the LXC so I edited prowlarr.service like in the radarr container section above.

Error fixing:

I had to fix an ownership issues during this process (likely from not stopping the arr service before mucking around). I needed to end up mounting the file system on the host and changing permissions there because the LXC was kicking an error to change the owner of a number folders.

pct mount 504
---chown stuf---
pct unmount 504

[Chr1stian]

Great writeup @zelig2 , thanks! You seem knowledgeable about grouping and permissions, which I am trying to learn. I might try to copy this setup, but do you know of a easier way to get the right permissions on the folders that are mounted if all the users are root?
Its seems the versions I have installed with these scripts gave me all the *arr LXCs running with root user, and if its easier I might just keep it that way - its not a big security concern for me, as my network is closed.

[zelig2]

It is definately possible to reduce the complexity here. The first would be to know how the shared folders are mounted. If they are linked to the local host root user the you could do the binding like this:

lxc.idmap: u 0 0 1
lxc.idmap: u 1 100001 65534
lxc.idmap: g 0 0 1
lxc.idmap: g 1 100001 65534

Then each *arr container's root user will be mapped to the host root user. I personally think this is a bad idea even if you don't expose your system to the internet. At that point it's like you're not even running as containers anymore.

A second option could be to create one local host user that deals with NAS file sharing and map all the *arr root users to that account. That should reduce complexity.

[Chr1stian]

Thanks for getting back to me! I ended up just making the containers priviliged and mounted directly into them. This is going to be less prone to errors when I eventually get more Nodes and move VMs/CTs between them

[mastan30]

Hi @zelig2 I am facing issue with providing access to root user or another user access to an unprivilige dockge container, I have installed dockge unpriviliged container and added the following lxc id mapping but the mount is still showing under nogroup nobody access. Can you please help me with it?

my user uid and gid is 1000, checked it from /etc/passwd file and nobody group is 65534

lxc conf

lxc.idmap = u 0 100000 1000
lxc.idmap = g 0 100000 1000
lxc.idmap = u 1000 1000 1
lxc.idmap = g 1000 1000 1
lxc.idmap = u 1001 101001 64534
lxc.idmap = g 1001 101001 64534

subuid

root:1000:1
root:100000:65536
test:165536:65536

subgid

root:1000:1
root:100000:65536
test:165536:65536

[zelig2]

This has happened a few times to me and I think it's an order of operations issue but I'm not positive what causes it. In Step 7 above, my solution was to load the container file system in the host, change the ownership of the folder and then unmount the file system.

pct mount 104
chown -R 1000:1000 /var/lib/lxc/104/rootfs/mnt/directory
pct unmount 104

Then reboot the container.

[mastan30]

Hi @zelig2 Thanks for suggestion and quick reply, but I was able to finally do it another way. I was mounting the nas smb cifs drive using Proxmox UI which by default sets the uid and gid at root level. I needed to mount it using /etc/fstab by keeping the uid and gid to the user I want access and now I was able to access the smb share with write access in the Proxmox LXC and docker containers.

I used the below command to mount smb drive to proxmox in /etc/fstab/ file:

//192.168.X.XX/Path/to/share/ /path/to/mount/       cifs    noperm,iocharset=utf8,rw,credentials=/root/.storage_credentials,uid=1000,gid=1000,file_mode=0660,dir_mode=0770 0 0

then do nano /root/.storage_credentials
username=sambauser
password=sambauserspassword

This is the guide I followed and then followed the steps to modify the lxc conf using the proxmox documentation:

https://forum.proxmox.com/threads/how-to-automatically-mount-a-smb-share-on-an-lxc.118220/

LXC config to bind mounts to uid and gid:

https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

Hope this helps someone who is looking for Read/write access of SMB share in an unprivileged container.

[ottoman1384]

@zelig2 Thank you for the write up. I believe this is the most comprehensice write up I've found that should get me to where I need to be.

Unfortunately, I've tried so many things already that I am a little apprehensive to change much.

I am stuck on the 2nd step. Where you create a bunch of users on the host (pve) and then mention the below but don't mention how the new users are supposed to be written in - (sonarr:1502:100).

Next, add a line in /etc/subuid and /etc/subgid to account for these new users created above.

root:1501:100

I am also not sure where the root:1500:100 came from and how it relates to what we're doing.

Sorry if this is something super simple that is just going over my head.

Thank you, again!

[zelig2]

I'm not exactly sure what you're asking in your first question. I ran those commands in the pve host command line.

but don't mention how the new users are supposed to be written in - (sonarr:1502:100)

For your second question:

not sure where the root:1500:100 came from and how it relates to what we're doing

This part was definitely more vague than I liked as I was doing this work. To allow the host’s IDs to be passed into a container, you need to give permissions to a host user to do the mapping. Since root creates the container, the user root needs to be able to subuid / subgid for the users / groups that we are idmapping into the container. This is set by the files /etc/subuid and /etc/subgid. For my example above I'm allowing root to allow UIDs 1500-1599 to be mapped into the containers (I only need a few but I used a 100 because I'm lazy).

[ottoman1384]

You answered my question! Your last paragraph is exactly what I was looking for. I didn't understand what the 1501:100 signified but I get it now and it makes total sense.

I actually ended up just going back to my priveledged lxc running cockpit and NFS. I know it's a risk but I will eventually lock it down further with firewalls and specific IP access.