Description

This was reported by Mike Beaumont in the k8s slack: https://kubernetes.slack.com/archives/C0BP8PW9G/p1769162383724379

The root cause of the issue is that you can't idmap a mounted overlayfs, like the image source is. To idmap an overlayfs you need to idmap each of the lower layers. This is indeed what we are using for the rootfs.

It seems support for OCI image source was added here: #10579.

In particular, it seems to get the mount for the image here. But it doesn't set the uidmap/gidmap options in mount struct. If it did, then the overlayfs will be mounted properly, doing an idmap of each of the lower layers.

It seems that function doesn't have access to the mappings, so it should probably be modified to have them.

Then, if the mappings are added there, it should work. As if the options are set, the overlay will use them for the lower layers:

@wzshiming You did the PR to support OCI image as a source, can you have a look at fixing this issue?

Steps to reproduce the issue

I'll let the slack user to fill these.
1.
2.
3.

Describe the results you received and expected

We got:

Warning  Failed     6s (x2 over 6s)  kubelet            spec.containers{xxx}: Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: failed to fulfil mount request: failed to set MOUNT_ATTR_IDMAP on /run/containerd/io.containerd.grpc.v1.cri/image-volumes/025bdaf4b9484f9ce7b82ced2e291f9108935a390f89dda50388b82fe6bc233a/eeca853b14cafcc6490f3fbfa4253b909f88556ae59fb81fd3284e48647b7567: invalid argument (maybe the filesystem used doesn't support idmap mounts on this kernel?)

We expect the container to start just fine.

What version of containerd are you using?

containerd 2+

Any other relevant information

No response

Show configuration if it is related to CRI plugin.

No response