nfs_intro man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

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
       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 eas‐
       ier 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  Ser‐
       vice 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 sys‐
       tem 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	 over‐
       head  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 documenta‐
       tion.

       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	under‐
       stand  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	reini‐
       tialized (recovered), it notifies the local locking daemon of the fail‐
       ure.  The lock daemon then activates the	 appropriate  recovery	mecha‐
       nism.

       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 sig‐
       nal.  The client lock manager can create new locks by using the	inter‐
       face 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
       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 mas‐
       ter  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 speci‐
	      fied  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 direc‐
	      tory.

       For more information these daemons, see automount(8),  autofsd(8),  and
       autofsmount(8).	Or, refer to the Network Administration: Services man‐
       ual.

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 delim off

									nfs(4)
[top]

List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net