System Administration Guide: Resource Management and Network Services

Chapter 14 Managing Network File Systems (Overview)

This chapter provides an overview of the NFS service, which
can be used to access file systems over the network. The chapter includes
a discussion of the concepts necessary to understand the NFS service and a
description of the latest features in NFS and autofs.

NFS Terminology

This section presents some of the basic terminology that must be understood
to work with the NFS service. Expanded coverage of the NFS service is included
in Chapter 16, Accessing Remote File Systems (Reference).

NFS Servers and Clients

The terms client and server
are used to describe the roles that a computer assumes when sharing file systems.
Computers that share their file systems over a network are acting as servers.
The computers that are accessing the file systems are said to be clients.
The NFS service enables any computer to access any other computer’s file systems.
At the same time, the NFS service provides access to its own file systems.
A computer can assume the role of client, server, or both client and server
at any particular time on a network.

Clients access files on the server by mounting the server’s shared file
systems. When a client mounts a remote file system, the client does not make
a copy of the file system. Rather, the mounting process uses a series of remote
procedure calls that enable the client to access the file system transparently
on the server’s disk. The mount resembles a local mount. Users type commands
as if the file systems were local. See Mounting File Systems for information
about tasks that mount file systems.

After a file system has been shared on a server through an NFS operation,
the file system can be accessed from a client. You can mount an NFS file system
automatically with autofs. See Automatic File-System Sharing and Task Overview for Autofs Administration
for tasks that involve the share command and autofs.

NFS File Systems

The objects that can be shared with the NFS service include any whole
or partial directory tree or a file hierarchy—including a single file.
A computer cannot share a file hierarchy that overlaps a file hierarchy that
is already shared. Peripheral devices such as modems and printers cannot be
shared.

In most UNIX system environments, a file hierarchy that can be shared
corresponds to a file system or to a portion of a file system. However, NFS
support works across operating systems, and the concept of a file system might
be meaningless in other, non-UNIX environments. Therefore, the term file system refers to a file or file hierarchy
that can be shared and be mounted with NFS.

About the NFS Service

The NFS service enables computers of different architectures that run
different operating systems to share file systems across a network. NFS support
has been implemented on many platforms that range from the MS-DOS to the VMS
operating systems.

The NFS environment can be implemented on different operating systems
because NFS defines an abstract model of a file system, rather than an architectural
specification. Each operating system applies the NFS model to its file system
semantics. This model means that file system operations such as reading and
writing function as though the operations are accessing a local file.

The NFS service has the following benefits:

Enables multiple computers to use the same files, so everyone
on the network can access the same data
Reduces storage costs by having computers share applications
instead of needing local disk space for each user application
Provides data consistency and reliability because all users
can read the same set of files
Makes mounting of file systems transparent to users
Makes accessing of remote files transparent to users
Supports heterogeneous environments
Reduces system administration overhead

The NFS service makes the physical location of the file system irrelevant
to the user. You can use the NFS implementation to enable users to see all
the relevant files regardless of location. Instead of placing copies of commonly
used files on every system, the NFS service enables you to place one copy
on one computer’s disk. All other systems access the files across the network.
Under NFS operation, remote file systems are almost indistinguishable from
local file systems.

About Autofs

File systems that are shared through the NFS service can be mounted
by using automatic mounting. Autofs, a client-side service, is a file system
structure that provides automatic mounting. The autofs file system is initialized
by automount, which is run automatically when a system
is booted. The automount daemon, automountd, runs continuously,
mounting and unmounting remote directories as necessary.

Whenever a client computer that is running automountd
tries to access a remote file or remote directory, the daemon mounts the remote
file system. This remote file system remains mounted for as long as needed.
If the remote file system is not accessed for a certain period of time, the
file system is automatically unmounted.

Mounting need not be done at boot time, and the user no longer has to
know the superuser password to mount a directory. Users do not need to use
the mount and umount commands. The autofs
service mounts and unmounts file systems as required without any intervention
by the user.

Mounting some file hierarchies with automountd does
not exclude the possibility of mounting other hierarchies with mount. A diskless computer must mount / (root), /usr, and /usr/kvm
through the mount command and the /etc/vfstab file.

Task Overview for Autofs Administration and How Autofs Works give
more specific information about the autofs service.

Features of the NFS Service

This section describes the important features that are included in the
NFS service.

NFS Version 2 Protocol

Version 2 was the first version of the NFS protocol in wide use. Version
2 continues to be available on a large variety of platforms. All Solaris releases
support version 2 of the NFS protocol, but Solaris releases prior to Solaris
2.5 support version 2 only.

NFS Version 3 Protocol

An implementation of NFS version 3 protocol was a new feature of the
Solaris 2.5 release. Several changes have been made to improve interoperability
and performance. For optimal use, the version 3 protocol must be running on
both the NFS servers and clients.

This version enables safe asynchronous writes on the server, which improve
performance by allowing the server to cache client write requests in memory.
The client does not need to wait for the server to commit the changes to disk,
so the response time is faster. Also, the server can batch the requests, which
improves the response time on the server.

All Solaris NFS version 3 operations return the file attributes, which
are stored in the local cache. Because the cache is updated more often, the
need to do a separate operation to update this data arises less often. Therefore,
the number of RPC calls to the server is reduced, improving performance.

The process for verifying file access permissions has been improved.
Version 2 generated a “write error” message or a “read
error” message if users tried to copy a remote file without the appropriate
permissions. In version 3, the permissions are checked before the file is
opened, so the error is reported as an “open error.”

The NFS version 3 protocol removes the 8-Kbyte transfer size limit.
Clients and servers negotiate whatever transfer size the clients and servers
support, rather than conform to the 8-Kbyte limit imposed in version 2. The
Solaris 2.5 implementation defaults to a 32-Kbyte transfer size.

NFS ACL Support

Access control list (ACL) support was added in the Solaris 2.5 release.
ACLs provide a finer-grained mechanism to set file access permissions than
is available through standard UNIX file permissions. NFS ACL support provides
a method of changing and viewing ACL entries from a Solaris NFS client to
a Solaris NFS server. See “Using Access Control Lists (ACLs)” in System Administration Guide: Security Services for more
information about ACLs.

NFS Over TCP

The default transport protocol for the NFS protocol was changed to the
Transport Control Protocol (TCP) in the Solaris 2.5 release. TCP helps performance
on slow networks and wide area networks. TCP also provides congestion control
and error recovery. NFS over TCP works with version 2 and version 3. Prior
to 2.5, the default NFS protocol was User Datagram Protocol (UDP).

Network Lock Manager and NFS

The Solaris 2.5 release also included an improved version of the network
lock manager. The network lock manager provided UNIX record locking and PC
file sharing for NFS files. The locking mechanism is now more reliable for
NFS files, so commands that use locking are less likely to hang.

NFS Large File Support

The Solaris 2.6 implementation of the NFS version 3 protocol was changed
to correctly manipulate files that were larger than 2 Gbytes. The NFS version
2 protocol and the Solaris 2.5 implementation of the version 3 protocol could
not handle files that were larger than 2 Gbytes.

NFS Client Failover

Dynamic failover of read-only file systems was added in the Solaris
2.6 release. Failover provides a high level of availability for read-only
resources that are already replicated, such as man pages, other documentation,
and shared binaries. Failover can occur anytime after the file system is mounted.
Manual mounts can now list multiple replicas, much like the automounter in
previous releases. The automounter has not changed, except that failover need
not wait until the file system is remounted. See How to Use Client-Side Failover
and Client-Side Failover for more information.

Kerberos Support for the NFS Service

Support for Kerberos V4 clients was included in the Solaris 2.0 release.
In the 2.6 release, the mount and share
commands were altered to support NFS version 3 mounts that use Kerberos V5
authentication. Also, the share command was changed to
enable multiple authentication flavors for different clients. See RPCSEC_GSS Security Flavor
for more information about changes that involve security flavors. See “Configuring
SEAM NFS Servers” in System Administration Guide: Security
Services for information about Kerberos V5 authentication.

WebNFS Support

The Solaris 2.6 release also included the ability to make a file system
on the Internet accessible through firewalls. This capability was provided
by using an extension to the NFS protocol. One of the advantages to using
the WebNFSTM protocol for Internet access is its reliability.
The service is built as an extension of the NFS version 3 and version 2 protocol.
Also, an NFS server provides greater throughput under a heavy load than Hypertext
Transfer Protocol (HTTP) access to a Web server. This throughput can decrease
the amount of time that is required to retrieve a file. In addition, the WebNFS
implementation provides the ability to share these files without the administrative
overhead of an anonymous ftp site. See Security Negotiation for the WebNFS Service
for a description of more changes that are related to the WebNFS service.
See WebNFS Administration Tasks for more task information.

RPCSEC_GSS Security Flavor

A security flavor, called RPCSEC_GSS, is supported in the Solaris 7
release. This flavor uses the standard GSS-API interfaces to provide authentication,
integrity, and privacy, as well as enabling support of multiple security mechanisms.
See Kerberos Support for the NFS Service for more information about support of Kerberos
V5 authentication. See GSS-API Programming Guide for more information about GSS-API.

Solaris 7 Extensions for NFS Mounting

The Solaris 7 release includes extensions to the mount
command and automountd command. The extensions enable
the mount request to use the public file handle instead of the MOUNT protocol.
The MOUNT protocol is the same access method that the WebNFS service uses.
By circumventing the MOUNT protocol, the mount can occur through a firewall.
Additionally, because fewer transactions need to occur between the server
and the client, the mount should occur faster.

The extensions also enable NFS URLs to be used instead of the standard
path name. Also, you can use the public option
with the mount command and the automounter maps to force
the use of the public file handle. See WebNFS Support for more
information about changes to the WebNFS service.

Security Negotiation for the WebNFS Service

A new protocol has been added to enable a WebNFS client to negotiate
a security mechanism with an NFS server in the Solaris 8 release. This protocol
provides the ability to use secure transactions when using the WebNFS service.
See How WebNFS Security Negotiation Works for more information.

NFS Server Logging

In the Solaris 8 release, NFS server logging enables an NFS server to
provide a record of file operations that have been performed on its file
systems. The record includes information on what file was accessed, when the
file was accessed, and who accessed the file. You can specify the location
of the logs that contain this information through a set of configuration options.
You can also use these options to select the operations that should be logged.
This feature is particularly useful for sites that make anonymous FTP archives
available to NFS and WebNFS clients. See How to Enable NFS Server Logging for
more information.

Autofs Features

Autofs works with file systems that are specified in the local namespace.
This information can be maintained in NIS, NIS+, or local files.

A fully multithreaded version of automountd was included
in the Solaris 2.6 release. This enhancement makes autofs more reliable and
enables concurrent servicing of multiple mounts, which prevents the service
from hanging if a server is unavailable.

The new automountd also provides better on-demand
mounting. Previous releases would mount an entire set of file systems if the
file systems were hierarchically related. Now, only the top file system is
mounted. Other file systems that are related to this mount point are mounted
when needed.

The autofs service supports browsability of indirect maps. This support
enables a user to see what directories could be mounted, without having to
actually mount each one of the file systems. A -nobrowse option
has been added to the autofs maps so that large file systems, such as /net and /home, are not automatically browsable.
Also, you can turn off autofs browsability on each client by using the -n option with automount. See Disabling Autofs Browsability
for more information.