Novell Home

My Favorites

Close

Please to see your favorites.

Stale File Handle error while using NSS volume shared through NFS

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

Environment

Novell Open Enterprise Server 11 (OES 11) Linux

Situation

An OES server with one or more NSS volumes is exporting a path from the 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.

Resolution

Investigation into this issue is still a ongoing.  The issue deals with the fact that many Linux processes are case-sensitive, yet NSS volumes are not.  (See the "Cause" section of this document for more details).  SUSE is testing changes to NFS to allow for differences in export case (upper/lower).  A change will likely be made in maintenance updates for SLES 11 SP3 and beyond to better support this aspect of NSS.  However, this plan is tentative and subject to change.
 
In the meantime, there easiest workaround is:
 
Create a cron job (as root) on the OES server (where the NSS volume physically resides) with the following syntax:
 
*/5 * * * * /usr/sbin/exportfs -f > /dev/null 2>&1
 
This will cause 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) will not occur.

Cause

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 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 directories may get put into memory in an unexpected case, depending on what case was used the first time the directory object was accessed after boot, by any process (not just NFS processes).  Therefore, even matching the /etc/export syntax to that shown in "ls" (a directory list) may not fully protect against this issue.
 
This case "confusion" will not happen on the volume name itself (i.e. "DATA") or on "/media/nss", as those are case sensitive, and a path will not export or be mountable in the first place, if incorrect case is used in those components. 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 case 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 NFS server with "rcnfsserver restart", that correction may only survive until the machine is restarted.  A new mismatch could occur again after reboot.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/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:7014909
  • Creation Date:14-APR-14
  • Modified Date:14-MAY-14
    • NovellOpen Enterprise Server
    • SUSESUSE Linux Enterprise Server

Did this document solve your problem? Provide Feedback