lxc.idmap differing from 100000

Jul 3, 2020
23
1
8
47
Hi,

for better auditing what's happening in our containers I'd like to change their idmaps to distinct values. Besides their filesystems, is there something I'd need to consider doing so? Will it break PVE and result in a flaming pile of hardware?

Bests,
Masin
 
I found out, I had to change the config in /etc/pve/lxc/<vmid>.conf instead of /var/lib/lxc/<vmid>/config.

But while doing so, I seem to have broken something. First I couldn't start my test container as LXC couldn't acquire access to my chosen idmap
Code:
lxc.idmap = u 0 200000 65536
lxc.idmap = g 0 200000 65536
.

After adding my idmap range in /etc/subuid and /etc/subgid, LXC accepted the config and started the container but I cannot start it using pct. Instead I get these errors:
Code:
root@appserver3:~# pct start <vmid> --debug=1
problem with monitor socket, but continuing anyway: got timeout

get_rundir: 261 HOME isn't set in the environment
Failed to create lock for <vmid>
main: 242 Failed to create lxc_container
_rundir:261 - HOME isn't set in the environment
ERROR    lxc_start - tools/lxc_start.c:main:242 - Failed to create lxc_container

Actually, I cannot start any container anymore, with this same error. And I cannot find any information on this. The error message is generated in this file at line 263 shortly after the check for XDG_RUNTIME_DIR which it obviously passes but which also is the only context with which I can find results in the web.

The only action using the regular Proxmox toolkit I can remember which resulted in an error was my attempt to clone a container snapshot while I've been in the directory of the destination <vmid>. Rsync failed, but after leaving and removing the directory, the repeated attempt completed successfully. Interestingly, when starting the container via lxc-start -n <vmid> (after having mounted it's rootfs partition), it works without error and with every container I tried but failed using pct.

Oh, there was another massive action I had to make: I had to kill an lxc-start -F while debugging the container launch. Couldn't figure out how to stop the container until after I kill'ed it. Yeah, don't laugh at me, please. I didn't think of lxc-stop :-D.

Finally, even undoing all I could undo didn't help me with starting containers again using pct (or the web UI). Any hints?
 
Oh, well. For what it's worth: The problem disappeared after rebooting. Maybe just restarting the lxc service might have sufficed but Iused the opportunity to update to 6.4 and then to 7.0. Mostly without problems (only a Debian 8 container requires cgroups v1 and didn't work after first reboot). Whatever caused the problem, it's no permanent issue at least.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!