The high-level version of how mounting NFS filesystems works

For reasons that are going to become apparent soon, I need to explain how NFS mounting works.

NFS servers (in the code and protocol sense) just talk NFS, which is to say that you give them an NFS filehandle and tell them what operation you want to do with it and they give you a reply. One of those operations is to look up a name in a directory and give you its filehandle, which is the basic building block that lets a client traverse a filesystem's directory hierarchy.

Thus, at a conceptual level you mount an NFS filesystem by acquiring the filehandle of its root directory (and then remembering it locally). The NFS protocol has no mechanism for doing this, since all NFS operations start with the filehandle; instead, the job is delegated to an entirely separate protocol, the NFS mount protocol ('mountd'). Handling this protocol on the NFS server is traditionally done by a separate user-level program, the (NFS) mount daemon, and some associated daemons.

(It needs more than one daemon because of extra generality. NFS mounting is based on Sun RPC, and Sun RPC requires a bootstrapping process; first you ask the RPC portmapper on which port you can find whatever handles the mountd protocol, and then you go talk to that port to do the actual work. This avoids having to ask IANA for a bunch of port assignments, and back in 1986 or so no one had even started thinking about firewalls so the idea that services might wind up on randomly chosen TCP ports did not fill sysadmins with screaming nightmares. But I digress.)

Traditionally, clients also implement the NFS mount protocol in a separate user-level program (sometimes directly including it in mount, sometimes making it a separate internal program that mount runs for you). That program talks RPC to the NFS mount daemon, basically giving it a path and getting back an NFS filehandle; it then takes that filehandle and passes it to the kernel somehow (along with all of the other information about the mount that the kernel needs), where the kernel NFS client code takes over.

While this may seem peculiar, the advantage of this split is that neither the client nor the server kernels need to have all sorts of complicated code to do things like hostname lookups, RPC portmapping, parsing /etc/exports, and so on, all of which is much easier and more flexible when done in user level code.

(Having a separate NFS mount protocol also keeps the NFS protocol itself simpler and more regular.)