The mount protocol is separate from, but related to, the NFS protocol. It provides operating system-specific services to get NFS off the ground - looking up server pathnames, validating user identity, and checking access permissions. Clients use the mount protocol to get the first file handle, which allows them entry into a remote file system.
Notice that the protocol definition implies stateful servers
because the server maintains a list of client's mount requests.
This corresponds to current implementations which hold the mount list on
However, the mount list information is not critical for the correct
functioning of either the client or the server.
It is intended for
advisory use only; for example, to warn possible clients when a
server is going down.
Version 1 of the mount protocol is used with version 2 of the NFS protocol. The only connecting point is the fhandle structure, which is the same for both protocols.
The mount service uses
The mount service is currently supported on UDP/IP only.
Consult the server's port mapper, described in
These are the sizes, given in decimal bytes, of various XDR structures used in the protocol:
This section presents the data types used by the mount protocol. In many cases they are similar to the types used in NFS.
The type fhandle is the file handle that the server passes to the client. All file operations are done using file handles to refer to a file or directory. The file handle can contain whatever information the server needs to distinguish an individual file.
This is the same as the fhandle
XDR definition in version 2 of the NFS protocol; see
The type fhstatus is a union.
If a status of zero is returned,
the call completed successfully, and a file handle for the
A non-zero status indicates that an error occurred.
For a detailed description of the error conditions see Section 2.3, Error Numbers of the X/Open System Interfaces and Headers Specification (see reference XSH), [EPERM], [ENOENT], [EACCESS] and [EINVAL].
The type dirpath is a server pathname of a directory.
Implementations and applications must be able to handle pathnames as 8-bit transparent data (allowing use of arbitrary character set encodings). For maximum portability and interworking, it is recommended that applications and users define pathnames containing only the slash character (if required) plus the characters of the Portable Filename Character Set defined in ISO/IEC 9945-1:1990.
The type name is an arbitrary string used for various names.
Implementations and applications must be able to handle names as 8-bit transparent data (allowing use of arbitrary character set encodings). For maximum portability and interworking, it is recommended that applications and users define names containing only the characters of the Portable Filename Character Set defined in ISO/IEC 9945-1:1990.
The following reference pages define the RPC procedures supplied by a