home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1000s / rfc1094.txt < prev    next >
Text File  |  1989-03-02  |  50KB  |  1,515 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                             Sun Microsystems, Inc.
  8. Request for Comments: 1094                                    March 1989
  9.  
  10.  
  11.             NFS: Network File System Protocol Specification
  12.  
  13. STATUS OF THIS MEMO
  14.  
  15.    This RFC describes a protocol that Sun Microsystems, Inc., and others
  16.    are using.  A new version of the protocol is under development, but
  17.    others may benefit from the descriptions of the current protocol, and
  18.    discussion of some of the design issues.  Distribution of this memo
  19.    is unlimited.
  20.  
  21. 1. INTRODUCTION
  22.  
  23.    The Sun Network Filesystem (NFS) protocol provides transparent remote
  24.    access to shared files across networks.  The NFS protocol is designed
  25.    to be portable across different machines, operating systems, network
  26.    architectures, and transport protocols.  This portability is achieved
  27.    through the use of Remote Procedure Call (RPC) primitives built on
  28.    top of an eXternal Data Representation (XDR).  Implementations
  29.    already exist for a variety of machines, from personal computers to
  30.    supercomputers.
  31.  
  32.    The supporting mount protocol allows the server to hand out remote
  33.    access privileges to a restricted set of clients.  It performs the
  34.    operating system-specific functions that allow, for example, to
  35.    attach remote directory trees to some local file system.
  36.  
  37. 1.1.  Remote Procedure Call
  38.  
  39.    Sun's Remote Procedure Call specification provides a procedure-
  40.    oriented interface to remote services.  Each server supplies a
  41.    "program" that is a set of procedures.  NFS is one such program.  The
  42.    combination of host address, program number, and procedure number
  43.    specifies one remote procedure.  A goal of NFS was to not require any
  44.    specific level of reliability from its lower levels, so it could
  45.    potentially be used on many underlying transport protocols, or even
  46.    another remote procedure call implementation.  For ease of
  47.    discussion, the rest of this document will assume NFS is implemented
  48.    on top of Sun RPC, described in  RFC 1057, "RPC: Remote Procedure
  49.    Call Protocol Specification".
  50.  
  51. 1.2.  External Data Representation
  52.  
  53.    The eXternal Data Representation (XDR) standard provides a common way
  54.    of representing a set of data types over a network.  The NFS Protocol
  55.  
  56.  
  57.  
  58. Sun Microsystems, Inc.                                          [Page 1]
  59.  
  60. RFC 1094                NFS: Network File System              March 1989
  61.  
  62.  
  63.    Specification is written using the RPC data description language.
  64.    For more information, see RFC 1014, "XDR: External Data
  65.    Representation Standard".  Although automated RPC/XDR compilers exist
  66.    to generate server and client "stubs", NFS does not require their
  67.    use.  Any software that provides equivalent functionality can be
  68.    used, and if the encoding is exactly the same it can interoperate
  69.    with other implementations of NFS.
  70.  
  71. 1.3.  Stateless Servers
  72.  
  73.    The NFS protocol was intended to be as stateless as possible.  That
  74.    is, a server should not need to maintain any protocol state
  75.    information about any of its clients in order to function correctly.
  76.    Stateless servers have a distinct advantage over stateful servers in
  77.    the event of a failure.  With stateless servers, a client need only
  78.    retry a request until the server responds; it does not even need to
  79.    know that the server has crashed, or the network temporarily went
  80.    down.  The client of a stateful server, on the other hand, needs to
  81.    either detect a server failure and rebuild the server's state when it
  82.    comes back up, or cause client operations to fail.
  83.  
  84.    This may not sound like an important issue, but it affects the
  85.    protocol in some unexpected ways.  We feel that it may be worth a bit
  86.    of extra complexity in the protocol to be able to write very simple
  87.    servers that do not require fancy crash recovery.  Note that even if
  88.    a so-called "reliable" transport protocol such as TCP is used, the
  89.    client must still be able to handle interruptions of service by re-
  90.    opening connections when they time out.  Thus, a stateless protocol
  91.    may actually simplify the  implementation.
  92.  
  93.    On the other hand, NFS deals with objects such as files and
  94.    directories that inherently have state -- what good would a file be
  95.    if it did not keep its contents intact?  The goal was to not
  96.    introduce any extra state in the protocol itself.  Inherently
  97.    stateful operations such as file or record locking, and remote
  98.    execution,  were implemented as separate services, not described in
  99.    this document.
  100.  
  101.    The basic way to simplify recovery was to make operations as
  102.    "idempotent" as possible (so that they can potentially be repeated).
  103.    Some operations in this version of the protocol did not attain this
  104.    goal; luckily most of the operations (such as Read and Write) are
  105.    idempotent.  Also, most server failures occur between operations, not
  106.    between the receipt of an operation and the response.  Finally,
  107.    although actual server failures may be rare, in complex networks,
  108.    failures of any network, router, or bridge may be indistinguishable
  109.    from a server failure.
  110.  
  111.  
  112.  
  113.  
  114. Sun Microsystems, Inc.                                          [Page 2]
  115.  
  116. RFC 1094                NFS: Network File System              March 1989
  117.  
  118.  
  119. 2. NFS PROTOCOL DEFINITION
  120.  
  121.    Servers change over time, and so can the protocol that they use.  RPC
  122.    provides a version number with each RPC request.  This RFC describes
  123.    version two of the NFS protocol.  Even in the second version, there
  124.    are a few obsolete procedures and parameters, which will be removed
  125.    in later versions.  An RFC for version three of the NFS protocol is
  126.    currently under preparation.
  127.  
  128. 2.1.  File System Model
  129.  
  130.    NFS assumes a file system that is hierarchical, with directories as
  131.    all but the bottom level of files.  Each entry in a directory (file,
  132.    directory, device, etc.) has a string name.  Different operating
  133.    systems may have restrictions on the depth of the tree or the names
  134.    used, as well as using different syntax to represent the "pathname",
  135.    which is the concatenation of all the "components" (directory and
  136.    file names) in the name.  A "file system" is a tree on a single
  137.    server (usually a single disk or physical partition) with a specified
  138.    "root".  Some operating systems provide a "mount" operation to make
  139.    all file systems appear as a single tree, while others maintain a
  140.    "forest" of file systems.  Files are unstructured streams of
  141.    uninterpreted bytes.  Version 3 of NFS uses slightly more general
  142.    file system model.
  143.  
  144.    NFS looks up one component of a pathname at a time.  It may not be
  145.    obvious why it does not just take the whole pathname, traipse down
  146.    the directories, and return a file handle when it is done.  There are
  147.    several good reasons not to do this.  First, pathnames need
  148.    separators between the directory components, and different operating
  149.    systems use different separators.  We could define a Network Standard
  150.    Pathname Representation, but then every pathname would have to be
  151.    parsed and converted at each end.  Other issues are discussed in
  152.    section 3, NFS Implementation Issues.
  153.  
  154.    Although files and directories are similar objects in many ways,
  155.    different procedures are used to read directories and files.  This
  156.    provides a network standard format for representing directories.  The
  157.    same argument as above could have been used to justify a procedure
  158.    that returns only one directory entry per call.  The problem is
  159.    efficiency.  Directories can contain many entries, and a remote call
  160.    to return each would be just too slow.
  161.  
  162. 2.2.  Server Procedures
  163.  
  164.    The protocol definition is given as a set of procedures with
  165.    arguments and results defined using the RPC language (XDR language
  166.    extended with program, version, and procedure declarations).  A brief
  167.  
  168.  
  169.  
  170. Sun Microsystems, Inc.                                          [Page 3]
  171.  
  172. RFC 1094                NFS: Network File System              March 1989
  173.  
  174.  
  175.    description of the function of each procedure should provide enough
  176.    information to allow implementation.  Section 2.3 describes the basic
  177.    data types in more detail.
  178.  
  179.    All of the procedures in the NFS protocol are assumed to be
  180.    synchronous.  When a procedure returns to the client, the client can
  181.    assume that the operation has completed and any data associated with
  182.    the request is now on stable storage.  For example, a client WRITE
  183.    request may cause the server to update data blocks, filesystem
  184.    information blocks (such as indirect blocks), and file attribute
  185.    information (size and modify times).  When the WRITE returns to the
  186.    client, it can assume that the write is safe, even in case of a
  187.    server crash, and it can discard the data written.  This is a very
  188.    important part of the statelessness of the server.  If the server
  189.    waited to flush data from remote requests, the client would have to
  190.    save those requests so that it could resend them in case of a server
  191.    crash.
  192.  
  193.            /*
  194.             * Remote file service routines
  195.             */
  196.            program NFS_PROGRAM {
  197.                    version NFS_VERSION {
  198.                            void
  199.                            NFSPROC_NULL(void)              = 0;
  200.  
  201.                            attrstat
  202.                            NFSPROC_GETATTR(fhandle)        = 1;
  203.  
  204.                            attrstat
  205.                            NFSPROC_SETATTR(sattrargs)      = 2;
  206.  
  207.                            void
  208.                            NFSPROC_ROOT(void)              = 3;
  209.  
  210.                            diropres
  211.                            NFSPROC_LOOKUP(diropargs)       = 4;
  212.  
  213.                            readlinkres
  214.                            NFSPROC_READLINK(fhandle)       = 5;
  215.  
  216.                            readres
  217.                            NFSPROC_READ(readargs)          = 6;
  218.  
  219.                            void
  220.                            NFSPROC_WRITECACHE(void)        = 7;
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Sun Microsystems, Inc.                                          [Page 4]
  227.  
  228. RFC 1094                NFS: Network File System              March 1989
  229.  
  230.  
  231.                            attrstat
  232.                            NFSPROC_WRITE(writeargs)        = 8;
  233.  
  234.                            diropres
  235.                            NFSPROC_CREATE(createargs)      = 9;
  236.  
  237.                            stat
  238.                            NFSPROC_REMOVE(diropargs)       = 10;
  239.  
  240.                            stat
  241.                            NFSPROC_RENAME(renameargs)      = 11;
  242.  
  243.                            stat
  244.                            NFSPROC_LINK(linkargs)          = 12;
  245.  
  246.                            stat
  247.                            NFSPROC_SYMLINK(symlinkargs)    = 13;
  248.  
  249.                            diropres
  250.                            NFSPROC_MKDIR(createargs)       = 14;
  251.  
  252.                            stat
  253.                            NFSPROC_RMDIR(diropargs)        = 15;
  254.  
  255.                            readdirres
  256.                            NFSPROC_READDIR(readdirargs)    = 16;
  257.  
  258.                            statfsres
  259.                            NFSPROC_STATFS(fhandle)         = 17;
  260.                    } = 2;
  261.            } = 100003;
  262.  
  263. 2.2.1.  Do Nothing
  264.  
  265.            void
  266.            NFSPROC_NULL(void) = 0;
  267.  
  268.    This procedure does no work.  It is made available in all RPC
  269.    services to allow server response testing and timing.
  270.  
  271. 2.2.2.  Get File Attributes
  272.  
  273.            attrstat
  274.            NFSPROC_GETATTR (fhandle) = 1;
  275.  
  276.    If the reply status is NFS_OK, then the reply attributes contains the
  277.    attributes for the file given by the input fhandle.
  278.  
  279.  
  280.  
  281.  
  282. Sun Microsystems, Inc.                                          [Page 5]
  283.  
  284. RFC 1094                NFS: Network File System              March 1989
  285.  
  286.  
  287. 2.2.3.  Set File Attributes
  288.  
  289.            struct sattrargs {
  290.                    fhandle file;
  291.                    sattr attributes;
  292.            };
  293.  
  294.            attrstat
  295.            NFSPROC_SETATTR (sattrargs) = 2;
  296.  
  297.    The "attributes" argument contains fields which are either -1 or are
  298.    the new value for the attributes of "file".  If the reply status is
  299.    NFS_OK, then the reply attributes have the attributes of the file
  300.    after the "SETATTR" operation has completed.
  301.  
  302.    Notes:  The use of -1 to indicate an unused field in "attributes" is
  303.    changed in the next version of the protocol.
  304.  
  305. 2.2.4.  Get Filesystem Root
  306.  
  307.            void
  308.            NFSPROC_ROOT(void) = 3;
  309.  
  310.    Obsolete.  This procedure is no longer used because finding the root
  311.    file handle of a filesystem requires moving pathnames between client
  312.    and server.  To do this right, we would have to define a network
  313.    standard representation of pathnames.  Instead, the function of
  314.    looking up the root file handle is done by the MNTPROC_MNT procedure.
  315.    (See Appendix A, "Mount Protocol Definition", for details).
  316.  
  317. 2.2.5.  Look Up File Name
  318.  
  319.            diropres
  320.            NFSPROC_LOOKUP(diropargs) = 4;
  321.  
  322.    If the reply "status" is NFS_OK, then the reply "file" and reply
  323.    "attributes" are the file handle and attributes for the file "name"
  324.    in the directory given by "dir" in the argument.
  325.  
  326. 2.2.6.  Read From Symbolic Link
  327.  
  328.            union readlinkres switch (stat status) {
  329.            case NFS_OK:
  330.                path data;
  331.            default:
  332.                void;
  333.            };
  334.  
  335.  
  336.  
  337.  
  338. Sun Microsystems, Inc.                                          [Page 6]
  339.  
  340. RFC 1094                NFS: Network File System              March 1989
  341.  
  342.  
  343.            readlinkres
  344.            NFSPROC_READLINK(fhandle) = 5;
  345.  
  346.    If "status" has the value NFS_OK, then the reply "data" is the data
  347.    in the symbolic link given by the file referred to by the fhandle
  348.    argument.
  349.  
  350.    Notes:  Since NFS always parses pathnames on the client, the pathname
  351.    in a symbolic link may mean something different (or be meaningless)
  352.    on a different client or on the server if a different pathname syntax
  353.    is used.
  354.  
  355. 2.2.7.  Read From File
  356.  
  357.            struct readargs {
  358.                    fhandle file;
  359.                    unsigned offset;
  360.                    unsigned count;
  361.                    unsigned totalcount;
  362.            };
  363.  
  364.            union readres switch (stat status) {
  365.            case NFS_OK:
  366.                    fattr attributes;
  367.                    nfsdata data;
  368.            default:
  369.                    void;
  370.            };
  371.  
  372.            readres
  373.            NFSPROC_READ(readargs) = 6;
  374.  
  375.    Returns up to "count" bytes of "data" from the file given by "file",
  376.    starting at "offset" bytes from the beginning of the file.  The first
  377.    byte of the file is at offset zero.  The file attributes after the
  378.    read takes place are returned in "attributes".
  379.  
  380.    Notes:  The argument "totalcount" is unused, and is removed in the
  381.    next protocol revision.
  382.  
  383. 2.2.8.  Write to Cache
  384.  
  385.            void
  386.            NFSPROC_WRITECACHE(void) = 7;
  387.  
  388.    To be used in the next protocol revision.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Sun Microsystems, Inc.                                          [Page 7]
  395.  
  396. RFC 1094                NFS: Network File System              March 1989
  397.  
  398.  
  399. 2.2.9.  Write to File
  400.  
  401.            struct writeargs {
  402.                    fhandle file;
  403.                    unsigned beginoffset;
  404.                    unsigned offset;
  405.                    unsigned totalcount;
  406.                    nfsdata data;
  407.            };
  408.  
  409.            attrstat
  410.            NFSPROC_WRITE(writeargs) = 8;
  411.  
  412.    Writes "data" beginning "offset" bytes from the beginning of "file".
  413.    The first byte of the file is at offset zero.  If the reply "status"
  414.    is NFS_OK, then the reply "attributes" contains the attributes of the
  415.    file after the write has completed.  The write operation is atomic.
  416.    Data from this "WRITE" will not be mixed with data from another
  417.    client's "WRITE".
  418.  
  419.    Notes:  The arguments "beginoffset" and "totalcount" are ignored and
  420.    are removed in the next protocol revision.
  421.  
  422. 2.2.10.  Create File
  423.  
  424.            struct createargs {
  425.                    diropargs where;
  426.                    sattr attributes;
  427.            };
  428.  
  429.            diropres
  430.            NFSPROC_CREATE(createargs) = 9;
  431.  
  432.    The file "name" is created in the directory given by "dir".  The
  433.    initial attributes of the new file are given by "attributes".  A
  434.    reply "status" of NFS_OK indicates that the file was created, and
  435.    reply "file" and reply "attributes" are its file handle and
  436.    attributes.  Any other reply "status" means that the operation failed
  437.    and no file was created.
  438.  
  439.    Notes:  This routine should pass an exclusive create flag, meaning
  440.    "create the file only if it is not already there".
  441.  
  442. 2.2.11.  Remove File
  443.  
  444.            stat
  445.            NFSPROC_REMOVE(diropargs) = 10;
  446.  
  447.  
  448.  
  449.  
  450. Sun Microsystems, Inc.                                          [Page 8]
  451.  
  452. RFC 1094                NFS: Network File System              March 1989
  453.  
  454.  
  455.    The file "name" is removed from the directory given by "dir".  A
  456.    reply of NFS_OK means the directory entry was removed.
  457.  
  458.    Notes:  possibly non-idempotent operation.
  459.  
  460. 2.2.12.  Rename File
  461.  
  462.            struct renameargs {
  463.                    diropargs from;
  464.                    diropargs to;
  465.            };
  466.  
  467.            stat
  468.            NFSPROC_RENAME(renameargs) = 11;
  469.  
  470.    The existing file "from.name" in the directory given by "from.dir" is
  471.    renamed to "to.name" in the directory given by "to.dir".  If the
  472.    reply is NFS_OK, the file was renamed.  The RENAME operation is
  473.    atomic on the server; it cannot be interrupted in the middle.
  474.  
  475.    Notes:  possibly non-idempotent operation.
  476.  
  477. 2.2.13.  Create Link to File
  478.  
  479.    Procedure 12, Version 2.
  480.  
  481.            struct linkargs {
  482.                    fhandle from;
  483.                    diropargs to;
  484.            };
  485.  
  486.            stat
  487.            NFSPROC_LINK(linkargs) = 12;
  488.  
  489.    Creates the file "to.name" in the directory given by "to.dir", which
  490.    is a hard link to the existing file given by "from".  If the return
  491.    value is NFS_OK, a link was created.  Any other return value
  492.    indicates an error, and the link was not created.
  493.  
  494.    A hard link should have the property that changes to either of the
  495.    linked files are reflected in both files.  When a hard link is made
  496.    to a file, the attributes for the file should have a value for
  497.    "nlink" that is one greater than the value before the link.
  498.  
  499.    Notes:  possibly non-idempotent operation.
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Sun Microsystems, Inc.                                          [Page 9]
  507.  
  508. RFC 1094                NFS: Network File System              March 1989
  509.  
  510.  
  511. 2.2.14.  Create Symbolic Link
  512.  
  513.            struct symlinkargs {
  514.                    diropargs from;
  515.                    path to;
  516.                    sattr attributes;
  517.            };
  518.  
  519.            stat
  520.            NFSPROC_SYMLINK(symlinkargs) = 13;
  521.  
  522.    Creates the file "from.name" with ftype NFLNK in the directory given
  523.    by "from.dir".  The new file contains the pathname "to" and has
  524.    initial attributes given by "attributes".  If the return value is
  525.    NFS_OK, a link was created.  Any other return value indicates an
  526.    error, and the link was not created.
  527.  
  528.    A symbolic link is a pointer to another file.  The name given in "to"
  529.    is not interpreted by the server, only stored in the newly created
  530.    file.  When the client references a file that is a symbolic link, the
  531.    contents of the symbolic link are normally transparently
  532.    reinterpreted as a pathname to substitute.  A READLINK operation
  533.    returns the data to the client for interpretation.
  534.  
  535.    Notes:  On UNIX servers the attributes are never used, since symbolic
  536.    links always have mode 0777.
  537.  
  538. 2.2.15.  Create Directory
  539.  
  540.            diropres
  541.            NFSPROC_MKDIR (createargs) = 14;
  542.  
  543.    The new directory "where.name" is created in the directory given by
  544.    "where.dir".  The initial attributes of the new directory are given
  545.    by "attributes".  A reply "status" of NFS_OK indicates that the new
  546.    directory was created, and reply "file" and reply "attributes" are
  547.    its file handle and attributes.  Any other reply "status" means that
  548.    the operation failed and no directory was created.
  549.  
  550.    Notes:  possibly non-idempotent operation.
  551.  
  552. 2.2.16.  Remove Directory
  553.  
  554.            stat
  555.            NFSPROC_RMDIR(diropargs) = 15;
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Sun Microsystems, Inc.                                         [Page 10]
  563.  
  564. RFC 1094                NFS: Network File System              March 1989
  565.  
  566.  
  567.    The existing empty directory "name" in the directory given by "dir"
  568.    is removed.  If the reply is NFS_OK, the directory was removed.
  569.  
  570.    Notes:  possibly non-idempotent operation.
  571.  
  572. 2.2.17.  Read From Directory
  573.  
  574.            struct readdirargs {
  575.                    fhandle dir;
  576.                    nfscookie cookie;
  577.                    unsigned count;
  578.            };
  579.  
  580.            struct entry {
  581.                    unsigned fileid;
  582.                    filename name;
  583.                    nfscookie cookie;
  584.                    entry *nextentry;
  585.            };
  586.  
  587.            union readdirres switch (stat status) {
  588.            case NFS_OK:
  589.                    struct {
  590.                            entry *entries;
  591.                            bool eof;
  592.                    } readdirok;
  593.            default:
  594.                    void;
  595.            };
  596.  
  597.            readdirres
  598.            NFSPROC_READDIR (readdirargs) = 16;
  599.  
  600.    Returns a variable number of directory entries, with a total size of
  601.    up to "count" bytes, from the directory given by "dir".  If the
  602.    returned value of "status" is NFS_OK, then it is followed by a
  603.    variable number of "entry"s.  Each "entry" contains a "fileid" which
  604.    consists of a unique number to identify the file within a filesystem,
  605.    the "name" of the file, and a "cookie" which is an opaque pointer to
  606.    the next entry in the directory.  The cookie is used in the next
  607.    READDIR call to get more entries starting at a given point in the
  608.    directory.  The special cookie zero (all bits zero) can be used to
  609.    get the entries starting at the beginning of the directory.  The
  610.    "fileid" field should be the same number as the "fileid" in the the
  611.    attributes of the file.  (See section "2.3.5. fattr" under "Basic
  612.    Data Types".)  The "eof" flag has a value of TRUE if there are no
  613.    more entries in the directory.
  614.  
  615.  
  616.  
  617.  
  618. Sun Microsystems, Inc.                                         [Page 11]
  619.  
  620. RFC 1094                NFS: Network File System              March 1989
  621.  
  622.  
  623. 2.2.18.  Get Filesystem Attributes
  624.  
  625.            union statfsres (stat status) {
  626.            case NFS_OK:
  627.                struct {
  628.                    unsigned tsize;
  629.                    unsigned bsize;
  630.                    unsigned blocks;
  631.                    unsigned bfree;
  632.                    unsigned bavail;
  633.                } info;
  634.            default:
  635.                    void;
  636.            };
  637.  
  638.            statfsres
  639.            NFSPROC_STATFS(fhandle) = 17;
  640.  
  641.    If the reply "status" is NFS_OK, then the reply "info" gives the
  642.    attributes for the filesystem that contains file referred to by the
  643.    input fhandle.  The attribute fields contain the following values:
  644.  
  645.       tsize   The optimum transfer size of the server in bytes.  This is
  646.               the number of bytes the server would like to have in the
  647.               data part of READ and WRITE requests.
  648.  
  649.       bsize   The block size in bytes of the filesystem.
  650.  
  651.       blocks  The total number of "bsize" blocks on the filesystem.
  652.  
  653.       bfree   The number of free "bsize" blocks on the filesystem.
  654.  
  655.       bavail  The number of "bsize" blocks available to non-privileged
  656.               users.
  657.  
  658.    Notes:  This call does not work well if a filesystem has variable
  659.    size blocks.
  660.  
  661. 2.3.  Basic Data Types
  662.  
  663.    The following XDR definitions are basic structures and types used in
  664.    other structures described further on.
  665.  
  666. 2.3.1.  stat
  667.  
  668.        enum stat {
  669.            NFS_OK = 0,
  670.            NFSERR_PERM=1,
  671.  
  672.  
  673.  
  674. Sun Microsystems, Inc.                                         [Page 12]
  675.  
  676. RFC 1094                NFS: Network File System              March 1989
  677.  
  678.  
  679.            NFSERR_NOENT=2,
  680.            NFSERR_IO=5,
  681.            NFSERR_NXIO=6,
  682.            NFSERR_ACCES=13,
  683.            NFSERR_EXIST=17,
  684.            NFSERR_NODEV=19,
  685.            NFSERR_NOTDIR=20,
  686.            NFSERR_ISDIR=21,
  687.            NFSERR_FBIG=27,
  688.            NFSERR_NOSPC=28,
  689.            NFSERR_ROFS=30,
  690.            NFSERR_NAMETOOLONG=63,
  691.            NFSERR_NOTEMPTY=66,
  692.            NFSERR_DQUOT=69,
  693.            NFSERR_STALE=70,
  694.            NFSERR_WFLUSH=99
  695.        };
  696.  
  697.    The "stat" type is returned with every procedure's results.  A value
  698.    of NFS_OK indicates that the call completed successfully and the
  699.    results are valid.  The other values indicate some kind of error
  700.    occurred on the server side during the servicing of the procedure.
  701.    The error values are derived from UNIX error numbers.
  702.  
  703.    NFSERR_PERM
  704.       Not owner.  The caller does not have correct ownership to perform
  705.       the requested operation.
  706.  
  707.    NFSERR_NOENT
  708.       No such file or directory.  The file or directory specified does
  709.       not exist.
  710.  
  711.    NFSERR_IO
  712.       Some sort of hard error occurred when the operation was in
  713.       progress.  This could be a disk error, for example.
  714.  
  715.    NFSERR_NXIO
  716.       No such device or address.
  717.  
  718.    NFSERR_ACCES
  719.       Permission denied.  The caller does not have the correct
  720.       permission to perform the requested operation.
  721.  
  722.    NFSERR_EXIST
  723.       File exists.  The file specified already exists.
  724.  
  725.    NFSERR_NODEV
  726.       No such device.
  727.  
  728.  
  729.  
  730. Sun Microsystems, Inc.                                         [Page 13]
  731.  
  732. RFC 1094                NFS: Network File System              March 1989
  733.  
  734.  
  735.    NFSERR_NOTDIR
  736.       Not a directory.  The caller specified a non-directory in a
  737.       directory operation.
  738.  
  739.    NFSERR_ISDIR
  740.       Is a directory.  The caller specified a directory in a non-
  741.       directory operation.
  742.  
  743.    NFSERR_FBIG
  744.       File too large.  The operation caused a file to grow beyond the
  745.       server's limit.
  746.  
  747.    NFSERR_NOSPC
  748.       No space left on device.  The operation caused the server's
  749.       filesystem to reach its limit.
  750.  
  751.    NFSERR_ROFS
  752.       Read-only filesystem.  Write attempted on a read-only filesystem.
  753.  
  754.    NFSERR_NAMETOOLONG
  755.       File name too long.  The file name in an operation was too long.
  756.  
  757.    NFSERR_NOTEMPTY
  758.       Directory not empty.  Attempted to remove a directory that was not
  759.       empty.
  760.  
  761.    NFSERR_DQUOT
  762.       Disk quota exceeded.  The client's disk quota on the server has
  763.       been exceeded.
  764.  
  765.    NFSERR_STALE
  766.       The "fhandle" given in the arguments was invalid.  That is, the
  767.       file referred to by that file handle no longer exists, or access
  768.       to it has been revoked.
  769.  
  770.    NFSERR_WFLUSH
  771.       The server's write cache used in the "WRITECACHE" call got flushed
  772.       to disk.
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Sun Microsystems, Inc.                                         [Page 14]
  787.  
  788. RFC 1094                NFS: Network File System              March 1989
  789.  
  790.  
  791. 2.3.2.  ftype
  792.  
  793.           enum ftype {
  794.               NFNON = 0,
  795.               NFREG = 1,
  796.               NFDIR = 2,
  797.               NFBLK = 3,
  798.               NFCHR = 4,
  799.               NFLNK = 5
  800.           };
  801.  
  802.       The enumeration "ftype" gives the type of a file.  The type NFNON
  803.       indicates a non-file, NFREG is a regular file, NFDIR is a
  804.       directory, NFBLK is a block-special device, NFCHR is a character-
  805.       special device, and NFLNK is a symbolic link.
  806.  
  807. 2.3.3.  fhandle
  808.  
  809.           typedef opaque fhandle[FHSIZE];
  810.  
  811.       The "fhandle" is the file handle passed between the server and the
  812.       client.  All file operations are done using file handles to refer
  813.       to a file or directory.  The file handle can contain whatever
  814.       information the server needs to distinguish an individual file.
  815.  
  816. 2.3.4.  timeval
  817.  
  818.           struct timeval {
  819.               unsigned int seconds;
  820.               unsigned int useconds;
  821.           };
  822.  
  823.       The "timeval" structure is the number of seconds and microseconds
  824.       since midnight January 1, 1970, Greenwich Mean Time.  It is used
  825.       to pass time and date information.
  826.  
  827. 2.3.5.  fattr
  828.  
  829.           struct fattr {
  830.               ftype        type;
  831.               unsigned int mode;
  832.               unsigned int nlink;
  833.               unsigned int uid;
  834.               unsigned int gid;
  835.               unsigned int size;
  836.               unsigned int blocksize;
  837.               unsigned int rdev;
  838.               unsigned int blocks;
  839.  
  840.  
  841.  
  842. Sun Microsystems, Inc.                                         [Page 15]
  843.  
  844. RFC 1094                NFS: Network File System              March 1989
  845.  
  846.  
  847.               unsigned int fsid;
  848.               unsigned int fileid;
  849.               timeval      atime;
  850.               timeval      mtime;
  851.               timeval      ctime;
  852.           };
  853.  
  854.       The "fattr" structure contains the attributes of a file; "type" is
  855.       the type of the file; "nlink" is the number of hard links to the
  856.       file (the number of different names for the same file); "uid" is
  857.       the user identification number of the owner of the file; "gid" is
  858.       the group identification number of the group of the file; "size"
  859.       is the size in bytes of the file; "blocksize" is the size in bytes
  860.       of a block of the file; "rdev" is the device number of the file if
  861.       it is type NFCHR or NFBLK; "blocks" is the number of blocks the
  862.       file takes up on disk; "fsid" is the file system identifier for
  863.       the filesystem containing the file; "fileid" is a number that
  864.       uniquely identifies the file within its filesystem; "atime" is the
  865.       time when the file was last accessed for either read or write;
  866.       "mtime" is the time when the file data was last modified
  867.       (written); and "ctime" is the time when the status of the file was
  868.       last changed.  Writing to the file also changes "ctime" if the
  869.       size of the file changes.
  870.  
  871.       "Mode" is the access mode encoded as a set of bits.  Notice that
  872.       the file type is specified both in the mode bits and in the file
  873.       type.  This is really a bug in the protocol and will be fixed in
  874.       future versions.  The descriptions given below specify the bit
  875.       positions using octal numbers.
  876.  
  877.       0040000 This is a directory; "type" field should be NFDIR.
  878.       0020000 This is a character special file; "type" field should
  879.               be NFCHR.
  880.       0060000 This is a block special file; "type" field should be
  881.               NFBLK.
  882.       0100000 This is a regular file; "type" field should be NFREG.
  883.       0120000 This is a symbolic link file;  "type" field should be
  884.               NFLNK.
  885.       0140000 This is a named socket; "type" field should be NFNON.
  886.       0004000 Set user id on execution.
  887.       0002000 Set group id on execution.
  888.       0001000 Save swapped text even after use.
  889.       0000400 Read permission for owner.
  890.       0000200 Write permission for owner.
  891.       0000100 Execute and search permission for owner.
  892.       0000040 Read permission for group.
  893.       0000020 Write permission for group.
  894.       0000010 Execute and search permission for group.
  895.  
  896.  
  897.  
  898. Sun Microsystems, Inc.                                         [Page 16]
  899.  
  900. RFC 1094                NFS: Network File System              March 1989
  901.  
  902.  
  903.       0000004 Read permission for others.
  904.       0000002 Write permission for others.
  905.       0000001 Execute and search permission for others.
  906.  
  907.       Notes:  The bits are the same as the mode bits returned by the
  908.       stat(2) system call in UNIX.  The file type is specified both in
  909.       the mode bits and in the file type.  This is fixed in future
  910.       versions.
  911.  
  912.       The "rdev" field in the attributes structure is an operating
  913.       system specific device specifier.  It will be removed and
  914.       generalized in the next revision of the protocol.
  915.  
  916. 2.3.6.  sattr
  917.  
  918.           struct sattr {
  919.               unsigned int mode;
  920.               unsigned int uid;
  921.               unsigned int gid;
  922.               unsigned int size;
  923.               timeval      atime;
  924.               timeval      mtime;
  925.           };
  926.  
  927.       The "sattr" structure contains the file attributes which can be
  928.       set from the client.  The fields are the same as for "fattr"
  929.       above.  A "size" of zero means the file should be truncated.  A
  930.       value of -1 indicates a field that should be ignored.
  931.  
  932. 2.3.7.  filename
  933.  
  934.           typedef string filename<MAXNAMLEN>;
  935.  
  936.       The type "filename" is used for passing file names or pathname
  937.       components.
  938.  
  939. 2.3.8.  path
  940.  
  941.           typedef string path<MAXPATHLEN>;
  942.  
  943.       The type "path" is a pathname.  The server considers it as a
  944.       string with no internal structure, but to the client it is the
  945.       name of a node in a filesystem tree.
  946.  
  947. 2.3.9.  attrstat
  948.  
  949.           union attrstat switch (stat status) {
  950.           case NFS_OK:
  951.  
  952.  
  953.  
  954. Sun Microsystems, Inc.                                         [Page 17]
  955.  
  956. RFC 1094                NFS: Network File System              March 1989
  957.  
  958.  
  959.               fattr attributes;
  960.           default:
  961.               void;
  962.           };
  963.  
  964.       The "attrstat" structure is a common procedure result.  It
  965.       contains a "status" and, if the call succeeded, it also contains
  966.       the attributes of the file on which the operation was done.
  967.  
  968. 2.3.10.  diropargs
  969.  
  970.           struct diropargs {
  971.               fhandle  dir;
  972.               filename name;
  973.           };
  974.  
  975.       The "diropargs" structure is used in directory operations.  The
  976.       "fhandle" "dir" is the directory in which to find the file "name".
  977.       A directory operation is one in which the directory is affected.
  978.  
  979. 2.3.11.  diropres
  980.  
  981.           union diropres switch (stat status) {
  982.           case NFS_OK:
  983.               struct {
  984.                   fhandle file;
  985.                   fattr   attributes;
  986.               } diropok;
  987.           default:
  988.               void;
  989.           };
  990.  
  991.       The results of a directory operation are returned in a "diropres"
  992.       structure.  If the call succeeded, a new file handle "file" and
  993.       the "attributes" associated with that file are returned along with
  994.       the "status".
  995.  
  996. 3. NFS IMPLEMENTATION ISSUES
  997.  
  998.    The NFS protocol was designed to allow different operating systems to
  999.    share files.  However, since it was designed in a UNIX environment,
  1000.    many operations have semantics similar to the operations of the UNIX
  1001.    file system.  This section discusses some of the implementation-
  1002.    specific details and semantic issues.
  1003.  
  1004. 3.1.  Server/Client Relationship
  1005.  
  1006.    The NFS protocol is designed to allow servers to be as simple and
  1007.  
  1008.  
  1009.  
  1010. Sun Microsystems, Inc.                                         [Page 18]
  1011.  
  1012. RFC 1094                NFS: Network File System              March 1989
  1013.  
  1014.  
  1015.    general as possible.  Sometimes the simplicity of the server can be a
  1016.    problem, if the client wants to implement complicated filesystem
  1017.    semantics.
  1018.  
  1019.    For example, some operating systems allow removal of open files.  A
  1020.    process can open a file and, while it is open, remove it from the
  1021.    directory.  The file can be read and written as long as the process
  1022.    keeps it open, even though the file has no name in the filesystem.
  1023.    It is impossible for a stateless server to implement these semantics.
  1024.    The client can do some tricks such as renaming the file on remove,
  1025.    and only removing it on close.  We believe that the server provides
  1026.    enough functionality to implement most file system semantics on the
  1027.    client.
  1028.  
  1029.    Every NFS client can also potentially be a server, and remote and
  1030.    local mounted filesystems can be freely intermixed.  This leads to
  1031.    some interesting problems when a client travels down the directory
  1032.    tree of a remote filesystem and reaches the mount point on the server
  1033.    for another remote filesystem.  Allowing the server to follow the
  1034.    second remote mount would require loop detection, server lookup, and
  1035.    user revalidation.  Instead, we decided not to let clients cross a
  1036.    server's mount point.  When a client does a LOOKUP on a directory on
  1037.    which the server has mounted a filesystem, the client sees the
  1038.    underlying directory instead of the mounted directory.
  1039.  
  1040.    For example, if a server has a file system called "/usr" and mounts
  1041.    another file system on  "/usr/src", if a client mounts "/usr", it
  1042.    does NOT see the mounted version of "/usr/src".  A client could do
  1043.    remote mounts that match the server's mount points to maintain the
  1044.    server's view.  In this example, the client would also have to mount
  1045.    "/usr/src" in addition to "/usr", even if they are from the same
  1046.    server.
  1047.  
  1048. 3.2. Pathname Interpretation
  1049.  
  1050.    There are a few complications to the rule that pathnames are always
  1051.    parsed on the client.  For example, symbolic links could have
  1052.    different interpretations on different clients.  Another common
  1053.    problem for non-UNIX implementations is the special interpretation of
  1054.    the pathname ".." to mean the parent of a given directory.  The next
  1055.    revision of the protocol uses an explicit flag to indicate the parent
  1056.    instead.
  1057.  
  1058. 3.3.  Permission Issues
  1059.  
  1060.    The NFS protocol, strictly speaking, does not define the permission
  1061.    checking used by servers.  However, it is expected that a server will
  1062.    do normal operating system permission checking using AUTH_UNIX style
  1063.  
  1064.  
  1065.  
  1066. Sun Microsystems, Inc.                                         [Page 19]
  1067.  
  1068. RFC 1094                NFS: Network File System              March 1989
  1069.  
  1070.  
  1071.    authentication as the basis of its protection mechanism.  The server
  1072.    gets the client's effective "uid", effective "gid", and groups on
  1073.    each call and uses them to check permission.  There are various
  1074.    problems with this method that can been resolved in interesting ways.
  1075.  
  1076.    Using "uid" and "gid" implies that the client and server share the
  1077.    same "uid" list.  Every server and client pair must have the same
  1078.    mapping from user to "uid" and from group to "gid".  Since every
  1079.    client can also be a server, this tends to imply that the whole
  1080.    network shares the same "uid/gid" space.  AUTH_DES (and the next
  1081.    revision of the NFS protocol) uses string names instead of numbers,
  1082.    but there are still complex problems to be solved.
  1083.  
  1084.    Another problem arises due to the usually stateful open operation.
  1085.    Most operating systems check permission at open time, and then check
  1086.    that the file is open on each read and write request.  With stateless
  1087.    servers, the server has no idea that the file is open and must do
  1088.    permission checking on each read and write call.  On a local
  1089.    filesystem, a user can open a file and then change the permissions so
  1090.    that no one is allowed to touch it, but will still be able to write
  1091.    to the file because it is open.  On a remote filesystem, by contrast,
  1092.    the write would fail.  To get around this problem, the server's
  1093.    permission checking algorithm should allow the owner of a file to
  1094.    access it regardless of the permission setting.
  1095.  
  1096.    A similar problem has to do with paging in from a file over the
  1097.    network.  The operating system usually checks for execute permission
  1098.    before opening a file for demand paging, and then reads blocks from
  1099.    the open file.  The file may not have read permission, but after it
  1100.    is opened it does not matter.  An NFS server can not tell the
  1101.    difference between a normal file read and a demand page-in read.  To
  1102.    make this work, the server allows reading of files if the "uid" given
  1103.    in the call has either execute or read permission on the file.
  1104.  
  1105.    In most operating systems, a particular user (on UNIX, the user ID
  1106.    zero) has access to all files no matter what permission and ownership
  1107.    they have.  This "super-user" permission may not be allowed on the
  1108.    server, since anyone who can become super-user on their workstation
  1109.    could gain access to all remote files.  The UNIX server by default
  1110.    maps user id 0 to -2 before doing its access checking.  This works
  1111.    except for NFS root filesystems, where super-user access cannot be
  1112.    avoided.
  1113.  
  1114. 3.4.  RPC Information
  1115.  
  1116.    Authentication
  1117.       The NFS service uses AUTH_UNIX,  AUTH_DES, or AUTH_SHORT style
  1118.       authentication, except in the NULL procedure where AUTH_NONE is
  1119.  
  1120.  
  1121.  
  1122. Sun Microsystems, Inc.                                         [Page 20]
  1123.  
  1124. RFC 1094                NFS: Network File System              March 1989
  1125.  
  1126.  
  1127.       also allowed.
  1128.  
  1129.    Transport Protocols
  1130.       NFS is supported normally on UDP.
  1131.  
  1132.    Port Number
  1133.       The NFS protocol currently uses the UDP port number 2049.  This is
  1134.       not an officially assigned port, so later versions of the protocol
  1135.       use the "Portmapping" facility of RPC.
  1136.  
  1137. 3.5.  Sizes of XDR Structures
  1138.  
  1139.    These are the sizes, given in decimal bytes, of various XDR
  1140.    structures used in the protocol:
  1141.  
  1142.    /*
  1143.     * The maximum number of bytes of data in a READ or WRITE
  1144.     * request.
  1145.     */
  1146.    const MAXDATA = 8192;
  1147.  
  1148.    /* The maximum number of bytes in a pathname argument. */
  1149.    const MAXPATHLEN = 1024;
  1150.  
  1151.    /* The maximum number of bytes in a file name argument. */
  1152.    const MAXNAMLEN = 255;
  1153.  
  1154.    /* The size in bytes of the opaque "cookie" passed by READDIR. */
  1155.    const COOKIESIZE  = 4;
  1156.  
  1157.    /* The size in bytes of the opaque file handle. */
  1158.    const FHSIZE = 32;
  1159.  
  1160. 3.6. Setting RPC Parameters
  1161.  
  1162.    Various file system parameters and options should be set at mount
  1163.    time.  The mount protocol is described in the appendix below.  For
  1164.    example, "Soft" mounts as well as "Hard" mounts are usually both
  1165.    provided.  Soft mounted file systems return errors when RPC
  1166.    operations fail (after a given number of optional retransmissions),
  1167.    while hard mounted file systems continue to retransmit forever.  The
  1168.    maximum transfer sizes are implementation dependent.  For efficient
  1169.    operation over a local network, 8192 bytes of data are normally used.
  1170.    This may result in lower-level fragmentation (such as at the IP
  1171.    level).  Since some network interfaces may not allow such packets,
  1172.    for operation over slower-speed networks or hosts, or through
  1173.    gateways, transfer sizes of 512 or 1024 bytes often provide better
  1174.    results.
  1175.  
  1176.  
  1177.  
  1178. Sun Microsystems, Inc.                                         [Page 21]
  1179.  
  1180. RFC 1094                NFS: Network File System              March 1989
  1181.  
  1182.  
  1183.    Clients and servers may need to keep caches of recent operations to
  1184.    help avoid problems with non-idempotent operations.  For example, if
  1185.    the transport protocol drops the response for a Remove File
  1186.    operation, upon retransmission the server may return an error code of
  1187.    NFSERR_NOENT instead of NFS_OK.  But if the server keeps around the
  1188.    last operation requested and its result, it could return the proper
  1189.    success code.  Of course, the server could be crashed and rebooted
  1190.    between retransmissions, but a small cache (even a single entry)
  1191.    would solve most problems.
  1192.  
  1193.  
  1194.  
  1195.  
  1196.  
  1197.  
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Sun Microsystems, Inc.                                         [Page 22]
  1235.  
  1236. RFC 1094                NFS: Network File System              March 1989
  1237.  
  1238.  
  1239.                    Appendix A. MOUNT PROTOCOL DEFINITION
  1240.  
  1241. A.1.  Introduction
  1242.  
  1243.    The mount protocol is separate from, but related to, the NFS
  1244.    protocol.  It provides operating system specific services to get the
  1245.    NFS off the ground -- looking up server path names, validating user
  1246.    identity, and checking access permissions.  Clients use the mount
  1247.    protocol to get the first file handle, which allows them entry into a
  1248.    remote filesystem.
  1249.  
  1250.    The mount protocol is kept separate from the NFS protocol to make it
  1251.    easy to plug in new access checking and validation methods without
  1252.    changing the NFS server protocol.
  1253.  
  1254.    Notice that the protocol definition implies stateful servers because
  1255.    the server maintains a list of client's mount requests.  The mount
  1256.    list information is not critical for the correct functioning of
  1257.    either the client or the server.  It is intended for advisory use
  1258.    only, for example, to warn possible clients when a server is going
  1259.    down.
  1260.  
  1261.    Version one of the mount protocol is used with version two of the NFS
  1262.    protocol.  The only information communicated between these two
  1263.    protocols is the "fhandle" structure.
  1264.  
  1265. A.2.  RPC Information
  1266.  
  1267.    Authentication
  1268.       The mount service uses AUTH_UNIX and AUTH_NONE style
  1269.       authentication only.
  1270.  
  1271.    Transport Protocols
  1272.       The mount service is supported on both UDP and TCP.
  1273.  
  1274.    Port Number
  1275.       Consult the server's portmapper, described in RFC 1057, "RPC:
  1276.       Remote Procedure Call Protocol Specification", to find the port
  1277.       number on which the mount service is registered.
  1278.  
  1279. A.3.  Sizes of XDR Structures
  1280.  
  1281.    These are the sizes, given in decimal bytes, of various XDR
  1282.    structures used in the protocol:
  1283.  
  1284.            /* The maximum number of bytes in a pathname argument. */
  1285.            const MNTPATHLEN = 1024;
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Sun Microsystems, Inc.                                         [Page 23]
  1291.  
  1292. RFC 1094                NFS: Network File System              March 1989
  1293.  
  1294.  
  1295.            /* The maximum number of bytes in a name argument. */
  1296.            const MNTNAMLEN = 255;
  1297.  
  1298.            /* The size in bytes of the opaque file handle. */
  1299.            const FHSIZE = 32;
  1300.  
  1301. A.4.  Basic Data Types
  1302.  
  1303.    This section presents the data types used by the mount protocol.  In
  1304.    many cases they are similar to the types used in NFS.
  1305.  
  1306. A.4.1.  fhandle
  1307.  
  1308.        typedef opaque fhandle[FHSIZE];
  1309.  
  1310.    The type "fhandle" is the file handle that the server passes to the
  1311.    client.  All file operations are done using file handles to refer to
  1312.    a file or directory.  The file handle can contain whatever
  1313.    information the server needs to distinguish an individual file.
  1314.  
  1315.    This is the same as the "fhandle" XDR definition in version 2 of the
  1316.    NFS protocol; see section "2.3.3. fhandle" under "Basic Data Types".
  1317.  
  1318. A.4.2.  fhstatus
  1319.  
  1320.        union fhstatus switch (unsigned status) {
  1321.        case 0:
  1322.            fhandle directory;
  1323.        default:
  1324.            void;
  1325.        }
  1326.  
  1327.    The type "fhstatus" is a union.  If a "status" of zero is returned,
  1328.    the call completed successfully, and a file handle for the
  1329.    "directory" follows.  A non-zero status indicates some sort of error.
  1330.    In this case, the status is a UNIX error number.
  1331.  
  1332. A.4.3.  dirpath
  1333.  
  1334.        typedef string dirpath<MNTPATHLEN>;
  1335.  
  1336.    The type "dirpath" is a server pathname of a directory.
  1337.  
  1338. A.4.4.  name
  1339.  
  1340.        typedef string name<MNTNAMLEN>;
  1341.  
  1342.    The type "name" is an arbitrary string used for various names.
  1343.  
  1344.  
  1345.  
  1346. Sun Microsystems, Inc.                                         [Page 24]
  1347.  
  1348. RFC 1094                NFS: Network File System              March 1989
  1349.  
  1350.  
  1351. A.5.  Server Procedures
  1352.  
  1353.    The following sections define the RPC procedures supplied by a mount
  1354.    server.
  1355.  
  1356.            /*
  1357.             * Protocol description for the mount program
  1358.             */
  1359.            program MOUNTPROG {
  1360.                    /*
  1361.                     * Version 1 of the mount protocol used with
  1362.                     * version 2 of the NFS protocol.
  1363.                     */
  1364.                    version MOUNTVERS {
  1365.  
  1366.                            void
  1367.                            MOUNTPROC_NULL(void) = 0;
  1368.  
  1369.                            fhstatus
  1370.                            MOUNTPROC_MNT(dirpath) = 1;
  1371.  
  1372.                            mountlist
  1373.                            MOUNTPROC_DUMP(void) = 2;
  1374.  
  1375.                            void
  1376.                            MOUNTPROC_UMNT(dirpath) = 3;
  1377.  
  1378.                            void
  1379.                            MOUNTPROC_UMNTALL(void) = 4;
  1380.  
  1381.                            exportlist
  1382.                            MOUNTPROC_EXPORT(void)  = 5;
  1383.                    } = 1;
  1384.            } = 100005;
  1385.  
  1386. A.5.1.  Do Nothing
  1387.  
  1388.            void
  1389.            MNTPROC_NULL(void) = 0;
  1390.  
  1391.    This procedure does no work.  It is made available in all RPC
  1392.    services to allow server response testing and timing.
  1393.  
  1394. A.5.2.  Add Mount Entry
  1395.  
  1396.            fhstatus
  1397.            MNTPROC_MNT(dirpath) = 1;
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Sun Microsystems, Inc.                                         [Page 25]
  1403.  
  1404. RFC 1094                NFS: Network File System              March 1989
  1405.  
  1406.  
  1407.    If the reply "status" is 0, then the reply "directory" contains the
  1408.    file handle for the directory "dirname".  This file handle may be
  1409.    used in the NFS protocol.  This procedure also adds a new entry to
  1410.    the mount list for this client mounting "dirname".
  1411.  
  1412. A.5.3.  Return Mount Entries
  1413.  
  1414.            struct *mountlist {
  1415.                    name      hostname;
  1416.                    dirpath   directory;
  1417.                    mountlist nextentry;
  1418.            };
  1419.  
  1420.            mountlist
  1421.            MNTPROC_DUMP(void) = 2;
  1422.  
  1423.    Returns the list of remote mounted filesystems.  The "mountlist"
  1424.    contains one entry for each "hostname" and "directory" pair.
  1425.  
  1426. A.5.4.  Remove Mount Entry
  1427.  
  1428.            void
  1429.            MNTPROC_UMNT(dirpath) = 3;
  1430.  
  1431.    Removes the mount list entry for the input "dirpath".
  1432.  
  1433. A.5.5.  Remove All Mount Entries
  1434.  
  1435.            void
  1436.            MNTPROC_UMNTALL(void) = 4;
  1437.  
  1438.    Removes all of the mount list entries for this client.
  1439.  
  1440. A.5.6.  Return Export List
  1441.  
  1442.            struct *groups {
  1443.                    name grname;
  1444.                    groups grnext;
  1445.            };
  1446.  
  1447.            struct *exportlist {
  1448.                    dirpath filesys;
  1449.                    groups groups;
  1450.                    exportlist next;
  1451.            };
  1452.  
  1453.            exportlist
  1454.            MNTPROC_EXPORT(void) = 5;
  1455.  
  1456.  
  1457.  
  1458. Sun Microsystems, Inc.                                         [Page 26]
  1459.  
  1460. RFC 1094                NFS: Network File System              March 1989
  1461.  
  1462.  
  1463.    Returns a variable number of export list entries.  Each entry
  1464.    contains a filesystem name and a list of groups that are allowed to
  1465.    import it.  The filesystem name is in "filesys", and the group name
  1466.    is in the list "groups".
  1467.  
  1468.    Notes:  The exportlist should contain more information about the
  1469.    status of the filesystem, such as a read-only flag.
  1470.  
  1471. Author's Address:
  1472.  
  1473.    Bill Nowicki
  1474.    Sun Microsystems, Inc.
  1475.    Mail Stop 1-40
  1476.    2550 Garcia Avenue
  1477.    Mountain View, CA 94043
  1478.  
  1479.    Phone: (415) 336-7278
  1480.  
  1481.    Email: nowicki@SUN.COM
  1482.  
  1483.  
  1484.  
  1485.  
  1486.  
  1487.  
  1488.  
  1489.  
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Sun Microsystems, Inc.                                         [Page 27]
  1515.