Articles

NFS Interview Questions: Mount Failures, Identity Mapping, and Stale File Handles

Prepare for NFS interview questions with mount-failure evidence, NFSv3/v4 differences, identity mapping, root squashing, stale handles, and recovery checks.

An NFS interview often begins with a vague incident: “The share is broken.” Your first useful response is to ask which operation failed. Resolving the server, mounting an export, opening a file, writing a file and reusing an old file handle cross different boundaries. A single successful ping cannot establish all of them.

Locate the failed boundary, record the NFS version and security flavor, then choose the next check from evidence. This guide develops that approach through original mount, identity and stale-handle exercises. It focuses on Linux clients and servers, with Red Hat Enterprise Linux 9 guidance identified separately.

Practice describing what each observation proves before proposing a change.

Evidence boundary: Implementation facts come from current Linux manual pages, kernel documentation and Red Hat guidance, checked October 5, 2026. Incident ledgers and recommendations are original preparation material. No candidate reports establish interview frequency or employer scoring. Offline checks do not mount NFS, capture packets or reproduce every server's errors.

How do you investigate a mount failure?

Our original scenario has a reporting worker that cannot mount its expected share. Record the client, destination address, requested export, intended mount point, time of failure, exact error and whether another client succeeds. Avoid changing all the options before preserving that baseline.

The first diagnostic asset is a boundary matrix. Its observations are constructed examples, not findings from a real incident.

Observation	Boundary to investigate next	What remains unproved
Server name resolves to an unexpected address	DNS answer and client resolver context	Whether the expected server is reachable
TCP connection to the intended NFS endpoint times out	Routes, filtering, listener and return path	Whether the requested export is valid
Mount receives access denied	Export authorization, requested path and security compatibility	Whether a particular file operation is allowed
Mount exists but one worker cannot open a file	Effective identity, traversal permissions and access policy	Whether the worker used the intended credentials
Old reference fails while a fresh lookup succeeds	File-handle/object identity and server changes	Whether every open reference has recovered

Official Linux mount behavior: nfs(5) defines vers/nfsvers and the sec option. A requested unsupported version or incompatible security flavor can fail mounting. Our recommendation is to record both requested and effective settings; fallback negotiation can otherwise make two apparent comparisons test different protocols.

Useful Linux inspection commands include:

# Inspect an existing mount; these examples do not create one.
findmnt -T /mnt/reports -o TARGET,SOURCE,FSTYPE,OPTIONS
nfsstat -m

Use the actual application's namespace. A host shell and a container can see different mount trees. For a failed mount with no resulting entry, inspect the configured request and recorded error instead of treating an empty mount listing as a diagnosis.

Official version boundary: rpc.mountd explains that NFSv4 does not use the separate NFS MOUNT protocol. Official tool limitation: showmount queries that interface; a server exporting only NFSv4 need not provide it. Consequently, showmount -e failure can coexist with a working NFSv4 service.

For NFSv3, distinguish reaching the NFS service from reaching the required mount/RPC services. For NFSv4, investigate its exported namespace and negotiated configuration. Do not apply the same port checklist to every version, or equate a v3 diagnostic failure with a v4 outage.

Compare one working and one failing client while holding the intended server and export constant. If their versions, source addresses or security settings differ, those are candidate explanations. They are not proof until a controlled check connects the difference to the failed operation.

Why does mounting succeed while file access fails?

Mount authorization and file authorization are separate. Official RHEL guidance: exported filesystem permissions affect subsequent access. With traditional numeric identity handling, the same numeric UID on different clients can represent access to the same server-side ownership. Matching the displayed username alone is insufficient.

Our identity ledger assumes Linux NFS with sec=sys, ordinary mode-bit checks, no extra ACL grant, and a server file readable only by its owner. These assumptions deliberately isolate one issue; they are not a complete NFS authorization model.

Field	Client worker	Server file
Displayed username	`reporter`	`reporter`
Numeric user ID	1200	2200
File owner-read policy	Request arrives as UID 1200	Owner is UID 2200
Expected conclusion	Name looks consistent	Owner-only access does not match

The locally checked predicate rejects this owner-only access. Changing the client display name does not change that result; aligning the intended numeric identity does. In a real incident, inspect groups, ACLs, directory traversal and export policy as well before claiming a root cause.

Useful evidence includes id reporter, getent passwd 1200, numeric ownership such as ls -ln, and the running worker's actual identity. An interactive session under the right user does not prove a background process shares its credentials or supplementary groups.

Official export mapping: exports(5) documents root_squash, which maps requests from UID/GID zero to anonymous IDs. It also documents all_squash and configurable anonymous IDs. Therefore, testing as client root can change the identity being tested rather than bypass the server's permissions.

Our second controlled case uses an anonymous UID of 65534. Client UID zero maps to 65534 and cannot read the owner-only UID-2200 file. A nonroot client UID 2200 passes the simplified owner test. The anonymous number is an exercise setting, not a universal deployment value.

