"Stale File Handle" after 15 minutes of using NSS volume shared through NFS

SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 11
Novell Open Enterprise Server 2018 (OES 2018) for Linux
Novell Open Enterprise Server 2015 (OES 2015) for Linux
Novell Open Enterprise Server 11 (OES 11) for Linux

An OES server with one or more NSS volumes is exporting a path within an NSS volume via NFS.  An NFS client can mount this, but after about 15 minutes, the client begins receiving "Stale File Handle" errors from the NFS Server.

NOTE:  This could also happen with any file system which is not fully case-sensitive, if that file system resides on Linux and is exported via NFS.
 

The issue comes from the fact that many Linux processes and file systems are case-sensitive, yet NSS volumes are not.  (See the "Cause" section of this document for more details).  To make the Linux NFS export methods get along with file systems that are case-insensitive, a change was made in SLES 11 SP3 and beyond, to better support this aspect of NSS.

NOTE:  The change is made in the package "nfs-kernel-server" which should be applied to the NFS Server machine.  However, "nfs-kernel-server" and another package, "nfs-client", are built from the same source package (known as "nfs-utils"), so it is best that a Linux NFS Server receives updates of both packages at the same time.

SLES 15 (all SPx) will have this change "out of the box".

If SLES 12 SP5 is in use, make sure nfs-kernel-server package is updated to 1.3.0-34.53.5 or higher.

Within SLES 12, SP4 and below do not contain this change.

If SLES 11 SP4 is in use, it will have this change "out of the box."  Further update is not needed for this issue.
 
If SLES 11 SP3 is in use, make sure nfs-kernel-server is updated to 1.2.3-18.37.1 or higher.

Within SLES 11, SP2 and below do not contain this change.

The general Linux community adopted these changes beginning in nfs-utils 1.3.1.
 
If an update is not yet possible, or the SLES SPx level does not have an update available to correct this, there is a quick workaround which works in some cases:
 
On the OES server (where the NSS volume physically resides) create a cron job:
 
As root user, execute "crontab -e" and add the following line to the crontab file:
 
*/5 * * * * /usr/sbin/exportfs -f > /dev/null 2>&1
 
This causes the successfully functioning export information to be refreshed every 5 minutes.  This way, the event which causes the information to be lost (which occurs after 15 minutes) may not occur.


Another workaround is to export only the NSS volume's root location itself, rather than explicitly exporting subdirectory paths below it.  For example, if the NSS file system named "DATA" is mounted at "/media/nss/DATA" and then that path is exported, NFS clients can mount that location or subdirectories below it, and should not run into this problem.  But if "/media/nss/DATA/subdir1" is explicitly exported, this confusion could occur at the "subdir1" level.

NSS volumes, in their default configuration, are not fully case sensitive. This is different from most file systems on Linux. Even though the NSS volume itself is not fully case sensitive, the NFS Server and NFS mount daemon might experience some confusion if there is a upper/lowercase discrepancy in an NFS export point.
 
For example, consider this situation:
An NSS volume exists at:
/media/nss/DATA
and if an "ls" is done there, a subdirectory called "users" is shown to be present.
 
NSS may not care whether that directory name is accessed by referencing "users" or "USERS" or "uSeRs", but other Linux processes might.  To further complicate matters, certain information about the directory may get put into memory in an unexpected upper/low case combination, depending on what case was specified the first time the directory object was accessed after boot, by any process (not just NFS processes).  Therefore, after any reboot, a new variation of the mismatch could occur.  Since this can change each time, it may not be enough to match the /etc/export syntax to that which is shown by "ls".
 
This "case confusion" will not happen on the volume name itself (i.e. "DATA") or on "/media/nss", as those are case sensitive.  If an incorrect case were used with one of those components, the path will not export or be mountable in the first place.  This confusion will only happen on subdirectories which exist inside the NSS volume, and which are specifically named within the export syntax in /etc/exports.
 
When this case confusion is happening, it can typically be confirmed by checking the path in these two locations:
 
The output of the command:
exportfs
 
The contents of this file:
/proc/net/rpc/nfsd.fh/content
 
If the case of the directory path in those two locations doesn't match, the problem will likely occur.  While this mismatch can be corrected by editing /etc/exports and afterwards restarting the "nfsserver" service, that correction might only survive until the machine is restarted.  A new mismatch could occur again after reboot.