Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




22.2. Mounting NFS File Systems

Use the mount command to mount a shared NFS directory from another machine:

mount /misc/local


The mount point directory on the local machine (/misc/local in the above example) must exist before this command can be executed.

In this command, is the hostname of the NFS file server, /misc/export is the directory that shadowman is exporting, and /misc/local is the location to mount the file system on the local machine. After the mount command runs (and if the client has proper permissions from the NFS server) the client user can execute the command ls /misc/local to display a listing of the files in /misc/export on

22.2.1. Mounting NFS File Systems using /etc/fstab

An alternate way to mount an NFS share from another machine is to add a line to the /etc/fstab file. The line must state the hostname of the NFS server, the directory on the server being exported, and the directory on the local machine where the NFS share is to be mounted. You must be root to modify the /etc/fstab file.

The general syntax for the line in /etc/fstab is as follows:

server:/usr/local/pub    /pub   nfs    rsize=8192,wsize=8192,timeo=14,intr

The mount point /pub must exist on the client machine before this command can be executed. After adding this line to /etc/fstab on the client system, type the command mount /pub at a shell prompt, and the mount point /pub is mounted from the server.

22.2.2. Mounting NFS File Systems using autofs

A third option for mounting an NFS share is the use of the autofs service. Autofs uses the automount daemon to manage your mount points by only mounting them dynamically when they are accessed.

Autofs consults the master map configuration file /etc/auto.master to determine which mount points are defined. It then starts an automount process with the appropriate parameters for each mount point. Each line in the master map defines a mount point and a separate map file that defines the file systems to be mounted under this mount point. For example, the /etc/auto.misc file might define mount points in the /misc directory; this relationship would be defined in the /etc/auto.master file.

Each entry in auto.master has three fields. The first field is the mount point. The second field is the location of the map file, and the third field is optional. The third field can contain information such as a timeout value.

For example, to mount the directory /proj52 on the remote machine at the mount point /misc/myproject on your machine, add the following line to auto.master:

/misc   /etc/auto.misc --timeout 60

Next, add the following line to /etc/auto.misc:

myproject  -rw,soft,intr,rsize=8192,wsize=8192

The first field in /etc/auto.misc is the name of the /misc subdirectory. This directory is created dynamically by automount. It should not actually exist on the client machine. The second field contains mount options such as rw for read and write access. The third field is the location of the NFS export including the hostname and directory.


The directory /misc must exist on the local file system. There should be no subdirectories in /misc on the local file system.

To start the autofs service, at a shell prompt, type the following command:

/sbin/service autofs restart

To view the active mount points, type the following command at a shell prompt:

/sbin/service autofs status

If you modify the /etc/auto.master configuration file while autofs is running, you must tell the automount daemon(s) to reload by typing the following command at a shell prompt:

/sbin/service autofs reload

To learn how to configure autofs to start at boot time, and for information on managing services, refer to Chapter 20 Controlling Access to Services.

22.2.3. Using TCP

The default transport protocol for NFSv4 is TCP; however, the Red Hat Enterprise Linux 4 kernel includes support for NFS over UDP. To use NFS over UDP, include the -o udp option to mount when mounting the NFS-exported file system on the client system.

There are three ways to configure an NFS file system export. On demand via the command line (client side), automatically via the /etc/fstab file (client side), and automatically via autofs configuration files, such as /etc/auto.master and /etc/auto.misc (server side with NIS).

For example, on demand via the command line (client side):

mount -o udp /misc/local

When the NFS mount is specified in /etc/fstab (client side):

server:/usr/local/pub    /pub   nfs    rsize=8192,wsize=8192,timeo=14,intr,udp

When the NFS mount is specified in an autofs configuration file for a NIS server, available for NIS enabled workstations:

myproject  -rw,soft,intr,rsize=8192,wsize=8192,udp

Since the default is TCP, if the -o udp option is not specified, the NFS-exported file system is accessed via TCP.

The advantages of using TCP include the following:

  • Improved connection durability, thus less NFS stale file handles messages.

  • Performance gain on heavily loaded networks because TCP acknowledges every packet, unlike UDP which only acknowledges completion.

  • TCP has better congestion control than UDP (which has none). On a very congested network, UDP packets are the first packets that are dropped. This means that if NFS is writing data (in 8K chunks) all of that 8K must be retransmitted over UDP. Because of TCP's reliability, only parts of that 8K data are transmitted at a time.

  • Error detection. When a TCP connection breaks (due to the server being unavailable) the client stops sending data and restarts the connection process once the server becomes available. With UDP, since it's connection-less, the client continues to pound the network with data until the server reestablishes a connection.

The main disadvantage is that there is a very small performance hit due to the overhead associated with the TCP protocol.

22.2.4. Preserving ACLs

The Red Hat Enterprise Linux 4 kernel provides ACL support for the ext3 file system and ext3 file systems mounted with the NFS or Samba protocols. Thus, if an ext3 file system has ACLs enabled for it and is NFS exported, and if the NFS client can read ACLs, they are used by the NFS client as well.

  Published under the terms of the GNU General Public License Design by Interspire