nfsd_lookup(9)

📦 version 7.3.1, in nixpkgs unstable

💖 nfsd_lookup — look up a single path component for nfsd 💖

🌸 NAME 🌸

Okay bestie, welcome to nfsd_lookup(9) from the Kernel API Manual 🫶. This is nfsd_lookup — look up a single path component for nfsd — and it’s giving “one component only, we are not doing the whole path today” energy 💅✨.

✨ SYNOPSIS ✨

No notes, just the exact signature:

__be32 nfsd_lookup (struct svc_rqst *rqstp , struct svc_fh *fhp , const
       char *name , unsigned int len , struct svc_fh *resfh );

💅 ARGUMENTS 💅

These are the little squad members, no cap:

  • rqstp — the request context.
  • fhp — the file handle of the directory.
  • name — the component name, or NULL to look up parent.
  • len — length of name to examine.
  • resfh — pointer to pre-initialised filehandle to hold result.

🎀 DESCRIPTION 🎀

Look up one component of a pathname. N.B. — after this call, both fhp and resfh need an fh_put. Like, do not ghost those handles, okay? 🫶

If the lookup would cross a mountpoint, and the mounted filesystem is exported to the client with NFSEXP_NOHIDE, then the lookup is accepted as it stands and the mounted directory is returned. Otherwise the covered directory is returned. That’s the whole vibe: mountpoint crossing gets the mounted directory if NFSEXP_NOHIDE is in the chat; otherwise it’s the covered directory 🦋✨.

⚠️ NOTE ⚠️

⚠️ Bestie, listen: this mountpoint crossing is not supported properly by all clients and is explicitly disallowed for NFSv3. That’s not me being dramatic, that’s literally the note 💀.

🦋 SEE ALSO 🦋

Kernel file ./fs/nfsd/vfs.c — and the whole reference squad is:

xoxo 💋 — source/version corner: ./fs/nfsd; date: October 2026; page: nfsd_lookup(9). Stay hydrated and don’t forget the fh_put, bestie 🫶💅

📦 where this page comes from