LXC idmap bug

A

alegasalv

New Member
Oct 20, 2024
4
0
1
After applying the following configuration to an Alpine LXC, mapping uid & gid from 0(root) CT to 1070(nextcloud) host. All files ownerships are shifted 1 place!
What's going on here?

Code: 
lxc.idmap: u 0 1070 1
lxc.idmap: u 1 100000 65535
lxc.idmap: g 0 1070 1
lxc.idmap: g 1 100000 65535

Code: 
alpine-nextcloud:~# getent passwd
root:x:0:0:root:/root:/bin/sh
bin:x:1:1:bin:/bin:/sbin/nologin

Before
Bash: 
alpine-nextcloud:~# ls -las /
total 184
     8 drwxr-xr-x   19 root     root            20 Oct 20 18:59 .
     8 drwxr-xr-x   19 root     root            20 Oct 20 18:59 ..
    32 drwxr-xr-x    2 root     root            88 Oct 20 18:16 bin
     0 drwxr-xr-x    6 root     root           460 Oct 20 18:59 dev
    32 drwxr-xr-x   39 root     root            81 Oct 20 18:59 etc
     0 -rw-r--r--    1 root     root             0 Oct 20 18:59 fastboot
     0 drwxr-xr-x    2 root     root             2 Jan 26  2024 home
    32 drwxr-xr-x    9 root     root            48 Oct 20 18:16 lib
     0 drwxr-xr-x    5 root     root             5 Jan 26  2024 media
     0 drwxr-xr-x    3 root     root             3 Oct 20 18:30 mnt
     0 drwxr-xr-x    2 root     root             2 Jan 26  2024 opt
     0 dr-xr-xr-x  634 nobody   nobody           0 Oct 20 18:59 proc
     0 drwx------    2 root     root             5 Oct 20 18:17 root
     0 drwxr-xr-x    8 root     root           340 Oct 20 18:59 run
    32 drwxr-xr-x    2 root     root           114 Oct 20 18:16 sbin
     0 drwxr-xr-x    2 root     root             2 Jan 26  2024 srv
     0 dr-xr-xr-x   13 nobody   nobody           0 Oct 20 18:59 sys
     0 drwxrwxrwt    4 root     root             4 Oct 20 18:59 tmp
     8 drwxr-xr-x    9 root     root             9 Oct 20 18:16 usr
    24 drwxr-xr-x   12 root     root            14 Oct 20 18:16 var



After
Bash: 
alpine-nextcloud:~# ls -las /
total 184
     8 drwxr-xr-x   19 bin      bin             20 Oct 20 18:42 .
     8 drwxr-xr-x   19 bin      bin             20 Oct 20 18:42 ..
    32 drwxr-xr-x    2 bin      bin             88 Oct 20 18:16 bin
     0 drwxr-xr-x    6 root     root           460 Oct 20 18:42 dev
    32 drwxr-xr-x   39 bin      bin             81 Oct 20 18:42 etc
     0 -rw-r--r--    1 root     root             0 Oct 20 18:42 fastboot
     0 drwxr-xr-x    2 bin      bin              2 Jan 26  2024 home
    32 drwxr-xr-x    9 bin      bin             48 Oct 20 18:16 lib
     0 drwxr-xr-x    5 bin      bin              5 Jan 26  2024 media
     0 drwxr-xr-x    3 bin      bin              3 Oct 20 18:30 mnt
     0 drwxr-xr-x    2 bin      bin              2 Jan 26  2024 opt
     0 dr-xr-xr-x  623 nobody   nobody           0 Oct 20 18:42 proc
     0 drwx------    2 bin      bin              5 Oct 20 18:17 root
     0 drwxr-xr-x    7 root     root           320 Oct 20 18:42 run
    32 drwxr-xr-x    2 bin      bin            114 Oct 20 18:16 sbin
     0 drwxr-xr-x    2 bin      bin              2 Jan 26  2024 srv
     0 dr-xr-xr-x   13 nobody   nobody           0 Oct 20 18:42 sys
     0 drwxrwxrwt    4 bin      bin              4 Oct 20 18:42 tmp
     8 drwxr-xr-x    9 bin      bin              9 Oct 20 18:16 usr
    24 drwxr-xr-x   12 bin      bin             14 Oct 20 18:16 var
 
