I'm running a K3s cluster on Raspberry Pis and want to mount directories from a UGREEN DXP6800 Pro NAS into pods. I'm using the Kubernetes NFS CSI driver with NFSv3, manually defined PersistentVolumes and PersistentVolumeClaims, and ReadWriteMany access.
The mounts work initially, but after roughly a day they start failing with permission errors. I then have to remove the PVs, PVCs, and related services before things work again. The NAS directories appear to have wide-open permissions, so I'm not sure whether this is a Kubernetes configuration problem, an NFS identity mapping issue, or something in the NAS export settings. I'd especially like to understand whether the pod user needs to match the NAS file owner, whether root squashing is involved, and how to diagnose the failure without repeatedly recreating the storage resources.
4 Answers
NFS itself is a reasonable choice here, so I’d first focus on identity mapping rather than recreating the PV and PVC. NFS checks the numeric UID and GID presented by the client; it does not care that the usernames look the same on the NAS and inside the container. Make sure the pod’s effective UID/GID has access to the exported directory, or configure the NAS export with the appropriate mapping. Also check whether root squashing is enabled, because a container running as root may be mapped to an anonymous user and still receive permission denied.
The storage definitions look broadly normal, although the PVC requests 10Mi while the PV advertises 5Gi; that mismatch is worth correcting even though it should not cause intermittent file permissions. Keep the PV and PVC simple, confirm the share can be mounted and written to manually from each Raspberry Pi, and inspect the NAS audit or NFS logs when access starts failing. That should distinguish a real export or network problem from a container UID mismatch.
Your pod is running nginx, and the process may not run as the same user that owns the files on the NAS. Inspect the container’s actual UID/GID with `id`, then use a pod `securityContext` with a deliberate `runAsUser`, `runAsGroup`, and possibly `fsGroup` if that matches your NAS permissions. Avoid relying on an init container to repeatedly chmod the share; that only masks the UID/GID or ACL configuration problem and may fail when the export is mounted with different identity rules.
Also check the NAS export configuration for the exact path, allowed client addresses, read/write mode, NFS version, and anonymous-user mapping. Test with the same NFS version and options from a cluster node before involving Kubernetes.
Verify the mount independently on every cluster node. The NFS CSI driver mounts the share on the node hosting the pod, so compare the output of `mount`, `id`, and a simple read/write test from each node. Check the node’s kernel and kubelet logs at the exact time the problem occurs. If the mount is stale or the NAS briefly disconnects, the error may look like a permissions problem even though the underlying issue is connectivity or an NFS server timeout.
The directory being mode 777 does not necessarily rule this out. The trailing ACL marker in the listing suggests extended ACLs may also be applied, and those can override what you expect from the basic Unix mode bits.