You are on page 1of 25

Chapter – 16

Network File System (NFS)


Objectives:

At the end of this module, you would have gained fair


knowledge on:

•Concept of Network File System


•Exporting file systems using NFS
•Mounting a Remote File System exported through
NFS
•Configuring Autofs
NFS (Network File
System) exists to allow remote hosts to
mount partitions on a particular system
and use them as though they were
local filesystems.

This allows files to be


organized in a central location, while
providing the functionality of allowing
authorized users continuous access to
them.
Two versions of NFS are
currently in use. NFS version 2, which
has been around for several years, is
widely supported by various operating
systems.
NFS version 3 has several
more features, including a variable file
handle size and better error reporting.
Red Hat Linux supports both NFSv2 and
NFSv3, and uses NFSv3 by default when
connecting with a server that supports it.
Mounting NFS Filesystems
Use the mount command to mount
an NFS filesystem from another machine:
mount shadowman:/mnt/export /mnt/local
The mount point directory on local machine
(/mnt/local in the above example) must exist.

In this command, shadowman is the


hostname of the NFS fileserver, /mnt/export is
the filesystem that shadowman is exporting,
and /mnt/local is a directory on the local
machine where we want to mount the
filesystem.
Linux uses a combination of kernel-
level support and continuously running daemon
processes to provide NFS file sharing, and NFS
support must be enabled in the Linux kernel to
function.
NFS uses Remote Procedure Calls
(RPC) to route requests between clients and
servers, meaning that the portmap service must
be enabled and active at the proper runlevels for
NFS communication to occur. Working
with portmap, various other processes ensure that
a particular NFS connection is allowed and may
proceed without error:
rpc.mountd — The running process that receives the mount
request from an NFS client and checks to see if it matches
with a currently exported filesystem.

rpc.nfsd — The process that implements the user-level part of


