1
Diagnostic step 1
Avoid online changes to exports during peak operations. Document and backup /etc/exports on both nodes before making changes.
FULL AI ANALYSIS
NFS client mounts switch to read-only with 'stale file handle' after server cluster failover
Generated Oct 3, 2026, 12:35:03 AM
Analysis summary
Stale file handle indicates that the file handle (which encodes inode / fsid information) held by the client no longer matches what the server exports — often because the server's representation of the filesystem changed (different fsid or inode numbering) after a relocation or re-export. The kernel protects against silent corruption by switching the mount read-only when server replies are inconsistent. The temporary remount works because the client obtains new handles, but any failover that changes the exported filesystem identity will break clients until remounted. Using unstable export identifiers or a failover mechanism that does not preserve filesystem identity causes exactly these symptoms.
Possible causes
The HA failover changed underlying filesystem IDs (fsid) so file handles on clients are invalid after failover.
95%Client caching combined with NFSv4 stateful locking/cached handles leads to inconsistency when server reexports the filesystem.
75%The passive node exported a different mountpoint or lacked proper bind/export options, causing clients to see a different filesystem namespace.
40%DNS or virtual IP reconfiguration during failover caused clients to connect to a different server path that doesn't match original export state.
20%Suggested fixes
2
Diagnostic step 2
On the storage/cluster side: ensure that exported filesystem identities (fsid) remain stable across failover. Configure exports to include an explicit fsid= option if appropriate so clients see the same fsid regardless of active node.
3
Diagnostic step 3
Test client behaviour in a maintenance window: perform a controlled failover and capture kernel logs (dmesg), rpc debug logs, and showmount outputs to correlate the change.
4
Diagnostic step 4
Prefer using a clustered filesystem or a network filesystem solution designed for HA (e.g., clustered NFS gateway, GlusterFS, Ceph) which preserves object identity across failovers if your application requires high availability without remounts.
5
Diagnostic step 5
As a practical mitigation, schedule remounts via automation immediately after failover or perform backups and use a read-only failover mode until you can remount clients safely. If uncertain whether data may be corrupted, escalate to storage/cluster administrators and avoid write-heavy operations until the cluster export identity is guaranteed stable.