unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Page:
Section:
Apropos / Subsearch:
optional field



nfs(4)								       nfs(4)



NAME

  nfs, nfs_intro - Network File	System (NFS) information

DESCRIPTION

  NFS is a facility for	sharing	files in a heterogeneous environment of	pro-
  cessors, operating systems, and networks.  Sharing is	accomplished by
  mounting a remote file system	or directory on	a local	system and then	read-
  ing 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 dif-
       ferent 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 systems.

  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: Services manual.

  You mount a remote file system by using either the mount command or an
  automatic mounting daemon, such as Automount or AutoFS.  In addition,	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 congested wide	area
  networks because of its superior retransmit features and congestion con-
  trol.	 The UDP protocol is best in networks where congestion and lost	mes-
  sages	are not	a problem because its lower overhead might yield higher
  throughput.  The client selects the transport	protocol in the	mount com-
  mand.

  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 sys-
  tems 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	dae-
  mon after obtaining its address from portmap.	 A port	mapper is a Remote
  Procedure Call (RPC) daemon that maps	RPC program numbers of network ser-
  vices	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: Services.

  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 systems.
  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:

   1.  Determines if the file or region	within the file	is locked

   2.  Applies a lock if the file or region is not locked

   3.  Makes the changes to the	file or	region

   4.  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, pro-
  vided	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 appropriate
  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 Auto-
  mount	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 daemon mounts it, keep-
  ing 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	sys-
  tems 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 pathname,
       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: Services 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: Services