CRI-O currently attempts to use OverlayFS with user namespace ID mappings for OCI artifact mounts (introduced in commit ab3f85e), but this hits a kernel limitation.
According to Christian Brauner, OverlayFS supports two types of idmapped mounts:
Type-1: Mounting OverlayFS on top of idmapped layers (Supported)
Type-2: Idmapping OverlayFS itself (Not currently supported)

xref: https://lore.kernel.org/linux-unionfs/20250815150629.2097562-1-sohank2602@gmail.com/T/#u

Our current implementation attempts Type-2 by setting UIDMappings/GIDMappings directly on overlay mounts:

specgen.AddMount(rspec.Mount{
    Type:        "overlay",
    Source:      "overlay", 
    Destination: m.GetContainerPath(),
    Options:     []string{"lowerdir=" + mountPoint + ":" + imageVolumesPath},
    UIDMappings: getOCIMappings(m.GetUidMappings()),
    GIDMappings: getOCIMappings(m.GetGidMappings()),
})

This can cause fsconfig create 'overlay': Invalid argument errors when the kernel rejects the unsupported operation.

Christian mentioned that he actually implemented Type-2 support years ago, but it wasn't merged because:
It introduces complex "double translation" logic. There wasn't a compelling use case at the time.
CRI-O's OCI artifact mounting with user namespaces could be exactly the real-world use case needed to justify this kernel feature. Should we reach out to Christian Brauner with a concrete proposal?