[SOLVED] ONE OPTION: the chronic permissions flail on mounted drives / mount points and 97 threads and options

G

grottoguy

New Member
Jun 7, 2025
29
3
3
Argh.
I hate to add to the pile of permission related funk around PBS unprivileged lxc's trying to use a mounted USB drive from the proxmox host.
But I've got a usb drive mounted in my proxmox host, and configured as a mount point in the /etc/pve/lxc/xxx.conf file using the mp parameters.

While I can create files in the PBS server lxc as root, when I try to add the mountpoint as a datastore, I get the dreaded eperm.
So I realize I'm in the chronic flail of the nobody/nogroup mapping.

I don't even have a perfect question formulated, but I think basically I'm worn out re-reading and trying to compare dates and evaluate the quality of the threads and documentation out there...

I've seen numerous other people flail over this, and also see conflicting data about whether this can all be done through the gui or not, etc.

I am surprised there isn't a fresh FAQ on this in the PBS documentation, seems like it could make the cut... The doc related to unprivileged containers (see below) is 4 years untouched, and seems to at least be behind the news of gui functionality available since then.

It seems like the 'right' method is to do id mapping from the host to the lxc.
I've seen threads where adding uid/gid to the mp parameters are supposed to work and seem like a simple solution- but is that in the /etc/fstab for the proxmox host, or in the lxc config file where the mp is defined? I've gotten neither to work, can't see where the uid parameters are valid even though I've found multiple references to it, and seems like that would be easy...

I've also seen the rather convoluted id.mapping option threads, but I haven't actually tried it because it seems rather clunky, and it worries me that this document (unlike many related threads) seems to be 4 years old (see below).

https://pve.proxmox.com/mediawiki/index.php?title=Unprivileged_LXC_containers&action=history

I also feel like I've found so many conflicting 'solutions' that my head's a little dizzy; is that the latest and greatest doc about this topic? Is there another better source of truth on best practice / simple solution?

So all that said, I'm not proud of this post, but I feel like I've gone through this and around and around for a couple days now, and am not trusting the data sources I keep re-reading.

If anybody can point at the most current 'source of truth' on how to do this most properly (i.e., not by giving the container privileges, etc), that would be great.

It seems pretty whacky that I can so easily have the storage available to the container, and that the container root can create files on it, but it's a multi day crazy hunt to figure out how to allow a different local user to have access as the pbs server user.

Thanks for reading, sorry for this, but I know I'm not alone in flailing through it.
 
IMHO, using an unprivileged LXC for PBS doesn't make sense. The isolation that provides an unprivileged container is of no use in this use case. I mean, I don't expect PBS processes to misbehave or become malware that may try to get out the LXC via the host's kernel and try to break havoc in the host. You can perfectly use a privileged LXC or even install PBS alongside with PVE.
 
  • Like
Reactions: Johannes S
VictorSTS said:
IMHO, using an unprivileged LXC for PBS doesn't make sense. The isolation that provides an unprivileged container is of no use in this use case. I mean, I don't expect PBS processes to misbehave or become malware that may try to get out the LXC via the host's kernel and try to break havoc in the host. You can perfectly use a privileged LXC or even install PBS alongside with PVE.
Click to expand...
That's a great point, especially since it's on the same host with other targets that are more of an issue (i.e., are more logically unprivileged), etc.
I've read it's better to have the PBS separate entirely, but I have 2 sites, so I'll be doing local PBS in both locations and then either replicating or backing up to the other location as well.

Thanks very much for pointing out my somewhat blinded allegiance to the premise of the unprivileged container...

It's a quite logical option for my circumstances in particular.

I think this topic still needs a good refresh at least- I've been thrilled with this entire proxmox universe, but this particular topic has been a surprising roadblock that shouldn't be so confusing to sort through.

But I'll leave it here and go with your suggestion for myself...

Thanks!
 
Try to get PBS in a completely different machine to ease the recovery when the PVE host(s) fail, at least the one on the "main" site. That would also completely workaround the permissions issue. Remember that you can also use a Virtual Machine and use USB or full disk pass through to get the VM access the disk directly. There are many other options which IMHO are better than an LXC for a PBS.
 
grottoguy said:
That's a great point, especially since it's on the same host with other targets that are more of an issue (i.e., are more logically unprivileged), etc.
I've read it's better to have the PBS separate entirely, but I have 2 sites, so I'll be doing local PBS in both locations and then either replicating or backing up to the other location as well.

Thanks very much for pointing out my somewhat blinded allegiance to the premise of the unprivileged container...

It's a quite logical option for my circumstances in particular.

I think this topic still needs a good refresh at least- I've been thrilled with this entire proxmox universe, but this particular topic has been a surprising roadblock that shouldn't be so confusing to sort through.

But I'll leave it here and go with your suggestion for myself...

