NFS ID Mapping in Kubernetes

[johnsmyth]

I am mounting an NFS volume in my Kubernetes container. If I use the default runtimeClass, it works as expected - The file ownership is mapped to the users in the container, ie:

drwxr-xr-x 2 admin admin 4096 Aug 28 12:50 ./
drwxr-xr-x 3 root  root  4096 Aug 28 12:49 ../
-rw-r--r-- 1 admin admin    0 Aug 27 16:55 test2
-rw-r--r-- 1 admin admin   15 Aug 27 16:57 test3
-rw-r--r-- 1 admin admin    0 Aug 27 16:20 testfile

If I change only the runtimeClass to sysbox-runc, the file ownership is not mapped - Everything is owned by nobody:nogroup:

-rw-r--r-- 1 nobody nogroup    0 Aug 27 16:20 testfile
-rw-r--r-- 1 nobody nogroup   15 Aug 27 16:57 test3
-rw-r--r-- 1 nobody nogroup    0 Aug 27 16:55 test2
drwxr-xr-x 3 root   root    4096 Aug 27 16:59 ..
drwxr-xr-x 2 nobody nogroup 4096 Aug 27 16:57 .

I'm running in GKE, and using the Ubuntu with containerd (ubuntu_containerd) node type as was suggested in the docs, the kernel is version 5.15.0-1061-gke and shiftfs appears to be installed. The documentation suggests that with this kernel version and shiftfs the ID mapping should work. Any ideas?

[net00-1]

I also encountered this problem. I am using the same setup in GKE, and the log says this when the Sysbox pod starts up

setting up ID-mapped mount on path /var/lib/containers/storage/overlay/my/mount/path failed with Failed to set mount attr: invalid argument (likely means idmapped mounts are not supported on the filesystem at this path (nfs))

These are NFSv3 netapp volumes that I am connecting to the pod through PVC. They work on regular container setup. I found that only some types of volumes have been confirmed to work. Is this a limitation of GKE node linux kernel/volume type/shiftfs or something else?

[EddieX64]

Hello,
I'm having the same issue using GKE with Filestore NFSv3 instance as a PVC for our pods. Seeing the same error mentioned by @net00-1

setting up ID-mapped mount on path /var/lib/containers/storage/overlay/my/mount/path failed with Failed to set mount attr: invalid argument (likely means idmapped mounts are not supported on the filesystem at this path (nfs))

Because of this we are unable to use shared NFS volumes for our CI/CD pipelines. This limitation is unfortunately causing a slowdown in the overall execution of the pipelines.