NFS: 'Permission denied' for attributes after file move

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


SUSE Linux Enterprise Server 12 SP5


A SLES machine acting as an NFS client to a 3rd party NFS Server was upgraded from SUSE Linux Enterprise Server 12 SP4 to SP5.  Then, on an NFS Mount, if a file is moved to a new location, subsequent directory listings give 'Permission denied' and display question marks instead of file attributes.

ls: cannot access 'subfolder/a.txt': Permission denied
total 16
drwxr-xr-x 2 root root 8192 Apr  1  2021 ./
drwxr-xr-x 4 root root 8192 Apr  1  2021 ../
?????????? ? ?    ?       ?            ? a.txt



Check for unapplied updates for the 3rd party NFS Server for file handling.  (See Cause section, below.)

Until the NFS Server side can be corrected, possible workarounds include:

1.  At the NFS client, when mounting the share, include the "lookupcache=none' option.  This should avoid the problem altogether, although there could be a small performance penalty.

An example in a mount command:
mount -o lookupcache=none nfs-server1:/share1 /mnt

An example for /etc/fstab:
nfs-server1:/share1     /mnt     nfs     lookupcache=none  0  0

If #1 cannot be immediately implemented, alternatives 2 and 3 can be considered:

2.  It is likely that touching (setting a new time stamp) on the parent directory will cause the NFS client to flush enough cache to correct the problem.  If the problematic file is:
Then execute:
touch /mnt/subfolder

3.  Dropping all disk caches at the NFS client machine will allow the client to learn new file handles, anywhere this problem has occurred.  However, this step can have a large impact and should only be used as a last resort.  Machine performance may suffer for a period of time after this is executed, because previously cached information from any/all file systems will have to be relearned from disk and/or from the NFS Server.
echo 3 > /proc/sys/vm/drop_caches


The 3rd party NFS Server is creating a new file handle for a moved file, rather than using the same file handle.  This is likely a violation of the NFS Protocol, as file handles are not allowed to depend upon the pathname of the object.  This requirement is intended to avoid file handle changes upon a rename or move.

The NFS Server in this case was using 3PAR/File Persona Version 1.6.0, and the behavior was fixed by upgrading to 1.6.1.


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:000020367
  • Creation Date: 25-Aug-2021
  • Modified Date:21-Sep-2021
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]

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