Thanks!
Click to expand...
Here's a sad deja vu from 2021...

J

Thread 'Mapping single uid/gid to unprivileged LXC container'

I'm loathe to post this asking for help because there are already several threads about uid/gid mapping for an unprivileged LXC container (believe me, I've read and re-read them all!), and there's even @DougD's python script to automate the process.. so I feel really dumb... but I've been trying for months and I can't seem to figure out the mapping for my use case with just a single user (root):

Host: root
Debian 10 CT: root

This doesn't work, but it's as close as I've gotten:
Code: 
# /etc/pve/lxc/100.conf
lxc.idmap = u 0 100000 1
lxc.idmap = g 0 100000 1
lxc.idmap = u 0 0 1...

And a more recent from 2025...

X

Thread 'Understanding LXC UID Mappings'

Reading the Unprivileged LXC containers wiki page, it seems UID mappings are needed in the LXC config files to allow permissions for mount points. I thought that the >100000 range of host ids was already mapped to the CT starting with id 0 when you create a new unprivileged CT. Why does the documentation say I need to map all those IDs instead of just the one I need to have permission if they are already mapped?
Code: 
# uid map: from uid 0 map 1005 uids (in the ct) to the range starting 100000 (on the host), so 0..1004 (ct) → 100000..101004 (host)
lxc.idmap = u 0 100000 1005
lxc.idmap =...

I share these only for others hunting and to perhaps inoculate myself from jabs going forward, ha!

I concur with one of the people's points in here- it seems like there should be a simpler way to do a simple one user bind in the id mapping option.

