Date: 2026-02-06
Use NFS exports (e.g. kryptovisor.auth.home.lan:/mnt/fastdata, ...:/mnt/bigdata) as backing storage for Kubernetes PVs/PVCs.
With sec=krb5p, read/write authorization is tied to Kerberos identities and the server must be able to map those identities to POSIX UID/GID. Kubernetes pods typically do not have user Kerberos tickets, so the cluster must rely on a deterministic machine/service identity that the server can map.
On every node that will mount NFS volumes:
rpc_pipefs is mounted.gssproxy and rpc-gssd.sec=krb5p and the server is reachable on TCP/2049.Quick checks:
systemctl is-active gssproxy rpc-gssd var-lib-nfs-rpc_pipefs.mount
findmnt -n /mnt/fastdata /mnt/bigdata -o SOURCE,OPTIONS
On the file server:
The common symptom when this is broken is:
Permission denied on IO./proc/net/rpc/nfs4.nametoid/content remains empty.Create dedicated roots for Kubernetes volumes:
/mnt/fastdata/k8s-pvcs/mnt/bigdata/k8s-pvcsThen dynamic provisioners can create per-claim subdirectories inside.
sudo -u ax_julian ls /mnt/fastdata >/dev/null
sudo -u ax_julian ls /mnt/bigdata >/dev/null
# Example: as the service identity you want Kubernetes to rely on
sudo -u k8s-nfs-access sh -c 'echo hi > /mnt/fastdata/k8s-pvcs/.write_test && rm -f /mnt/fastdata/k8s-pvcs/.write_test'
sudo -u k8s-nfs-access sh -c 'echo hi > /mnt/bigdata/k8s-pvcs/.write_test && rm -f /mnt/bigdata/k8s-pvcs/.write_test'
If this fails with Permission denied, PVCs will not be reliable until the server-side identity mapping is corrected.