[SOLVED] Changing the default lxc uid/gid mapping

[commander_fett]

Instead of the default lxc idmap (u/g 0 100000 65536), I'd like to use a different range as the default mapping for containers. I changed /etc/subuid and /etc/subgid to reflect the ranges I want, but I can't find anything on how I would configure proxmox to create containers with the new ids instead of [100000,165536). As a result, I get the following error when I try to create an lxc container in the proxmox gui:

extracting archive '/var/lib/vz/template/cache/ubuntu-22.04-standard_22.04-1_amd64.tar.zst'
lxc 20220531090123.868 ERROR    conf - conf.c:lxc_map_ids:3668 - newuidmap failed to write mapping "newuidmap: uid range [0-65536) -> [100000-165536) not allowed": newuidmap 2264132 0 100000 65536
Failed to write id mapping for child process
lxc 20220531090123.868 ERROR    utils - utils.c:lxc_drop_groups:1363 - Operation not permitted - Failed to drop supplimentary groups
lxc 20220531090123.868 ERROR    utils - utils.c:lxc_switch_uid_gid:1338 - Invalid argument - Failed to switch to gid 0
TASK ERROR: unable to create CT 100 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar xpf - --zstd --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' -C /var/lib/lxc/100/rootfs --skip-old-files --anchored --exclude './dev/*'' failed: exit code 1

Adding the lxc.idmap lines to /etc/lxc/default.conf had no effect, and I haven't been able to find any information on how to configure the idmap used by proxmox in the initial lxc creation. Is it possible to change this, or is the only option to restore the original subuid / subgid ranges and manually set up the id mappings in /etc/pve/lxc/<container>.conf?

 

[fabian]

currently only this is supported:

manually set up the id mappings in /etc/pve/lxc/<container>.conf?

which requires manually fixing up any existing files/dirs that have the wrong uid/gid. backup/restore as root should then preserve the mappings (there was a bug that affected some setups), although we've recently discussed making the idmaps proper options that are supported on creation (and also allow changing the maps on restore then).

 

[commander_fett]

currently only this is supported:



which requires manually fixing up any existing files/dirs that have the wrong uid/gid. backup/restore as root should then preserve the mappings (there was a bug that affected some setups), although we've recently discussed making the idmaps proper options that are supported on creation (and also allow changing the maps on restore then).

Alright, thanks for the help. Manual it is. Setting idmaps on creation and restore would be a lovely feature, though

 

[zoomzoom]

@fabian I'm running into this same issue.

To support the id mapping, I've changed /etc/subuid and /etc/subgid to this:

```
root:1000:1
root:100000:1000
root:101001:64536
```

But when I try to create a new container I hit the same error as OP wrote above.

If I subsequently change /etc/subuid and /etc/subgid to this:

```
root:100000:65536
```

I can then create the new container.

Is there something I'm missing here? Is there a way of doing the id substitution AND continue to be able to create new containers? Or do I always need to revert the subuid/subgid settings to create a new container?

Thanks!

 

[fabian]

/etc/subid and /etc/subgid don't specify the mapping, just the allowed ranges for mappings. so having

root:1000:1
root:100000:65536

should be fine and allow creation of a container, and then subsequent adding of the 1000 mapping to the already created container. the issue in this thread is that such a custom mapping including 1000 is then in turn not handled well on backup an restore..