5. Appendix I: Mount protocol
5.0 Appendix I: Mount protocol
The changes from the NFS version 2 protocol to the NFS version 3 protocol have required some changes to be made in the MOUNT protocol. To meet the needs of the NFS version 3 protocol, a new version of the MOUNT protocol has been defined. This new protocol satisfies the requirements of the NFS version 3 protocol and addresses several other current market requirements.
5.1 RPC Information
5.1.1 Authentication
The MOUNT service uses AUTH_NONE in the NULL procedure. AUTH_UNIX, AUTH_SHORT, AUTH_DES, or AUTH_KERB are used for all other procedures. Other authentication types may be supported in the future.
5.1.2 Constants
These are the RPC constants needed to call the MOUNT service. They are given in decimal.
PROGRAM 100005
VERSION 3
5.1.3 Transport address
The MOUNT service is normally supported over the TCP and UDP protocols. The rpcbind daemon should be queried for the correct transport address.
5.1.4 Sizes
const MNTPATHLEN = 1024; /* Maximum bytes in a path name / const MNTNAMLEN = 255; / Maximum bytes in a name / const FHSIZE3 = 64; / Maximum bytes in a V3 file handle */
5.1.5 Basic Data Types
typedef opaque fhandle3<FHSIZE3>;
typedef string dirpath<MNTPATHLEN>;
typedef string name<MNTNAMLEN>;
enum mountstat3 \{ MNT3_OK = 0, /* no error / MNT3ERR_PERM = 1, / Not owner / MNT3ERR_NOENT = 2, / No such file or directory / MNT3ERR_IO = 5, / I/O error / MNT3ERR_ACCES = 13, / Permission denied / MNT3ERR_NOTDIR = 20, / Not a directory / MNT3ERR_INVAL = 22, / Invalid argument / MNT3ERR_NAMETOOLONG = 63, / Filename too long / MNT3ERR_NOTSUPP = 10004, / Operation not supported / MNT3ERR_SERVERFAULT = 10006 / A failure on the server */ \};
5.2 Server Procedures
The following sections define the RPC procedures supplied by a MOUNT version 3 protocol server. The RPC procedure number is given at the top of the page with the name and version. The SYNOPSIS provides the name of the procedure, the list of the names of the arguments, the list of the names of the results, followed by the XDR argument declarations and results declarations. The information in the SYNOPSIS is specified in RPC Data Description Language as defined in [RFC1014]. The DESCRIPTION section tells what the procedure is expected to do and how its arguments and results are used. The ERRORS section lists the errors returned for specific types of failures. The IMPLEMENTATION field describes how the procedure is expected to work and how it should be used by clients.
program MOUNT_PROGRAM \\\{
version MOUNT_V3 \\\{
void MOUNTPROC3_NULL(void) = 0;
mountres3 MOUNTPROC3_MNT(dirpath) = 1;
mountlist MOUNTPROC3_DUMP(void) = 2;
void MOUNTPROC3_UMNT(dirpath) = 3;
void MOUNTPROC3_UMNTALL(void) = 4;
exports MOUNTPROC3_EXPORT(void) = 5;
\\\} = 3;
\\\} = 100005;
5.2.0 Procedure 0: Null - Do nothing
SYNOPSIS
void MOUNTPROC3_NULL(void) = 0;
DESCRIPTION
Procedure NULL does not do any work. It is made available
to allow server response testing and timing.
IMPLEMENTATION
It is important that this procedure do no work at all so
that it can be used to measure the overhead of processing
a service request. By convention, the NULL procedure
should never require any authentication. A server may
choose to ignore this convention, in a more secure
implementation, where responding to the NULL procedure
call acknowledges the existence of a resource to an
unauthenticated client.
ERRORS
Since the NULL procedure takes no MOUNT protocol arguments
and returns no MOUNT protocol response, it can not return
a MOUNT protocol error. However, it is possible that some
server implementations may return RPC errors based on
security and authentication requirements.
5.2.1 Procedure 1: MNT - Add mount entry
SYNOPSIS
mountres3 MOUNTPROC3_MNT(dirpath) = 1;
struct mountres3_ok \\\{
fhandle3 fhandle;
int auth_flavors`<>`;
\\\};
union mountres3 switch (mountstat3 fhs_status) \\\{
case MNT_OK:
mountres3_ok mountinfo;
default:
void;
\\\};
DESCRIPTION
Procedure MNT maps a pathname on the server to a file
handle. The pathname is an ASCII string that describes a
directory on the server. If the call is successful
(MNT3_OK), the server returns an NFS version 3 protocol
file handle and a vector of RPC authentication flavors
that are supported with the client's use of the file
handle (or any file handles derived from it). The
authentication flavors are defined in Section 7.2 and
section 9 of [RFC1057].
IMPLEMENTATION
If mountres3.fhs_status is MNT3_OK, then
mountres3.mountinfo contains the file handle for the
directory and a list of acceptable authentication
flavors. This file handle may only be used in the NFS
version 3 protocol. This procedure also results in the
server adding a new entry to its mount list recording that
this client has mounted the directory. AUTH_UNIX
authentication or better is required.
ERRORS
MNT3ERR_NOENT
MNT3ERR_IO
MNT3ERR_ACCES
MNT3ERR_NOTDIR
MNT3ERR_NAMETOOLONG
5.2.2 Procedure 2: DUMP - Return mount entries
SYNOPSIS
mountlist MOUNTPROC3_DUMP(void) = 2;
typedef struct mountbody *mountlist;
struct mountbody \\\{
name ml_hostname;
dirpath ml_directory;
mountlist ml_next;
\\\};
DESCRIPTION
Procedure DUMP returns the list of remotely mounted file
systems. The mountlist contains one entry for each client
host name and directory pair.
IMPLEMENTATION
This list is derived from a list maintained on the server
of clients that have requested file handles with the MNT
procedure. Entries are removed from this list only when a
client calls the UMNT or UMNTALL procedure. Entries may
become stale if a client crashes and does not issue either
UMNT calls for all of the file systems that it had
previously mounted or a UMNTALL to remove all entries that
existed for it on the server.
ERRORS
There are no MOUNT protocol errors which can be returned
from this procedure. However, RPC errors may be returned
for authentication or other RPC failures.
5.2.3 Procedure 3: UMNT - Remove mount entry
SYNOPSIS
void MOUNTPROC3_UMNT(dirpath) = 3;
DESCRIPTION
Procedure UMNT removes the mount list entry for the
directory that was previously the subject of a MNT call
from this client. AUTH_UNIX authentication or better is
required.
IMPLEMENTATION
Typically, server implementations have maintained a list
of clients which have file systems mounted. In the past,
this list has been used to inform clients that the server
was going to be shutdown.
ERRORS
There are no MOUNT protocol errors which can be returned
from this procedure. However, RPC errors may be returned
for authentication or other RPC failures.
5.2.4 Procedure 4: UMNTALL - Remove all mount entries
SYNOPSIS
void MOUNTPROC3_UMNTALL(void) = 4;
DESCRIPTION
Procedure UMNTALL removes all of the mount entries for
this client previously recorded by calls to MNT. AUTH_UNIX
authentication or better is required.
IMPLEMENTATION
This procedure should be used by clients when they are
recovering after a system shutdown. If the client could
not successfully unmount all of its file systems before
being shutdown or the client crashed because of a software
or hardware problem, there may be servers which still have
mount entries for this client. This is an easy way for the
client to inform all servers at once that it does not have
any mounted file systems. However, since this procedure
is generally implemented using broadcast RPC, it is only
of limited usefullness.
ERRORS
There are no MOUNT protocol errors which can be returned
from this procedure. However, RPC errors may be returned
for authentication or other RPC failures.
5.2.5 Procedure 5: EXPORT - Return export list
SYNOPSIS
exports MOUNTPROC3_EXPORT(void) = 5;
typedef struct groupnode *groups;
struct groupnode \\\{
name gr_name;
groups gr_next;
\\\};
typedef struct exportnode *exports;
struct exportnode \\\{
dirpath ex_dir;
groups ex_groups;
exports ex_next;
\\\};
DESCRIPTION
Procedure EXPORT returns a list of all the exported file
systems and which clients are allowed to mount each one.
The names in the group list are implementation-specific
and cannot be directly interpreted by clients. These names
can represent hosts or groups of hosts.
IMPLEMENTATION
This procedure generally returns the contents of a list of
shared or exported file systems. These are the file
systems which are made available to NFS version 3 protocol
clients.
ERRORS
There are no MOUNT protocol errors which can be returned
from this procedure. However, RPC errors may be returned
for authentication or other RPC failures.