Question about User Namespace ID Mapping with hostPath in Azure VM

General Discussions
,
1

Asking for help? Comment out what you need so we can get more information to help you!

Cluster information:

Kubernetes version: 1.33.2
Cloud being used: (put bare-metal if not on a public cloud)
Installation method: kubeadm
Host OS: Azure VM, ubuntu24.04, azure-linux-kernel: 6.11.0-1018-azure
CRI: crio 1.33.1

Question about User Namespace ID Mapping with hostPath in Azure VM

I’m running a Kubernetes cluster on an Azure VM and encountering an issue with user namespace ID mapping. Here’s my setup:

Environment:

  • Platform: Azure VM (Standard_B2s)
  • Virtualization: Hyper-V with Secure Boot + vTPM enabled
  • Kernel: linux-azure (6.11.0-1018-azure)
  • Kubernetes setup with user namespaces enabled

Configuration:

  • I have a pod with user namespaces enabled
  • Using hostPath to mount a folder from the host into the pod
  • The pod is configured to run with a non-root user

Observed Behavior:
When I check /proc/{$pod_PID}/mountinfo on the host, I see:

1783 1815 8:1 /home/user_name/nfs /mnt/nfs rw,relatime,idmapped - ext4 /dev/root rw,discard,errors=remount-ro,commit=30

Notice the idmapped flag is present, suggesting ID mapping should be active.

Problem:
However, when I create files inside the mounted folder from within the pod, and then check the file ownership on the host, the files show uid=0 gid=0 (root:root) instead of the expected mapped user ID.

Questions:

  1. Is this behavior normal/expected in Azure VM environments?
  2. Could this be related to Azure’s Hyper-V virtualization limitations on idmapped mounts?
  3. Are there known workarounds for achieving proper user ID mapping with hostPath mounts in Azure-based Kubernetes clusters?

Additional Context:
I’ve verified that:

  • User namespaces are properly configured (/proc/self/uid_map shows correct mappings)
  • The mount_setattr system call exists but returns EPERM when tested directly
  • Other namespace operations (network, PID) work correctly
  • This appears to be specific to Azure VM environment (Hyper-V with security features enabled)

Any insights on whether this is expected behavior or if there are alternative approaches would be greatly appreciated.

2

The UID of the files will be the user the container is running inside the userns. (Userns author here).

So, the process creating those files is running as UID 0 inside the container.

Is it possible that you made a mistake and it is running as root? At least the process that created that file?