NFS: 'Permission denied' for attributes after file move

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:

/mnt/subfolder/a.txt

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.