nfsd(7)

🎀 nfsd(7) 🎀

ok bestie, welcome to nfsd(7) from the Miscellaneous Information Manual — the little page that explains the special filesystem that runs your Linux NFS server. it's giving sysadmin main character energy and we're gonna get through it together 💅

✨ NAME ✨

nfsd — the special filesystem for controlling the Linux NFS server 🦋

💖 SYNPOSIS 💖

mount -t nfsd nfsd /proc/fs/nfsd

🌸 DESCRIPTION 🌸

So. The nfsd filesystem is a special filesystem that hands you the keys to the Linux NFS server 🔑. Writing to files in this filesystem can literally affect the server (yes, for real, be careful bestie). Reading from them gives you information about the server. It's a whole two-way relationship.

As well as this filesystem, there's a whole collection of files chillin' in the procfs filesystem (normally mounted at /proc) that are also used to control the NFS server. This manual page describes all of these files. every single one. no crumbs left.

The exportfs and mountd programs (they're part of the nfs-utils package, iykyk) expect to find this filesystem mounted at /proc/fs/nfsd or /proc/fs/nfs.

🔍 DETAILS 🔍

Files in the nfsd filesystem include:

• exports — this file contains a list of filesystems that are currently exported, plus the clients that each filesystem is exported to, together with a list of export options for that client/filesystem pair. Basically the receipts of who gets what 👑. This is similar to the /proc/fs/nfs/exports file in 2.4. One difference (and it's a big one) is that a client doesn't necessarily correspond to just one host — it can respond to a large collection of hosts that are all being treated identically. Group chat rules, everyone gets the same energy.

Each line of the file contains a path name, a client name, and a number of options in parentheses. Any space, tab, newline or back-slash character in the path name or client name will be replaced by a backslash followed by the octal ASCII code for that character. Escaping era fr fr.

• threads — this file represents the number of nfsd thread currently running. Reading it will show you the number of threads. Writing an ASCII decimal number will cause the number of threads to be changed (increased or decreased as necessary) to achieve that number. it's a slider, bestie, you're just typing the vibe you want 🎚️
• filehandle — this is a somewhat unusual file in that what is read from it depends on what was just written to it. She's a little mysterious, we respect that 🙈. It provides a transactional interface where a program can open the file, write a request, and read a response. And if two separate programs open, write, and read at the same time? Their requests will not be mixed up. iconic behaviour honestly.

The request written to filehandle should be a client name, a path name, and a number of bytes. This should be followed by a newline, with white-space separating the fields, and octal quoting of special characters.

On writing this, the program will be able to read back a filehandle for that path as exported to the given client. The filehandle's length will be at most the number of bytes given.

The filehandle will be represented in hex with a leading \x.

• clients/ — this directory contains a subdirectory for each NFSv4 client. Each file under that subdirectory gives some details about the client in YAML format ✨. In addition, writing "expire\n" to the ctl file will force the server to immediately revoke all state held by that client. bye boo 👋

The directory /proc/net/rpc in the procfs filesystem contains a number of files and directories. The files contain statistics that can be display using the nfsstat program. The directories contain information about various caches that the NFS server maintains to keep track of access permissions that different clients have for different filesystems. The caches are:

• auth.unix.ip — this cache contains a mapping from IP address to the name of the authentication domain that the ipaddress should be treated as part of.
• nfsd.export — this cache contains a mapping from directory and domain to export options.
• nfsd.fh — this cache contains a mapping from domain and a filesystem identifier to a directory. The filesystem identifier is stored in the filehandles and consists of a number indicating the type of identifier and a number of hex bytes indicating the content of the identifier.

Each directory representing a cache can hold from 1 to 3 files. They are:

• flush — when a number of seconds since epoch (1 Jan 1970) is written to this file, all entries in the cache that were last updated before that file become invalidated and will be flushed out. Writing a time in the future (in seconds since epoch) will flush everything. This is the only file that will always be present. always there, never leaves, loyal queen 💜
• content — this file, if present, contains a textual representation of ever entry in the cache, one per line. If an entry is still in the cache (because it is actively being used) but has expired or is otherwise invalid, it will be presented as a comment (with a leading hash character). # said what she said.
• channel — this file, if present, acts a channel for request from the kernel-based nfs server to be passed to a user-space program for handling.

When the kernel needs some information which isn't in the cache, it makes a line appear in the channel file giving the key for the information. A user-space program should read this, find the answer, and write a line containing the key, an expiry time, and the content. For example the kernel might make

nfsd 127.0.0.1

appear in the auth.unix.ip/content file. The user-space program might then write

nfsd 127.0.0.1 1057206953 localhost

to indicate that 127.0.0.1 should map to localhost, at least for now. it's giving "here's your answer, don't @ me" 💖

If the program uses select(2) or poll(2) to discover if it can read from the channel then it will never see and end-of-file but when all requests have been answered, it will block until another request appears. no EOF for you, only ✨suspense✨

In the /proc filesystem there are 4 files that can be used to enabled extra tracing of nfsd and related code. They are:

/proc/sys/sunrpc/nfs_debug
/proc/sys/sunrpc/nfsd_debug
/proc/sys/sunrpc/nlm_debug
/proc/sys/sunrpc/rpc_debug

They control tracing for the NFS client, the NFS server, the Network Lock Manager (lockd) and the underlying RPC layer respectively. Decimal numbers can be read from or written to these files. Each number represents a bit-pattern where bits that are set cause certain classes of tracing to be enabled. Consult the kernel header files to find out what number correspond to what tracing. yes bestie, you gotta go read the headers, that's the homework 📚

⚠️ NOTES ⚠️

This file system is only available in Linux 2.6 and later series kernels (and in the later parts of the 2.5 development series leading up to 2.6). This man page does not apply to 2.4 and earlier. if you're on 2.4, this page is not for you, no cap 😭

Previously the nfsctl systemcall was used for communication between nfsd and user utilities. That systemcall was removed in kernel version 3.1. Older nfs-utils versions were able to fall back to nfsctl if necessary; that was removed from nfs-utils 1.3.5. rip nfsctl, you served 🕊️

👀 SEE ALSO 👀

nfsd(8), rpc.nfsd(8), exports(5), nfsstat(8), mountd(8) exportfs(8).

💜 AUTHOR 💜

NeilBrown

and that's the whole page bestie, you ate it 🫶 this was nfsd(7) from the Miscellaneous Information Manual, dated 3 July 2003 — yes, she's vintage, and she's still serving ✨🌸💅