Our recovery recommendation is to establish the intended access model first. Broadening every permission or disabling root squashing changes that model and can conceal the original mismatch. A narrow correction needs both an allowed operation and a forbidden-operation check under the relevant worker identity.

What does NFSv4 identity mapping actually establish?

Official Linux identity mapping: nfsidmap describes translation between NFSv4 owner/group strings and local IDs, including domain configuration and cached mappings. An unexpected displayed owner can therefore be an identity-mapping symptom rather than evidence that the file was reassigned.

Keep three identities separate: the credential used for the request, ownership attributes returned by the server, and the local name displayed for an ID. Correcting one presentation layer does not automatically establish successful authorization at another layer.

Official kernel nuance: Linux's NFS module parameters document numeric-ID behavior for sec=sys and fallback to mapping when required. Saying “NFSv4 always authorizes through username strings” is too broad. State the client implementation, security flavor and observed mapping behavior before diagnosing a domain mismatch.

For our UID ledger, numeric owner-only authorization is an explicit assumption. For a deployment using Kerberos, inspect the relevant principal and its server-side mapping instead of borrowing that predicate unchanged. NFS version and authentication mechanism are different dimensions of the case.

Our recommended comparison records the effective worker credential, numeric ownership, displayed names, configured mapping domain and relevant errors. Preserve the evidence before clearing mappings. If cached mapping state is implicated, a targeted refresh is a controlled change with its own before-and-after test, not a universal first step.

An interview answer earns clarity by stopping at the evidence boundary: “The owner display suggests mapping trouble; I still need the request credential and server access decision.” It is stronger than declaring that an unfamiliar owner name explains every denied write.

Why can a file handle become stale at the same path?

Official object-reference model: Linux's exportability documentation explains that remote filesystem references need an opaque identifier beyond a filename, designed to survive operations such as renames. The path is a lookup route; it is not the old remote object's identity.

Our third asset is a replacement timeline. The labels A, B and generation numbers are invented teaching identifiers, not a universal NFS handle layout.

A worker resolves /reports/q.csv and receives a handle for object A in backend generation 7.
Maintenance removes A and creates object B at the same path.
A fresh path lookup resolves B; a request using A's old handle cannot resolve the original object in our fixture.
Recovery must account for processes still holding old references, as well as successful new lookups.

The offline handle check accepts a rename that preserves object A. It rejects deletion/recreation and an incompatible backend-generation change. This distinguishes our intended replacement case from the incorrect shortcut “renaming a file always makes its handle stale.”

Actual behavior depends on the server, exported filesystem and persistence of identifiers. A restart alone does not prove all handles become invalid. Ask about filesystem replacement, restored snapshots, export changes and failover identity, then correlate those events with the first observed failure.

Our recovery recommendation starts on the server: verify that the intended backend is present and that the export refers to it. On clients, identify affected processes and operations. Refreshing a mount may obtain new references, but does not independently recover pending application work or prove that every process stopped using the old object.

A lazy unmount or a service restart is a change to system behavior, not explanatory evidence. Describe the proposed recovery's scope, interruption and verification before choosing it. Repeating the same failing pathname lookup without inspecting object identity can keep the diagnosis at the wrong layer.

How do you reason about timeouts and safe recovery?

Official retry behavior: nfs(5) says a hard mount retries requests indefinitely after timeout; soft modes can eventually return errors, and the manual warns of data-integrity risks in some cases. Choosing a soft mount changes failure behavior. It does not repair a lost network path or establish that a previous write had no effect.

Our preparation answer records the failed operation, effective mount options, relevant logs and the application's response. A rising retry count supports investigating responsiveness; it does not uniquely identify packet loss, server saturation or backend storage delay.

For a hung reporting task, distinguish waiting for remote I/O from consuming CPU. Compare client symptoms with server-side activity and a controlled operation from another client. Keep the operation and identity comparable so that a successful read is not mistaken for evidence that the failing write is healthy.

The recovery verification should reproduce the affected workflow with a small permitted operation. Check the intended source and version, correct access under the worker identity, fresh lookup behavior, and the application's handling of old or interrupted work. Preserve one negative authorization check so that restored availability does not mask unintended access.

For concurrent writers, our recommendation is to define an application coordination contract rather than infer transaction semantics from a shared mount. State what happens when a response is lost, when a worker retries, and when another client changes the same file. An NFS repair and an application's duplicate-write policy answer different questions.

Finish with a concise evidence statement: “The worker now opens the intended object under the intended identity; the original failed operation succeeds, and the prohibited operation remains denied.” Add any untested boundary explicitly, including old process references or failover behavior.

Sources and Further Reading

Research checked October 5, 2026. Linux implementation details and RHEL 9 guidance are scoped above. Fixtures are original; no real NFS mount, server repair or candidate interview was performed.