Even better / cleaner, I would propose 'bind as uid' that works in the lxc.conf (that would be very clean and simple, not sure why it doesn't seem to work for me), which would also maintain the security goal.

And holy shamoley. Maybe 3 times is the charm (3rd morning looking at this).

It violates my rational thought just a tad, but it keeps the unprivileged container option, is a 1 command 'fix', and just allowed me to create the dang datastore that I've been unable to do until now.

Rather than the elaborate (and overly comprehensive) id mapping, and without the ability to set the UID in the bind mount function itself, a sort of hacky but not at all bad option is just to blindly change the ownership and group of the mount on the proxmox host by adding 100000 to whatever the actual desired / an acceptable user id on the lxc container is.

It bugs me because that uid doesn't exist on the proxmox host, and it wouldn't work as cleanly if there were any intent to use the storage in the host itself. But in my case, my #1 goal is the PBS servers being able to use the storage, so for now it's a great option for me.

I'll post once more at the end to offer this as a 'solution' for others...
 
For my circumstances, main goal is backup- chown of the proxmox host mount / drive to backup was one suggestion, but it still ran into the offset UID issue faced by unprivileged containers (where they are rendered unprivileged users by bumping their uid's up).

But just ran into a reddit or something, already lost it, where somebody suggested just blindly adding the 100k to the ownership id on the proxmox host.

I'd seen that before in my googling (I think), but it had bothered me in the sense of creating a new user on the host for no good reason (vs mapping).

But having flailed with the effort to map for multiple days and not liking those options, I was about to follow the commenter's advice and privilege the container, but did one last thing that only slightly disturbed me:

chown 100034:100034 /mnt/[myusbdrive]

on the proxmox host- then as before, I was able to create a file in the lxc as root.
However, unlike before, I was able to use the pbs web gui (and presumably the cli but didn't do it that way) to add the datastore without running into the EPERM.

So unless I find something goes haywire downstream when I ask the process to actually write some backups, I think this is a good long term option for me & my circumstances.
(Just ran my first backup against the datastore and confirmed it succeeded).

Again, if I were working on the same storage from the proxmox host itself, I guess I'd consider making an account with the weird #'d user id but I suspect I'd then be forced to do the user mapping stuff all over again (that other people have died trying to make work, ha!).

Good luck to everybody else wrestling with this- for me it's a good simple clean option that is only slightly disturbing when viewed from the proxmox host perspective.
 
Last edited:
IMHO all are misuses of an unprivileged LXC: it exists to isolate the LXC from the host as much a possible and that's why it is hard to "un-isolate" the LXC from the host. As simple as that. In this very case of a PBS, an unprivileged LXC adds nothing but headaches (but you already noticed that!). I might be missing some use case were it is useful, would love to know it.

Even if you manage to map id's, change owner, add ACLs or whatever trick may be used you are reducing the security both the host and every other LXC. Say some other LXC creates a user with id 100034, somehow circumvents apparmor and ends up accessing host files would have access to your PBS datastore.

Thanks for the links and all.
 
I definitely get your point as well.
A random user id would help obfuscate a little from another lxc perhaps. Always layers upon layers of security to help.
I actually missed your earlier post until just now about a separate box for pbs.
I will probably migrate to that- for now I'll have 2 PBS lxc's on two remote hosts, use it for local and remote backups which should help with some of what you pointed out / the general guidance about separating your PBS.
I'll probably end up getting even wimpier little boxes dedicated to just PBS standalone with their own storage...

Re the use case, it's not really a proactive use case; it's more that I've just started growing my stack, likely will land with 2 separate pbs hosts.
I just dipped into proxmox a month or so ago with a single box to see how it did, and then I've added two for my internal stuff at the moment which is where I'm temporarily putting the PBS servers (and testing them vs regular PVE backup as well).

Lots of options to sort through, for now I want to at least preserve what I have.


Thanks very much for your posts!
 
grottoguy said:
I definitely get your point as well.
A random user id would help obfuscate a little from another lxc perhaps. Always layers upon layers of security to help.
I actually missed your earlier post until just now about a separate box for pbs.
I will probably migrate to that- for now I'll have 2 PBS lxc's on two remote hosts, use it for local and remote backups which should help with some of what you pointed out / the general guidance about separating your PBS.
I'll probably end up getting even wimpier little boxes dedicated to just PBS standalone with their own storage...

Re the use case, it's not really a proactive use case; it's more that I've just started growing my stack, likely will land with 2 separate pbs hosts.
I just dipped into proxmox a month or so ago with a single box to see how it did, and then I've added two for my internal stuff at the moment which is where I'm temporarily putting the PBS servers (and testing them vs regular PVE backup as well).

Lots of options to sort through, for now I want to at least preserve what I have.
Click to expand...
One other thought- I plan to do the PBS server backups themselves to the remote PBS, so that ideally I'll always have a separated server and backups to restore from (assuming one of two sites is up). Somewhere in there I'll throw an NFS share for another copy of things as well. Not sure what I think about clustering yet, HA may be a bit overkill for my purposes.
grottoguy said:
Thanks very much for your posts!
Click to expand...
 
OK this is truly sad and embarrassing.
In my little saga I have recently added TrilliumNext to do documentation, but apparently didn't do it soon enough or with enough fidelity.

In comparing my two ProxMox hosts and their fleet of LXC's including their own PBS, I have realized that a couple weeks back, on the first location, I somehow managed to set up the USB drive and make 500Gb of it (total of 2 TB) accessible as a datastore to the PBS, and successfully wrote some backups. Apparently it was so easy that time that I didn't document it for the next time, which is what this thread was all about, where I somehow couldn't get it made available to PBS with correct permissions.
So now I'm trying to retrace my steps with the first host & PBS instance to see what of the many ways to do this stuff I used, as it seems to have worked flawlessly.
But as an example, I now need to figure out when/where I defined a 500gb slice of the 2 TB, as it wasn't by partition (there is only 1 large partition). So I'm still confused, but hopefully will find my way back through the comedy of my journey and land in a good spot.
Just for walking around in case anybody else is stumbling.
In the first instance, my lxc conf looks like this, and I did no editing myself in the file:

hostname: proxmox-backup-server
memory: 2048
mp2: cave_usb_2tb:102/vm-102-disk-0.raw,mp=/mnt/cave_usb,backup=1,size=500G
net0: name=eth0,bridge=vmbr0,hwaddr=BC:24:11:33:25:11,ip=dhcp,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-102-disk-0,size=80G
swap: 512
tags: backup;community-script
unprivileged: 1

So somehow I made a successful mount point (mp2) using the webGUI, and defined the datastore size as a starter size of 500.

When I went to do the second one a few weeks later, somehow this all eluded me, and I went down the crazy rabbit trail of permissions and editing the lxc config file, etc, etc, .

So I gotta figure out how I got the first model in place and replicate it.

Laughing is encouraged and mockery is acceptable but keep it civil.
 
OK, last post on the matter.
I managed to find just enough notes in my Trillium to retrace my steps...

Rather than be all tangled up with the USB pass through / mount / mismatched permissions / etc, it looks like the first instance I did was

1 mount the usb at the pve host
2 then create a shared directory in the datacenter webgui using the mountpoint you set up as the location

3 then go to the pbs pve admin / resources and create a mount point and size targeting that newly visible disk that shows up as 'storage' (see below)
4 then you can add a datastore that points at that mount point in the PBS server admin (the gui for that app)

No editing of files needed, no permissions flail, etc.

Last post unless I find I've tricked myself again and am actually writing to the LVM underneath or some such BS as that.
Or if somebody points out that I've completely gone in circles and am entirely confused.
This does mean that this storage will be shared by more than 1 lxc (in my case , 2 pbs server), and not separated as separate partitions at the moment, so that's something to realize.. Sort of a 'size' partition rather than a real partition, as defined by the size parameter in the mount point def...




1752259330339.png
 
You must log in or register to reply here.
Top Bottom