Idmaps on incus container

Hi all

I need some help to understand potential issue I face.
I have a new server and I made a fresh install of Debian Trixie and incus with the Zabbly repo.

After the installation, I create my first container based on the Debian trixie and i see that the rootfs and all file created with the host root uid/sid

sudo ls -al /var/lib/incus/containers/test/
total 8
d--x------ 1 root root   78 17 janv. 19:37 .
drwx--x--x 1 root root   70 17 janv. 19:37 ..
-r-------- 1 root root 3547 17 janv. 19:37 backup.yaml
-rw-r--r-- 1 root root  529 17 janv. 06:31 metadata.yaml
drwxr-xr-x 1 root root  132 17 janv. 06:31 rootfs
drwxr-xr-x 1 root root   42 17 janv. 06:31 templates
sudo ls -al /var/lib/incus/containers/test/rootfs/
total 16
drwxr-xr-x 1 root root  132 17 janv. 06:31 .
d--x------ 1 root root   78 17 janv. 19:37 ..
lrwxrwxrwx 1 root root    7  2 janv. 13:35 bin -> usr/bin
drwxr-xr-x 1 root root    0  2 janv. 13:35 boot
drwxr-xr-x 1 root root    0 17 janv. 06:31 dev
drwxr-xr-x 1 root root 1584 17 janv. 06:31 etc
drwxr-xr-x 1 root root    0  2 janv. 13:35 home
lrwxrwxrwx 1 root root    7  2 janv. 13:35 lib -> usr/lib
lrwxrwxrwx 1 root root    9  2 janv. 13:35 lib64 -> usr/lib64
drwxr-xr-x 1 root root    0 17 janv. 06:24 media
drwxr-xr-x 1 root root    0 17 janv. 06:24 mnt
drwxr-xr-x 1 root root    0 17 janv. 06:24 opt
drwxr-xr-x 1 root root    0  2 janv. 13:35 proc
drwx------ 1 root root   38 17 janv. 06:25 root
drwxr-xr-x 1 root root    0 17 janv. 06:26 run
lrwxrwxrwx 1 root root    8  2 janv. 13:35 sbin -> usr/sbin
drwxr-xr-x 1 root root    0 17 janv. 06:24 srv
drwxr-xr-x 1 root root    0  2 janv. 13:35 sys
drwxrwxrwt 1 root root    0 17 janv. 06:25 tmp
drwxr-xr-x 1 root root   94 17 janv. 06:24 usr
drwxr-xr-x 1 root root   90 17 janv. 06:24 var

I checked my file subuid and subguid without see any issue

cat /etc/subuid
manchot:100000:65536
manchotadm:165536:65536
root:1000000:1000000000
root:1001:1

cat /etc/subgid
manchot:100000:65536
manchotadm:165536:65536
root:1000000:1000000000
root:1001:1

Container config if it’s necessary

incus config show test 
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Debian trixie amd64 (20260117_05:24)
  image.os: Debian
  image.release: trixie
  image.serial: "20260117_05:24"
  image.type: squashfs
  image.variant: default
  volatile.apply_template: create
  volatile.base_image: 41506f0145c43eb8f741f0249be54f193d204fd6e1e4b1b412825650eea6bfc8
  volatile.cloud-init.instance-id: 9b48418e-2f5b-4f7e-9a00-9600ae6b70a4
  volatile.enp1s0.hwaddr: 10:66:6a:4e:d7:f6
  volatile.enp1s0.name: eth0
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
  volatile.uuid: 98a93fcd-523e-451f-82fd-8b033af17a0e
  volatile.uuid.generation: 98a93fcd-523e-451f-82fd-8b033af17a0e
devices: {}
ephemeral: false
profiles:
- base
stateful: false
description: ""

Base profile

incus profile show base
config:
  boot.autostart: "true"
  limits.memory: 500MB
  limits.memory.enforce: soft
  limits.memory.swap: "true"
  limits.memory.swap.priority: "6"
  security.nesting: "true"
  snapshots.expiry: 1w
  snapshots.pattern: backup-%d
  snapshots.schedule: '@daily'
  snapshots.schedule.stopped: "false"
description: Base template profile
devices:
  enp1s0:
    nictype: bridged
    parent: brincus0
    type: nic
  root:
    path: /
    pool: containers
    type: disk
name: base
used_by:
- /1.0/instances/test
project: default

Could you please help me to understand the issue and how to correct it because for me normally the rootfs folder need to have uid:gid 1000000 for the unpriviledge container with this configuration…

Thank you

That’s normal, on newer kernels we don’t need to physically rewrite the uid/gid of every single inode, we can just tell the kernel to perform uid/gid mapping for us into the container. That’s a lot more efficient and a lot less likely to cause corruption during remapping.