Introduction

When Kubernetes reports an NFS mount failure with exit status 32, the error usually comes from the underlying mount.nfs command on the node rather than from Kubernetes itself. The failure almost always points to one of four things: the node cannot reach the NFS server, the export is not allowed, the client tools are missing, or the mount options do not match what the server supports.

Start With the Node, Not the Pod

The kubelet performs the mount on the node before the container starts. That means you should debug from the worker node where the pod is scheduled, not only from the pod manifest.

Useful first checks are:

kubectl describe pod my-pod
journalctl -u kubelet -n 200 --no-pager

Then log into the affected node and test basic connectivity to the NFS server.

ping -c 3 nfs-server.example.internal
showmount -e nfs-server.example.internal

If showmount cannot list exports, the problem is usually network access, DNS resolution, or NFS server configuration. Kubernetes cannot mount a path that the node cannot reach with normal operating system tools.

Verify the NFS Export and Client Utilities

A very common cause is that the NFS path is not exported to the node subnet, or the nodes do not have the NFS client packages installed. Many minimal node images omit these packages by default.

On Debian-based systems, install the client tools like this:

sudo apt-get update
sudo apt-get install -y nfs-common

On RPM-based systems, the package is often nfs-utils.

You should also test the mount manually from the node. Manual failure gives clearer error text than the Kubernetes event stream.

1sudo mkdir -p /mnt/test-nfs
2sudo mount -t nfs -o vers=4 nfs-server.example.internal:/exports/shared /mnt/test-nfs
3ls /mnt/test-nfs
4sudo umount /mnt/test-nfs

If the manual mount fails with the same status, you have confirmed that the issue is outside the pod spec.

Check the Kubernetes Volume Definition

After node-level connectivity is working, verify that the Kubernetes manifest points to the exact exported path and uses valid mount options.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: nfs-demo
5spec:
6  containers:
7    - name: app
8      image: nginx:stable
9      volumeMounts:
10        - name: shared-data
11          mountPath: /usr/share/nginx/html
12  volumes:
13    - name: shared-data
14      nfs:
15        server: nfs-server.example.internal
16        path: /exports/shared
17        readOnly: false

Be precise with the path value. An export mismatch such as using /shared when the server actually exports /exports/shared is enough to trigger a generic mount failure.

If the server only supports specific protocol versions, align the mount options. For persistent volumes, those options can be set directly on the volume spec.

1apiVersion: v1
2kind: PersistentVolume
3metadata:
4  name: shared-pv
5spec:
6  capacity:
7    storage: 10Gi
8  accessModes:
9    - ReadWriteMany
10  mountOptions:
11    - vers=4.1
12  nfs:
13    server: nfs-server.example.internal
14    path: /exports/shared

Network Policy and Firewall Rules Matter Too

NFS is sensitive to network policy and firewall configuration. Even when DNS works, the relevant ports may still be blocked between worker nodes and the NFS server. For NFSv4, port 2049 is the main one to verify. Older NFS setups can also involve additional services managed by rpcbind and related daemons.

In cloud environments, remember to check both directions: node security groups or firewall rules, and the server-side allowlist. A successful ping does not prove that the NFS service itself is reachable.

Common Pitfalls

A common mistake is debugging only the pod manifest and never testing a manual mount from the node. Since the kubelet mounts NFS before the container starts, node-level diagnosis is usually faster.

Another mistake is forgetting to install nfs-common or nfs-utils on new node images. The cluster may work on older nodes and fail only on freshly provisioned ones, which makes the issue look random.

Teams also run into trouble by assuming the export path is correct without checking the server. A single directory mismatch produces a generic mount error that looks similar to network failure.

Finally, avoid guessing the NFS version. If the server expects vers=4.1 and the client negotiates differently, the mount can fail with an error that does not clearly mention version mismatch.

Summary

• 'exit status 32 usually comes from the node-level mount.nfs command.'
• Debug from the worker node using showmount, manual mount tests, and kubelet logs.
• Confirm the NFS server export path, network access, and installed client utilities.
• Use the exact exported path and correct mount options in the Kubernetes manifest.
• Treat the problem as a storage and node integration issue first, not only a pod YAML issue.