nfs(4)							     Kernel Interfaces Manual							    nfs(4)

NAME

       nfs, nfs_intro - Network File System (NFS) information

DESCRIPTION

       NFS is a facility for sharing files in a heterogeneous environment of processors, operating systems, and networks.  Sharing is accomplished
       by mounting a remote file system or directory on a local system and then reading or writing the files as though they were local.

       Sharing file systems has the following advantages: Removes the need to copy files across the network from one system  to  another  Provides
       easier access to remote files Reduces the risk of having out-of-date copies of the same file on different systems

   The NFS Environment
       NFS is based on the client-server model, in which client systems request resources from other systems called servers.  A server is any host
       system or process that provides a network service. A client is any host system or process that uses services from a server.

       A single host, or server, can provide more than one service.  Servers are passive; they do not call clients, they wait for clients to  call
       them.

       A one-to-one  correspondence between servers, clients, and systems does not always exist.  A system that acts as a server can also act as a
       client.	A server that exports file systems and directories can also mount remote file systems and directories exported by  other  systems,
       thus becoming a client.	To export a file system or directory is to make it available for NFS clients to mount remotely on their local sys-
       tems.

       The /etc/exports file defines the NFS file systems and directories that can be exported.  The following table summarizes  the  distinctions
       between client and server systems for NFS mounts.

       --------------------------------------------------------------
       Client			       Server
       --------------------------------------------------------------
       Requests a remote mount	       Responds to the mount request
       Reads the /etc/fstab file       Reads the /etc/exports file
       Checks if the server is known   Checks if the client is known
       --------------------------------------------------------------

       The client always initiates the remote mount.  The server completes the bindings, subject to access-control rules specific to NFS.  Because
       most network administration problems occur at bind time, you should know how a client binds to a server and what access control policy each
       server uses.  For more information on access control, see the NFS Service section and the Network Administration manual.

       You  mount  a  remote file system by using either the mount command or an automatic mounting daemon, such as Automount or AutoFS.  In addi-
       tion, you can use the WebNFS protocol, which bypasses mount and gives direct access to the WebNFS served file system.

       An NFS client selects a specific server from which to mount a file system or directory.	A client can mount file  systems  and  directories
       from several different servers.

   Network Transport Protocols
       NFS  can  use  either  the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) protocol.  The TCP protocol is best for con-
       gested wide area networks because of its superior retransmit features and congestion control.  The UDP protocol is best in  networks  where
       congestion  and lost messages are not a problem because its lower overhead might yield higher throughput.  The client selects the transport
       protocol in the mount command.

   The NFS Service
       Once a remote file system or directory is mounted, it can be used as a local file system by client programs.  Typically,  a  client  mounts
       one  or more remote file systems and directories at start up time, if lines similar to the following are in the /etc/fstab file.  The mount
       program reads these lines when the system starts up: titan:/usr2 /usr2 nfs rw,bg 0 0 venus:/usr/man /usr/man nfs rw,bg 0 0 The  first  line
       in  the	example  shows	that the /usr2 directory at system titan is mounted at local mount point /usr2 when you boot the local system. The
       rest of this line describes the mount.  See fstab(4) for a description of the file format.

       NFS servers control access to their resources by limiting named file systems and directories to a specific set of clients with an entry	in
       the  /etc/exports file.	The /etc/exports file allows you to limit access to NFS clients but not to individual remote users.  By default in
       Tru64 UNIX, mounts can be limited to client superusers only.

       The following four programs implement the NFS service: portmap mountd nfsiod nfsd

       A client's mount request is transmitted to the remote server's mountd daemon after obtaining its address from portmap.  A port mapper is  a
       Remote Procedure Call (RPC) daemon that maps RPC program numbers of network services to their UDP or TCP protocol port numbers.

       The  mountd  daemon  checks  the access permission of the client and returns a pointer to the file system or directory.	After the mount is
       completed, access to files and directories at and below that mount point go through the pointer to the server's	NFS  daemon  (nfsd)  using
       remote  procedure  calls.   Some  file  access  requests  (write-behind and read-ahead) are handled by the block I/O daemon (nfsiod) on the
       client.

   PC-NFS
       The PC-NFS facility provides the benefits of NFS to personal computers on  your	network.   PC-NFS  enables  personal  computers  to  share
       resources  and  exchange files, and like NFS, is based on the client-server model.  The client software runs on the personal computer;  the
       server software resides in the /usr/sbin directory.

       For information on the PC-NFS client, see your PC-NFS client documentation.

       For instructions on making the PC-NFS server available to clients, refer to Network Administration.

   The NFS Locking Service
       The NFS Locking Service (rpc.lockd) allows you to create advisory locks on files and file regions on local and remotely mounted	file  sys-
       tems.  Advisory locks are not enforced.

       To  make  use  of  the NFS Locking Service, a programmer needs to understand how to use the fcntl system call or the lockf subroutine.  See
       fcntl(2) and lockf(3) for programming information.

       File locking is a way to manage access to shared files.	A process takes the following steps when locking a  file  or  region  of  a  file:
       Determines if the file or region within the file is locked Applies a lock if the file or region is not locked Makes the changes to the file
       or region Unlocks the file or region

       The NFS Locking Service coordinates the dispersal of locks to remote file systems.  It communicates with  the  kernel  and  status  monitor
       (rpc.statd) of the local system, as well as with the other lock daemons on the network.

       The NFS Locking Service uses a stateless approach to failure recovery.  The fundamental element of this approach is that the status monitor
       detects both client and server recoveries.  This approach is passive.  When the client status monitor detects  that  a  failed  server  has
       reinitialized  (recovered),  it	notifies the local locking daemon of the failure.  The lock daemon then activates the appropriate recovery
       mechanism.

       If the NFS server fails and the NFS Locking Service is enabled, all the locks managed by the server's local processes are  lost.   However,
       when  the server recovers, the lock manager daemons on the client systems send reclaim requests for the NFS locks.  The server lock manager
       reestablishes the previously acquired locks associated with the reclaim requests, provided the  requests  are  received	within	the  grace
       period built into the NFS Locking Service.

       During  the  grace  period,  the  server lock manager honors only reclaim requests.  Once the grace period expires, reclaim requests are no
       longer valid, and the server lock manager accepts only new requests.  At this time, the server lock manager cannot reestablish  old  locks.
       A  user	process  whose	lock  could  not be reclaimed is sent a SIGLOST signal.  The client lock manager can create new locks by using the
       interface primitives in the fcntl system call or the lockf subroutine.

       If a client fails while it is using the NFS Locking Service, then when the client recovers, the status monitor daemon notifies  the  appro-
       priate  servers.   The  server  lock  manager then releases the locks.  The client applications can then issue new lock requests as part of
       their recovery procedure.

   Automatic Mounting Daemons
       NFS clients can optionally run an automatic mounting daemon, such as Automount or AutoFS.  These daemons are client interfaces that perform
       remote  mounts automatically, and only when they are needed.  If you need to access a remotely mounted file or directory, the selected dae-
       mon mounts it, keeping it mounted as long as you need it.

       The automount and autofsd daemons are told which remote file systems to mount from a database file called a map.  A map	lists  the  remote
       file systems that the selected daemon monitors, their locations, and any mount options. The maps can be shared through NIS.

       There are three types of maps: Master - Although not required, the master map helps to organize mounts.	If a master map exists, it is read
       first when the automount or autofsmount commands are invoked, acting as a pointer to other maps.

	      Both commands look for an NIS map called auto.master when invoked.  They can also be instructed to use a local master map.  Direct -
	      Specifies  a  key  that is the pathname of the mount point, and a location, which is the location of the file system or directory in
	      which it resides, specified in this format: server:pathname.  For direct maps, a local mount point is specified as an absolute path-
	      name,  such as /doclib.  Indirect - Like a direct map, specifies the pathname of the mount point and the location of the file system
	      on which it resides. For indirect maps, a local mount point is specified as a simple pathname, such as docsrc because the whole  map
	      is associated with a directory.

       For more information these daemons, see automount(8), autofsd(8), and autofsmount(8).  Or, refer to the Network Administration manual.

RELATED INFORMATION

       Commands: autofsmount(8), automount(8), nfsstat(8)

       Daemons: autofsd(8), automount(8), mountd(8), nfsd(8), nfsiod(8), rpc.lockd(8), rpc.statd(8)

       Files: advfs(4), cdfs(4), fstab(4)

       Technical Overview, Network Administration delim off

																	    nfs(4)