Last edited:
You are mapping:
- uid 1 in the ct to uid 100000 on the host
- uid 2 in the ct to uid 100001 on the host
- ...

What you actually want is:
- uid 1 in the ct to uid 100001 on the host
- uid 2 in the ct to uid 100002 on the host
- ...

To fix this, change your mapping configuration to this:
Code: 
lxc.idmap: u 0 1070 1
lxc.idmap: u 1 100001 65534
lxc.idmap: g 0 1070 1
lxc.idmap: g 1 100001 65534
 
Thanks for your answer

You are mapping:
- uid 1 in the ct to uid 100000 on the host
- uid 2 in the ct to uid 100001 on the host
- ...
Click to expand...
yes, but that's ok.
lxc.idmap: u 0 1070 1
lxc.idmap: u 1 100001 65534
lxc.idmap: g 0 1070 1
lxc.idmap: g 1 100001 65534
Click to expand...

Also this is missing one uid/gid mapping.

Nevertheless, I just tried your code and still doesn't work.
 
Oh, I see. You are remapping the root user of the container, which causes problems.
Instead, you can map a separate user in the container to UID 1070 on the host.

Here is an example where UID and GID 1010 in the container are mapped to UID and GID 1070 on the host:
Code: 
lxc.idmap = u 0 100000 1010
lxc.idmap = u 1010 1070 1
lxc.idmap = u 1011 101011 64525
lxc.idmap = g 0 100000 1010
lxc.idmap = g 1010 1070 1
lxc.idmap = g 1011 101011 64525

If this still does not help, please elaborate on what specifically does not work
 
Thanks, but that doesn't help me.

I will try to explain the problem better.
I’m experiencing an issue with user and group ID mapping in a Proxmox LXC container, where UID/GID changes unexpectedly for files in the container's root directory.

I have a container running a service as root user and I want to give this service rw access to a folder which is mounted in the pve-node:

15 drwxr-xr-x 4 radarr radarr 19 Oct 22:44 data

So I did:

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

This should theoretically map the container’s root user to UID 1070 on the host, while other container UIDs and GIDs map to unprivileged ranges (100001 and beyond) on the host.
But when inspecting the container’s root directory after applying this configuration, I notice that files and directories owned by root unexpectedly show daemon as the owner instead. There appears to be a UID shift of +1 for certain files and directories, which affects permissions and ownership of folders inside the container.

Code: 
root@radarr:~# ls -las /
total 81
 9 drwxr-xr-x  17 daemon root     22 Oct 26 21:51 .
 9 drwxr-xr-x  17 daemon root     22 Oct 26 21:51 ..
 1 -rw-------   1 daemon root     10 Oct 26 21:51 .bash_history
 1 lrwxrwxrwx   1 daemon root      7 Oct 10  2023 bin -> usr/bin
 1 drwxr-xr-x   2 daemon root      2 Sep 29  2023 boot
 0 drwxr-xr-x   6 root   root    480 Oct 26 21:51 dev
 9 drwxr-xr-x  64 daemon root    142 Oct 27 13:03 etc
 1 drwxr-xr-x   2 daemon root      2 Sep 29  2023 home
 1 lrwxrwxrwx   1 daemon root      7 Oct 10  2023 lib -> usr/lib
 1 lrwxrwxrwx   1 daemon root      9 Oct 10  2023 lib64 -> usr/lib64
 1 drwxr-xr-x   2 daemon root      2 Oct 10  2023 media
 1 drwxr-xr-x   4 daemon root      4 Jul  5 01:29 mnt
 1 drwxr-xr-x   3 daemon root      3 Jun 24 18:12 opt
 0 dr-xr-xr-x 666 nobody nogroup   0 Oct 26 21:51 proc
 9 drwx------   4 root   root      9 Oct 26 21:51 root
 0 drwxr-xr-x   9 root   root    320 Oct 26 21:51 run
 1 lrwxrwxrwx   1 daemon root      8 Oct 10  2023 sbin -> usr/sbin
 1 drwxr-xr-x   2 daemon root      2 Oct 10  2023 srv
 0 dr-xr-xr-x  13 nobody nogroup   0 Oct 26 21:51 sys
