I'm running a K3s cluster on Raspberry Pis and want to use storage from a UGREEN DXP6800 Pro NAS. I'm using the NFS CSI driver with a manually defined ReadWriteMany PersistentVolume and PersistentVolumeClaim, mounting the share into an nginx pod with NFS v3. The mount works initially, but after roughly a day the pod starts receiving permission errors. I then end up deleting and recreating the PV, PVC, and related workloads. The NAS export is configured with broadly permissive permissions, but the files are owned by my NAS account. Could this be caused by UID/GID mapping, root squashing, ACLs, or an NFS export setting? I'd like to understand what to check rather than relying on an init container to repeatedly change permissions.
3 Answers
The manifest is broadly reasonable. Since nginx normally only needs to read the website, use a pod security context with the intended numeric `runAsUser` and `fsGroup`, then make the NAS directory owned by that UID/GID. If the application needs to write, grant write access to that group instead of repeatedly changing ownership from an init container. Also make each `volumeHandle` unique and keep the NFS version consistent; changing PVs should not be necessary for an ordinary permissions problem.
Look at the kubelet and pod events on the specific node where the mount fails, along with the CSI node-plugin logs. Test the same export directly from every cluster node using the same NFS version and mount options. If only one node fails, it is probably a node, network, or NFS-client issue rather than the PVC. Confirm that the NAS share path is the exported path and that every node can resolve and reach the NAS consistently.
NFS itself is usually fine for this. The first thing to verify is the numeric UID and GID, not the usernames. NFS permission checks use numbers, so the user inside the container must match the owner or group on the NAS. Check the pod with `id`, inspect the files on the NAS with numeric IDs such as `ls -ln`, and compare them. An init container may appear to fix things temporarily, but it can hide the real mismatch and may fail later if the export uses root squashing or ACLs.
Also inspect the NAS export settings for root squash, anonymous UID/GID mapping, and ACLs. A directory showing mode 777 can still be denied by an ACL or by the NAS mapping the client to an anonymous account.
The `+` after the mode bits in your NAS listing indicates extended ACLs. Those ACLs are worth checking explicitly, because they can override what the traditional 777-looking permissions suggest.