the NFS service. It works with the Linux kernel to meet the
dynamic demands of NFS clients, such as providing additional
server threads for NFS clients to utilize.
rpc.lockd — A daemon that is not necessary with modern
kernels. NFS file locking is now done by the kernel. It is
included with the nfs-utils package for users utilizing older
kernels that do not include this functionality by default.
rpc.statd — Implements the Network Status Monitor (NSM)
RPC protocol. This provides reboot notification when an NFS
server is restarted without being gracefully brought down.
rpc.rquotad — An RPC server that provides user quota
information for remote users.
Not all of these programs are required for
NFS service. The only services that must be enabled
are rpc.mountd, rpc.nfsd, and portmap. The other
daemons provide additional functionality, based on
the particular requirements of your server
environment.
NFS version 2 uses the User Datagram
Protocol (UDP) to provide a stateless network
connection between the client and server. (NFS
version 3 can use UDP or TCP running over an IP.)
The stateless UDP connection minimizes network
traffic, as the NFS server sends the client a cookie
after the client is authorized to access the shared
volume.
Using NFS, authentication only occurs
when the client is attempting to mount to a
remote filesystem. The NFS server uses the
/etc/hosts.allow and /etc/hosts.deny files to
determine if a particular host should be
specifically permitted or prevented access via
NFS.
Then, the NFS server refers to the
/etc/exports file to uncover that host's privileges
for the various mounts available. After granting
access, any file and directory operations are sent
to the server using remote procedure calls.
NFS and portmap
NFS relies upon remote procedure calls (RPC) to
function. portmap is required to map RPC requests to the
correct services. RPC processes notify portmap when they
start, revealing the port number they are monitoring and the
RPC program numbers they expect to serve.
The client system then contacts portmap on the
server with a particular RPC program number. portmap then
redirects the client to the proper port number to communicate
with its intended service.
Because RPC-based services rely on portmap to make all
connections with incoming client requests, portmap must be
available before any of these services start. If, for some reason,
the portmap service unexpectedly quits, restart portmap and
any services running when it was started.
portmap Status
As portmap provides the coordination
between RPC services and the port numbers utilized to
communicate with them, it is useful to be able to get a
picture of the current RPC services using portmap when
troubleshooting.
The rpcinfo command shows each RPC-
based service with its port number, RPC program
number, version, and IP protocol type (TCP or UDP).
To make sure the proper NFS RPC-based
services are enabled for portmap, rpcinfo can be useful:
[root@bleach/]#rpcinfo -p some.machine.com
Exporting NFS Filesystems
The /etc/exports file controls what filesystems you wish to
export. Its format is as follows:
directory hostname(options)
The (options) are not required. For example:
/mnt/export aita.accel.com
would allow users from aita.accel.com to mount /mnt/export
with the default read-only permissions, but:
/mnt/export aita.accel.com(rw)
would allow users from aita.accel.com to mount /mnt/export
with read-write privileges.
/sbin/service nfs reload
Starting and Stopping the Server
On the server that is exporting NFS filesystems, the nfs
service must be running.
View the status of the NFS daemon with the command
/sbin/service nfs status
Start the NFS daemon with the command
/sbin/service nfs start
Stop the NFS daemon with the command
/sbin/service nfs stop
To start the nfs service at boot time, use the command:
/sbin/chkconfig --level 345 nfs on
You can also use ntsysv or serviceconf to configure which
services start at boot time
NFS Server Configuration Files
Configuring a system to share files and directories using
NFS is straightforward. Every filesystem being exported to
remote users via NFS, as well as the access rights relating to
those filesystems, is located in the /etc/exports file.
This file is read by the exportfs command to give
rpc.mountd and rpc.nfsd the information necessary to allow
the remote mounting of a filesystem by an authorized host.
The exportfs command allows you to selectively export
or unexport directories without restarting the various NFS
services. When exportfs is passed the proper options, the
filesystems to be exported are written to /var/lib/nfs/xtab.
Since rpc.mountd refers to the xtab file when deciding
access privileges to a filesystem, changes to the list of
exported filesystems take effect immediately.
/etc/exports
The /etc/exports file is the standard for
controlling which filesystems are exported to which
hosts, as well as specifying particular options that
control everything.
Blank lines are ignored, comments can be made
using #, and long lines can be wrapped with a backslash
(\). Each exported filesystem should be on its own line.
Lists of authorized hosts placed after an
exported filesystem must be separated by space
characters. Options for each of the hosts must be placed
in parentheses directly after the host identifier, without
any spaces separating the host and the first parenthesis.
When specifying hosts to be allowed to use a
particular exported filesystem, a variety of methods can be used,
including:
• single host — Where one particular host is specified with a
fully qualified domain name, hostname, or IP address.
• wildcards — Where a * or ? character is used to take into
account a grouping of fully qualified domain names or IP
addresses or those that match a particular string of letters.
∀• IP networks — Allows the matching of hosts based on their IP
addresses within a larger network.
∀•netgroups — Permits an NIS netgroup name, written as
@<group-name>, to be used. This effectively puts the NIS server
in charge of access control for this exported filesystem, where
users can be added and removed from an NIS group without
affecting /etc/exports.
NFS Client Configuration Files
Any NFS share made available by a
server can be mounted using various methods. Of
course, the share can be manually mounted, using
the mount command, to acquire the exported
filesystem at a particular mount point.
However, this requires that the root user
type the mount command every time the system
restarts. In addition, the root user must remember to
unmount the filesystem when shutting down the
machine.
Two methods of configuring NFS mounts
include modifying the /etc/fstab or utilizing the autofs
service.
/etc/fstab
Placing a properly formatted line in the
/etc/fstab file has the same effect as manually
mounting the exported filesystem. The /etc/fstab
file is read by the /etc/rc.d/init.d/netfs script at
system startup. The proper filesystem mounts,
including NFS, are put into place.
A sample /etc/fstab line to mount an
NFS export looks like the following:
<server-host>:</path/to/shared/directory>
</local/mount/point> nfs <options> 0 0
autofs
One drawback to using /etc/fstab is
that, regardless of how much you use that
mounted filesystem, your system must dedicate
resources to keep that mount in place.
This is not a problem with one or
two mounts, but when your system is maintaining
mounts to a dozen systems at one time, overall
system performance can suffer.
An alternative to /etc/fstab is to use the
kernel-based automount utility, which will
mount and unmount NFS filesystems
automatically, saving resources.
The autofs script, located in /etc/rc.d/init.d, is used to
control automount through the /etc/auto.master primary
configuration file. While automount can be specified on the
command line, it is more convenient to specify the mount points,
hostname, exported directory, and options in a set of files rather
than typing them all by hand.
By running autofs as a service that starts and stops in
designated runlevels, the mount configurations in the various files
can be automatically implemented. In order to use autofs, you
must have the autofs RPM installed on your system.
The autofs configuration files are arranged in a parent-child
relationship. A main configuration file (/etc/auto.master) refers
mount points on your system that are linked to a particular map
type, which take the form of other configuration files, programs,
NIS maps, and other less common mount methods
<mount-point> <map-type>
/home /etc/auto.home
This sets up the /home mount point on the local
system to be configured by the /etc/auto.home file,
which may look similar to this:
-fstype=nfs,soft,intr,rsize=8192,wsize=8192,nosuid
server.domain.com:/home/&
This line states that any directory a user tries to
access under the local /home directory (due to the
asterisk character) should result in an NFS mount on the
server.domain.com system within its exported /home
filesystem.
The mount options specify that each /home
directory NFS mounts should use a particular collection
of settings
Securing NFS
NFS works well for sharing entire
filesystems with a large number of known hosts
in a largely transparent manner. Many users
accessing files over an NFS mount may not be
aware that the filesystem they are using is not
local to their system. However, with ease of use
comes a variety of potential security problems.
The following points should be
considered when exporting NFS filesystems on a
server or mounting them on a client. Doing so will
minimize NFS security risks and better protect
your data and equipment.
Host Access
NFS controls who can mount an exported filesystem
based on the host making the mount request, not the user that will
utilize the filesystem. Hosts must be given explicit rights to mount
the exported filesystem.
Access control is not possible for users, other than
file and directory permissions. In other words, when you export a
filesystem via NFS to a remote host, you are not only trusting the
host you are allowing to mount the filesystem. You are also
allowing any user with access to that host to use your filesystem
as well.
The risks of doing this can be controlled, such as
requiring read-only mounts and squashing users to a common
user and group ID, but these solutions may prevent the mount
from being used in the way originally intended.
File Permissions
•Once the NFS filesystem is mounted read-write by a remote host,
protection for each shared file involves its permissions, and its
user and group ID ownership.
•If two users that share the same user ID value mount the same
NFS filesystem, they will be able to modify each others files
•Additionally, anyone logged in as root on the client system can
use the su command to become a user who could access
particular files via the NFS share.
•The default behavior when exporting a filesystem via NFS is to
use root squashing. This sets the user ID of anyone utilizing the
NFS share as the root user on their local machine to a value of
the server's nobody account.
•You should never turn off root squashing unless multiple users
with root access to your server does not bother you.
Points to remember
∀•  NFS is used to share disk resources in UNIX
systems.
∀•   Other operating systems also supports NFS
∀•  NFS was originally developed by SUN Microsystems
during 1980s.
∀•   Each NFS transaction is complete in its nature. A
transaction doesn’t needs the information about the
previous transaction.
∀• If a transaction is interrupted due to network
problems, the interrupted transaction can be continued
after restoring the network connections.