NFS share contains unexpected files named .nfs*

Files may show up within NFS shares with names in the form .nfs<hash>, for example:

.nfs00000000008ac03200000397
.nfs00000000008ac04f000004ef

These can be see from both the NFS clients and directly at the NFS server.  Attempts to delete them often fail.

Usually, no action is needed.  If the file has a recent date / timestamp, it would best to ignore it.  If the file is old, then likely it can be deleted successfully.

These are files which have been renamed by the NFS client in a method known as "silly rename".  They occur because NFS can't natively support the practice of "delete on last close."

"Delete on last close" is a practice in Unix and Linux where an application has a file open but issues a delete (unlink) on that file anyway.  In a native Linux file system, this will result in the file becoming invisible to other processes, even though it still exists and is still open.  Once the application closes the file, it gets fully removed, assuming no other links to that file exist.

However, over the NFS protocol, this "delete on last close" behavior isn't supported in the normal way.  The NFS Client layer must use another approach, by renaming the file to .nfs<hash>.  The NFS Client will remove the file after the application closes it.

As long as the application closes gracefully, these files should be removed automatically.  If applications have crashed or if a machine has lost power, then afterward the files might still exist and never be cleared away automatically.  In those cases, it should be fine to delete them manually, and this should succeed because nothing is holding them open any longer.