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)