25 drwxrwxrwt   3 root   root      6 Oct 27 09:31 tmp
 9 drwxr-xr-x  12 daemon root     12 Jun 24 18:11 usr
 9 drwxr-xr-x  11 daemon root     13 Oct 10  2023 var

Without the custom UID mapping, the container’s root user correctly retains ownership over files and directories in the root filesystem.

Code: 
root@radarr:/# ls -las /
total 81
 9 drwxr-xr-x  17 root   root     22 Oct 27 13:10 .
 9 drwxr-xr-x  17 root   root     22 Oct 27 13:10 ..
 1 -rw-------   1 root   root     10 Oct 26 21:51 .bash_history
 1 lrwxrwxrwx   1 root   root      7 Oct 10  2023 bin -> usr/bin
 1 drwxr-xr-x   2 root   root      2 Sep 29  2023 boot
 0 drwxr-xr-x   6 root   root    480 Oct 27 13:10 dev
 9 drwxr-xr-x  64 root   root    142 Oct 27 13:10 etc
 1 drwxr-xr-x   2 root   root      2 Sep 29  2023 home
 1 lrwxrwxrwx   1 root   root      7 Oct 10  2023 lib -> usr/lib
 1 lrwxrwxrwx   1 root   root      9 Oct 10  2023 lib64 -> usr/lib64
 1 drwxr-xr-x   2 root   root      2 Oct 10  2023 media
 1 drwxr-xr-x   4 root   root      4 Jul  5 01:29 mnt
 1 drwxr-xr-x   3 root   root      3 Jun 24 18:12 opt
 0 dr-xr-xr-x 685 nobody nogroup   0 Oct 27 13:10 proc
 9 drwx------   4 nobody root      9 Oct 26 21:51 root
 0 drwxr-xr-x  13 root   root    440 Oct 27 13:10 run
 1 lrwxrwxrwx   1 root   root      8 Oct 10  2023 sbin -> usr/sbin
 1 drwxr-xr-x   2 root   root      2 Oct 10  2023 srv
 0 dr-xr-xr-x  13 nobody nogroup   0 Oct 27 13:10 sys
25 drwxrwxrwt   6 nobody root      9 Oct 27 13:10 tmp
 9 drwxr-xr-x  12 root   root     12 Jun 24 18:11 usr
 9 drwxr-xr-x  11 root   root     13 Oct 10  2023 var

So I want to understand if this expected or not. And if so, how can I give the root user of the CT access to a folder in the host by another user.
 
Solution (Workaround)

I found a workaround that eliminates the need to manually add idmap entries to the container's config. Instead, I set the mappings as follows:

Code: 
Host_UID = CT_UID + 100000
Host_GID = CT_GID + 100000

This approach bypasses the need to specify idmap` configurations directly.

Related Issues

Someone else reported a similar issue, but unfortunately, no resolution was provided in that discussion.

However, I noticed that whenever I remap UIDs, files already created inside the container will appear owned by a different UID and GID on the host. This means I need to change ownership to match the container's mappings after any remap. For guidance on this, see this post on the Proxmox forum.

Bonus

I also discovered a helpful tool called lxc-idmap which automates UID/GID mapping and minimizes errors—a frequent issue I encountered when manually setting mappings.
 
You must log in or register to reply here.

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!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom