Provided by Colasoft Co., Ltd.

NFS ( Network File System )

Home > Protocols > NFS Update: 2005-11-07 17:17:55    I have words to say about this protocol
On this page
SUMMARY
Protocol : Network File System
Protocol suite : TCP/IP
Layer : Application Layer
Type : File transfer protocol
Latest Version : NFSv4
Ports : 2049
Working groups : NFSv4, Network File System Version 4
DESCRIPTION
The NFS protocol is designed to be machine, operating system, network architecture, and transport protocol independent. This independence is achieved through the use of Remote Procedure Call (RPC) primitives built on top of an eXternal Data Representation (XDR).

The Network File System (NFS), developed by Sun Microsystems in the 1980's as a way to create a file system on diskless clients. NFS provides remote access to shared file systems across networks. This means that a file system may actually be sitting on machine A, but machine B can mount that filesystem and it will look to the users on machine B like the file system resides on the local machine. In this way NFS is transparent to the user. NFS was also designed to be machine, operating system, network architecture, and transport protocol independent.

NFS is a stateless protocol. This means that the file server stores no per-client information, and there are no NFS "connections". For example, NFS has no operation to open a file, since this would require the server to store state information (that a file is open; what its file descriptor is; the next byte to read; etc). Instead, NFS supports a Lookup procedure, which converts a filename into a file handle. This file handle is a unique, immutable identifier, usually an i-node number, or disk block address. NFS does have a Read procedure, but the client must specify a file handle and starting offset for every call to Read. Two identical calls to Read will yield the exact same results. If the client wants to read further in the file, it must call Read with a larger offset.

The primary functions of NFS are to export or mount directories to other machines, either on or off a local network. These diretories can then be accessed as though they were local. NFS uses a client/server architecture and consists of a client program, a server program, and a protocol used to communicate between the two.

The server program makes filesystems available for access by other machines via a process called exporting. File systems that are available for access across the network are often referred to as shared file systems.

NFS clients access shared file systems mounting them from an NFS server machine. When a file system is mounted, it is integrated into the directory tree. An advanced form of this service is the automounter, which autmomatically mounts and unmounts file systems.

When someone accesses a file over NFS, the kernel places an RPC call to nfsd (the NFS daemon) on the server machine. This call takes the file handle, the name of the file to be accessed, and the user's user and group id as parameters. These are used in determining access rights to the specified file. In order to prevent unauthorized users from reading or modifying files, user and group ids must be the same on both hosts.


On most implementations, the NFS functionality of both client and server are implemented as kernel-level daemons that are started from user space at system boot. These are the NFS daemon (nfsd) on the server host, and the Block I/O Daemon (biod) running on the client host. To improve throughput, biod performs asynchronous I/O using read-ahead and write-behind; also, several nfsd daemons are usually run concurrently.

The NFS implementation of is a little different in that the client code is tightly integrated in the virtual file system (VFS) layer of the kernel and doesn't require additional control through biod. On the other hand, the server code runs entirely in user space, so that running several copies of the server at the same time is almost impossible because of the synchronization issues this would involve. There are currently three versions of NFS. NFS2, NFS3 and NFSv4.

The most important design principles:
  • Transparent Access

  • Users and applications can access remote files as if they were local. They are not required to know whether the files reside on the local disk or on remote servers.

  • Statelessness

  • NFS operates in a stateless manner using remote procedure calls (RPC) built on top of an external data representation (XDR) protocol. The RPC protocol enables version and authentication parameters to be exchanged for security over the network.
    When an NFS client mounts file system the server examines the mount request to be sure that the client is authorized, then issues a magic cookie to the client for use in later accesses. The magic cookie keeps the server stateless since no record of authenticated clients needs to be kept. Unmounting and remounting an NFS filesystem changes its magic cookie. Magic cookie persist across reboots provided that you do not boot single user or play with the file systems.
    Once the client has the magic cookie it uses RPC to make file requests. Because the server is stateless, it is the responsibility of the client to ensure that it has recieved acknowledgements of write requests before deleting its copy of data.

  • Portability

  • NFS is machine and operating system independent. This allows it to be ported easily to multiple OS and hardware platforms from PCs to mainframes.

  • Fast Recovery From Failure

  • NFS is designed to recover quickly from system failures and network problems, causing minimal disruption of service to users.

  • Network Protocol Independence

  • NFS has the flexibility to run on multiple transport protocols instead of being restricted to just one. This allows it to utilize existing protocols today as well as new protocols in the future.

  • Performance

  • NFS is designed for high performance so that users can access remote files as quickly as they can access local files.

  • Security

  • The NFS architecture enables the utilization of multiple security mechanisms. This allows system administrators to choose the security mechanism that is appropriate for their distributed file sharing environment instead of being restricted to one solution. This also allows NFS to utilize new security mechanisms in the future.



NFS version 4
A distributed filesystem protocol which owes heritage to NFS protocol versions 2 and 3. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added.

The goals of the NFS version 4 revision are as follows:
  • Improve access and good performance on the Internet.

  • Strong security with negotiation built into the protocol.

  • Good cross-platform interoperability.

  • Designed for protocol extensions.

The general file system model used for the NFS version4 protocol is the same as previous versions. The server file system is hierarchical with the regular files contained within being treated as opaque byte streams. In a slight departure, file and directory names are encoded with UTF-8 to deal with the basics of internationalization.

A separate protocol to provide for the initial mapping between path name and filehandle is no longer required. Instead of using the older MOUNT protocol for this mapping, the server provides a ROOT filehandle that represents the logical root or top of the file system tree provided by the server.

  • NFSv4 protocol header

  • 87654321Octets
    Tag Length1-4
    Tag (depends on Tag length)5-N
    Minor VersionN+1-N+4
    Operation ArgumentN+5-N+8

    • Tag Length

    • The length in bytes of the tag.

    • Tag

    • Defined by the implementor.

    • Minor Version

    • Each minor version number will correspond to an RFC . Minor version zero corresponds to NFSv4.

    • Operation Argument

    • Operation to be executed by the protocol.

    • Operation Argument Values

    • The operation arg value can be one of the following:

      Value

      Name

      3

      ACCESS

      4

      CLOSE

      5

      COMMIT

      6

      CREATE

      7

      DELEGPURGE

      8

      DELEGRETURN

      9

      GETATTR

      10

      GETFH

      11

      LINK

      12

      LOCK

      13

      LOCKT

      14

      LOCKU

      15

      LOOKUP

      16

      LOOKUPP

      17

      NVERIFY

      18

      OPEN

      19

      OPENATTR

      20

      OPEN_CONFIRM

      21

      OPEN_DOWNGRADE

      22

      PUTFH

      23

      PUTPUBFH

      24

      PUTROOTFH

      25

      READ

      26

      READDIR

      27

      READLINK

      28

      REMOVE

      29

      RENAME

      30

      RENEW

      31

      RESTOREFH

      32

      SAVEFH

      33

      SECINFO

      34

      SETATTR

      35

      SETCLIENTID

      36

      SETCLIENTID_CONFIRM

      37

      VERIFY

      38

      WRITE

    Top of Page

    EXAMPLES
    Example 1
    

    The syntax of the NFS URL is a subset of the Generic URL syntax described in RFC 1738.
    An NFS URL does not include user or password components, nor does it recognize "?"
    query or "#" fragment components.

    nfsURL = "nfs" ":" relativeURL
    relativeURL = net_path | abs_path | rel_path
    net_path = "//" hostport [ abs_path ]
    abs_path = "/" rel_path
    rel_path = [ path_segments ]
    hostport = host [ ":" port ]
    host = hostname | hostnumber
    hostname = *( domainlabel "." ) toplabel
    domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
    toplabel = alpha | alpha *( alphanum | "-" ) alphanum
    hostnumber = 1*digit "." 1*digit "." 1*digit "." 1*digit
    port = *digit
    url-path = [ "/" ] path_segments
    path_segments = segment *( "/" segment )
    segment = *pchar
    pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
    reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
    unreserved = alpha | digit | mark
    mark = "$" | "-" | "_" | "." | "!" | "~" |
    "*" | "'" | "(" | ")" | ","
    escaped = "%" hex hex
    hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
    "a" | "b" | "c" | "d" | "e" | "f"
    alphanum = alpha | digit
    alpha = lowalpha | upalpha
    lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
    "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
    "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
    upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
    "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
    "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
    digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
    "8" | "9"
    Example 2
    

    If the server aited to flush data from remote requests, the client would have to save
    those requests so that it could resend them in case of a server crash.

    /*
    * Remote file service routines
    */
    program NFS_PROGRAM {
    version NFS_VERSION {
    void
    NFSPROC_NULL(void) = 0;

    attrstat
    NFSPROC_GETATTR(fhandle) = 1;

    attrstat
    NFSPROC_SETATTR(sattrargs) = 2;

    void
    NFSPROC_ROOT(void) = 3;

    diropres
    NFSPROC_LOOKUP(diropargs) = 4;

    readlinkres
    NFSPROC_READLINK(fhandle) = 5;

    readres
    NFSPROC_READ(readargs) = 6;

    void
    NFSPROC_WRITECACHE(void) = 7;
    attrstat
    NFSPROC_WRITE(writeargs) = 8;

    diropres
    NFSPROC_CREATE(createargs) = 9;

    stat
    NFSPROC_REMOVE(diropargs) = 10;

    stat
    NFSPROC_RENAME(renameargs) = 11;

    stat
    NFSPROC_LINK(linkargs) = 12;

    stat
    NFSPROC_SYMLINK(symlinkargs) = 13;

    diropres
    NFSPROC_MKDIR(createargs) = 14;

    stat
    NFSPROC_RMDIR(diropargs) = 15;

    readdirres
    NFSPROC_READDIR(readdirargs) = 16;

    statfsres
    NFSPROC_STATFS(fhandle) = 17;
    } = 2;
    } = 100003;
    Example 3
    

    These are the sizes, given in decimal bytes, of various XDR structures used in the
    protocol

    /*
    * The maximum number of bytes of data in a READ or WRITE
    * request.
    */
    const MAXDATA = 8192;

    /* The maximum number of bytes in a pathname argument. */
    const MAXPATHLEN = 1024;

    /* The maximum number of bytes in a file name argument. */
    const MAXNAMLEN = 255;

    /* The size in bytes of the opaque "cookie" passed by READDIR. */
    const COOKIESIZE = 4;

    /* The size in bytes of the opaque file handle. */
    const FHSIZE = 32;

    Top of Page


    PROTOCOL RELATIONS
    Parent layer
    Child layer
    TCP/UDP
    NFS
    Top of Page

    GLOSSARY
    GSS-API
    The GSS-API (Generic Security Service Application Program Interface) is a generic API for doing client-server authentication.

    A typical GSS-API caller is itself a communications protocol, calling on GSS-API in order to protect its communications with authentication, integrity, and/or confidentiality security services. A GSS-API caller accepts tokens provided to it by its local GSS-API implementation and transfers the tokens to a peer on a remote system; that peer passes the received tokens to its local GSS-API implementation for processing. The security services available through GSS-API in this fashion are implementable (and have been implemented) over a range of underlying mechanisms based on secret-key and public-key cryptographic technologies.

    The GSS-API separates the operations of initializing a security context between peers, achieving peer entity authentication (GSS_Init_sec_context() and GSS_Accept_sec_context() calls), from the operations of providing per-message data origin authentication and data integrity protection (GSS_GetMIC() and GSS_VerifyMIC() calls) for messages subsequently transferred in conjunction with that context.

    Gopher
    A system that pre-dates the World Wide Web for organizing and displaying files on Internet servers. A Gopher server presents its contents as a hierarchically structured list of files. With the ascendance of the Web, many gopher databases were converted to Web sites which can be more easily accessed via Web search engines.

    Gopher was developed at the University of Minnesota and named after the school's mascot. Two systems, Veronica and Jughead, let you search global indices of resources stored in Gopher systems.

    IETF
    IETF (Internet Engineering Task Force) is the main standards organization for the Internet. The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual.

    WAIS
    WAIS (Wide Area Information Server) is an Internet system in which specialized subject databases are created at multiple server locations, kept track of by a directory of servers at one location, and made accessible for searching by users with WAIS client programs. The user of WAIS is provided with or obtains a list of distributed databases. The user enters a search argument for a selected database and the client then accesses all the servers on which the database is distributed. The results provide a description of each text that meets the search requirements. The user can then retrieve the full text.

    Top of Page

    REFERENCES
    RFCs:
    [RFC 2224] NFS URL Scheme.
                    Defines NFS URL nfs:.
    [RFC 2339] An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols.
    [RFC 2623] NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5.
    [RFC 2624] NFS Version 4 Design Considerations.
    [RFC 3530] Network File System (NFS) version 4 Protocol.
                    Defines NFS version 4.
                    Obsoletes: RFC 3010.
    Obsolete RFCs:
    [RFC 1094] NFS: Network File System Protocol Specification.
                    Obsoleted by: RFC 3010.
                    Defines NFS version 2.
    [RFC 1813] NFS Version 3 Protocol Specification.
                    Obsoleted by: RFC 3010.
                    Defines NFS version 3.
    [RFC 3010] NFS version 4 Protocol.
                    Obsoleted by: RFC 3530.
                    Defines NFS version 4.
                    Obsoletes: RFC 1094, RFC 1813.
    Publications
    [ISBN 1565925106] Managing NFS and NIS, 2nd Edition.
    [ISBN 0201325705] NFS Illustrated
                    


    Top of Page

    OTHER PROTOCOLS OF TCP/IP SUITE
    AARP   RRP   RTP Video   RTP Audio   RTP   COPS   Gopher   HSRP   ICP   MPLS   IEEE 802.2   CIP   FTP - Data   FTP - Ctrl   IMAPS   IP Fragment   LDAPS   PUP   MSSQL   RSH   SQL   POP3s   RTELNET   RSVP   STP   VLAN   MSN   H.323   MSRDP   HTTPS   WINS   LPD   GTP   ICMPv6   POP   TELNET   H.225   VRRP   PIM   RARP   SAP   OSPF   RLOGIN   SCTP   SIP   RTCP   PPPoE   Mobile IP   IMAP3   WhoIs   SLP   NCP   PPTP   MGCP   LDAP   L2TP   Kerberos   IPv6   GRE   Ethernet SNAP   AFP   CIFS   IEEE 802.3   Finger   NBDGM   NetBEUI   NBSSN   ESP   EIGRP   EGP   DHCP   CGMP   CDP   BOOTP   AH   NBNS   EthernetII   ICQ   PPP   ARP   RIP   IPX   IGRP   IGMP   SSH   RPC   NetBIOS   TFTP   SNMP   SNA   SMB   RADIUS   NTP   NNTP   UDP   TCP   BGP   DNS   SOCKS   IMAP   RTSP   NFS   ICMP   IP   FTP   Telnet   POP3   SMTP   HTTP  
    Search RFCs:

    Advanced Search
    Search Glossary:
    Exact search
    Fuzzy search


    All Protocols
    Submit a Request

    Recommend an Article

     Layer 7 Application Layer
      AFP
      BOOTP
      CIFS
      CIP
      COPS
      DHCP
      DNS
      Finger
      FTP
      FTP - Ctrl
      FTP - Data
      Gopher
      HSRP
      HTTP
      HTTPS
      ICP
      ICQ
      IMAP
      IMAP3
      IMAPS
      Kerberos
      LPD
      MGCP
      MSN
      MSRDP
      MSSQL
      NCP
      NFS
      NNTP
      NTP
      POP
      POP3
      POP3s
      RADIUS
      RLOGIN
      RRP
      RSH
      RTCP
      RTELNET
      RTP
      RTP Audio
      RTP Video
      RTSP
      SAP
      SIP
      SLP
      SMB
      SMTP
      SNA
      SNMP
      SOCKS
      SSH
      Telnet
      TELNET
      TFTP
      WhoIs
      WINS
     Layer 6 Presentation Layer
      NBNS
      NBSSN
      NCP
      NetBIOS
     Layer 5 Session Layer
      LDAP
      LDAPS
      NCP
      NetBEUI
      RPC
     Layer 4 Transport Layer
      H.225
      H.323
      NBDGM
      NetBEUI
      PUP
      SCTP
      TCP
      UDP
     Layer 3 Network Layer
      AARP
      AH
      BGP
      EGP
      EIGRP
      ESP
      GRE
      GTP
      ICMP
      ICMPv6
      IGMP
      IGRP
      IP
      IP Fragment
      IPv6
      IPX
      Mobile IP
      MPLS
      OSPF
      PIM
      PPPoE
      RIP
      RSVP
      STP
      VRRP
     Layer 2 Data Link Layer
      ARP
      CDP
      CGMP
      Ethernet SNAP
      EthernetII
      IEEE 802.2
      IEEE 802.3
      L2TP
      PPP
      PPTP
      RARP
      SQL
      VLAN
     Layer 1 Physical Layer
    © 2006 - 2007 Colasoft Co., Ltd. All rights reserved.