Umount fails on NFSv4 formerly exported file system until another file system is unexported

This document (000020609) is provided subject to the disclaimer at the end of this document.


SUSE Linux Enterprise Server 15 Service Pack 2
SUSE Linux Enterprise Server 15 Service Pack 3


An NFS server has two local file systems shared (exported) via NFS v4.x.  Later, one of those file systems is unexported, and an attempt is made to umount the local file system.  This fails because the file system is reported to be busy.  Even after an extended period of time and no activity, it continues to report "busy".

If the second file system is unexported and then the NFS lease time (usually 90 seconds) is allowed to expire, the first file system can finally be umounted.  Alternatively, if the nfsserver service is stopped, the file system can be immediately umounted.  However, it may be preferred for the first file system to be umounted without affecting the second file system's export status.


For NFSv4.1 and NFSv4.2, code has been added to allow a manual or scripted method to be used in order to bypass this issue.  This functionality has been added starting with the following kernels, released in early March 2022:

SLES15 SP3  kernel-default-5.3.18-150300.59.54.1
SLES15-SP2-LTSS  kernel-default-5.3.18-24.107.1

With the updated (or newer) kernel in place, use this sequence:

1.  Unexport the file system in question.  (See "man exportfs")

2.  Signal the NFS Server to unlock the file system with this command:
echo /path/to/filesystem > /proc/fs/nfsd/unlock_filesystem

Where "/path/to/filesystem" is replaced with the actual path to the file system which had been exported.  The proc location specified above is literal.

3.  Unmount (umount) the file system.


If a NFS v4.x Client has a file open, locked, or delegated when the NFS Server unexports that file system, the NFS Server is still aware of the state of that file and does not normally release it, so long as any other file system is also exported to that same client.  In many ways, NFS v4.x treats all exported file systems as part of one larger logical export, rather than as individual exports.

Additional Information

Due to complexity, this issue will not be addressed in NFSv4.0.

This issue was first brought to SUSE's attention by a customer whose Linux NFS Server was operating in a cluster. Different NFS-exported file systems were being managed and moved around the cluster independently from each other.  While this is a fairly common practice and will sometimes work without any perceptible problem, it doesn't correctly support 100% of NFS 4.x functionality.  Specifically, it doesn't support client lock retention during NFS Server failover.  For a discussion of NFS 4 cluster design which can support all functionality, see



This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:000020609
  • Creation Date: 09-Mar-2022
  • Modified Date:09-Mar-2022
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact:

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center