Research notes / Network filesystems

Why deleted NFS files become .nfs files

16 October 2026 / Source review, not a server benchmark

A Linux NFS client can rename an open file to a hidden .nfs name when its original name is removed. This preserves a reference until cleanup. But the workaround is conditional: an NFSv4.1 server can advertise open-file preservation. The version number alone does not establish that promise.

The name is not the open file

POSIX separates directory entries from open references. Removing the last link does not immediately destroy file contents while the file remains open; existing references continue to provide access. This is the contract applications use for temporary files, not proof that every network implementation reproduces it under every failure. [1]

Three questions must stay separate: does the original name exist, can an existing reader still access the file, and has storage actually been reclaimed? Neither a disappeared name nor a retained reference establishes secure erasure. See namespace identity for the related rename boundary.

The workaround was already incomplete in 1985

Sandberg and colleagues describe checking for local opens in the client's remove operation, renaming the file, then removing that temporary name when its vnode becomes inactive. A client crash between those steps leaves a file behind. The authors also identify a different hole: one client can remove a file another client still has open, causing the latter's read to fail. [2, pp. 126-127]

This describes the original Sun implementation, not a measured failure rate or every contemporary NFS deployment. One client's open-reference knowledge is not a complete inventory of other clients' activity. Do not transfer the paper's historical cleanup suggestion into an automatic deletion policy for a live share.

Follow the code past the stale comment

In Linux v6.12, nfs_sillyrename() uses the .nfs prefix and queues later removal. Its comment still describes taking advantage of server preservation as future work. Reading only that comment would miss the implemented path. [3]

_nfs4_do_open() checks the server's NFS4_OPEN_RESULT_PRESERVE_UNLINKED result and sets NFS_INO_PRESERVE_UNLINKED on the inode. [4]
nfs_unlink() enters the silly-rename branch when d_count(dentry) > 1 and that inode flag is absent. [5]
The dentry count is an internal reference count, not an application file-descriptor count. This predicate is not a universal user-space formula. [5]

Source-derived decision, not observed RPC traffic
Dentry references	Preserve flag	Silly-rename branch
More than one	Absent	Taken
More than one	Present	Bypassed
One	Either	Bypassed

Bypassing this branch does not guarantee unlink succeeds. Other checks and server responses still apply. The source-audit record pins the code and hashes; it does not test a running kernel.

Preserve contents, not necessarily a directory entry

RFC 8881's OPEN result describes preserving an open file when any client removes it, including across the server-restart grace period so an open can be reclaimed. This advertised capability is not a backup, unlimited retention, or proof that buffered writes are durable. [6, section 18.16.3]

The REMOVE discussion in section 18.25.4 contains conflicting directory-entry wording. Technical erratum 6865 proposes protecting contents until namespace references and opens are gone. Its status was Reported on 16 October 2026, not Verified. We use the OPEN description for the capability's scope; the proposed replacement is not an approved standard revision. [7]

A busy .nfs file is not a disk-health signal

The Linux unlink manual lists an active silly-renamed NFS file as one possible cause of EBUSY, alongside other causes. It also warns that NFS can lose access to still-used files. Neither the name pattern nor EBUSY alone identifies media failure. [8]

Our diagnostic recommendation: record the mount, client/server versions, application retaining references and exact error. Coordinate an orderly close and recheck. A local process inventory does not prove no other client uses the file. Repeated forced deletion is not a substitute for determining ownership.

Evaluate deployments with disposable files on an isolated share. Separate same-client removal, second-client removal and restart/reclaim; record OPEN results, RENAME/REMOVE operations, read outcomes and cleanup state. This is a proposed validation protocol. We did not run those server tests.

Evidence and limits

This is a source-code and specification comparison, not a new filesystem mechanism. Linux is pinned to v6.12, commit adc218676eef25575469234709c2d87185ca223a; vendor kernels can differ. The reproducible audit checks source markers and SHA-256 digests, not runtime conformance. No paper figures or benchmark numbers are transferred to current appliances.

Corpus: NFS silly rename, NFS open-file preservation and unlink. See NFS stable writes for persistence and cache visibility.