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
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

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

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.

9.4. NFS Client Configuration Files

NFS shares are mounted on the client side using the mount command. The format of the command is as follows:

mount -t <nfs-type> -o <options> <host>:</remote/export> </local/directory>

Replace <nfs-type> with either nfs for NFSv2 or NFSv3 servers, or nfs4 for NFSv4 servers. Replace <options> with a comma separated list of options for the NFS file system (refer to Section 9.4.3 Common NFS Mount Options for details). Replace <host> with the remote host, </remote/export> with the remote directory being mounted, and </local/directory> with the local directory where the remote file system is to be mounted.

Refer to the mount man page for more details.

If accessing an NFS share by manually issuing the mount command, the file system must be remounted manually after the system is rebooted. Red Hat Enterprise Linux offers two methods for mounting remote file systems automatically at boot time: the /etc/fstab file or the autofs service.

9.4.1. /etc/fstab

The /etc/fstab file is referenced by the netfs service at boot time, so lines referencing NFS shares have the same effect as manually typing the mount command during the boot process.

A sample /etc/fstab line to mount an NFS export looks like the following example:

<server>:</remote/export> </local/directory> <nfs-type> <options> 0 0

Replace <server> with the hostname, IP address, or fully qualified domain name of the server exporting the file system.

Replace </remote/export> with the path to the exported directory.

Replace </local/directory> with the local file system on which the exported directory is mounted. This mount point must exist before /etc/fstab is read or the mount fails.

Replace <nfs-type> with either nfs for NFSv2 or NFSv3 servers, or nfs4 for NFSv4 servers.

Replace <options> with a comma separated list of options for the NFS file system (refer to Section 9.4.3 Common NFS Mount Options for details). Refer to the fstab man page for additional information.

9.4.2. autofs

One drawback to using /etc/fstab is that, regardless of how infrequently a user accesses the NFS mounted file system, the system must dedicate resources to keep the mounted file system in place. This is not a problem with one or two mounts, but when the 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 can mount and unmount NFS file systems automatically, saving resources.

The autofs service is used to control the automount command 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 manually.

The autofs configuration files are arranged in a parent-child relationship. The main configuration file (/etc/auto.master) lists mount points on the system that are linked to a particular map type, which takes the form of other configuration files, programs, NIS maps, and other less common mount methods. The auto.master file contains lines referring to each of these mount points, organized in the following manner:

<mount-point> <map-type>

The <mount-point> element specifies the location of the mount on the local file system. The <map-type> specifies how the mount point is mounted. The most common method for auto mounting NFS exports is to use a file as the map type for the particular mount point. The map file is usually named auto.<mount-point>, where <mount-point> is the mount point designated in auto.master. A line within map files to mount an NFS export looks like the following example:

</local/directory>  -<options>  <server>:</remote/export>

Replace </local/directory;> with the local file system on which the exported directory is mounted. This mount point must exist before the map file is read, else the mount fails.

Replace <options> with a comma separated list of options for the NFS file system (refer to Section 9.4.3 Common NFS Mount Options for details). Be sure to include the hyphen character (-) immediately before the options list.

Replace <server> with the hostname, IP address, or fully qualified domain name of the server exporting the file system.

Replace </remote/export> with the path to the exported directory.

Replace <options> with a comma separated list of options for the NFS file system (refer to Section 9.4.3 Common NFS Mount Options for details).

While autofs configuration files can be used for a variety of mounts to many types of devices and file systems, they are particularly useful in creating NFS mounts. For example, some organizations store a user's /home/ directory on a central server via an NFS share, then configure the auto.master file on each of the workstations to point to an auto.home file containing the specifics for how to mount the /home/ directory via NFS. This allows the user to access personal data and configuration files in their /home/ directory by logging in anywhere on the network. The auto.master file in this situation would look similar to this:

/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 looks similar to the example below:

*  -fstype=nfs4,soft,intr,rsize=32768,wsize=32768,nosuid  server.example.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.example.com system on the mount point /home/. The mount options specify that each /home/ directory NFS mounts should use a particular collection of settings. For more information on mount options, including the ones used in this example, refer to Section 9.4.3 Common NFS Mount Options.

For more information about the autofs configuration files, refer to the auto.master man page.

9.4.3. Common NFS Mount Options

Beyond mounting a file system via NFS on a remote host, other options can be specified at the time of the mount to make it easier to use. These options can be used with manual mount commands, /etc/fstab settings, and autofs.

The following are options commonly used for NFS mounts:

  • fsid=num — Forces the file handle and file attributes settings on the wire to be num, instead of a number derived from the major and minor number of the block device on the mounted file system. The value 0 has special meaning when used with NFSv4. NFSv4 has a concept of a root of the overall exported file system. The export point exported with fsid=0 is used as this root.

  • hard or soft — Specifies whether the program using a file via an NFS connection should stop and wait (hard) for the server to come back online, if the host serving the exported file system is unavailable, or if it should report an error (soft).

    If hard is specified, the user cannot terminate the process waiting for the NFS communication to resume unless the intr option is also specified.

    If soft is specified, the user can set an additional timeo=<value> option, where <value> specifies the number of seconds to pass before the error is reported.

  • intr — Allows NFS requests to be interrupted if the server goes down or cannot be reached.

  • nfsvers=2 or nfsvers=3 — Specifies which version of the NFS protocol to use. This is useful for hosts that run multiple NFS servers. If no version is specified, NFS uses the highest supported version by the kernel and mount command. This option is not supported with NFSv4 and should not be used.

  • noacl — Turns off all ACL processing. This may be needed when interfacing with older versions of Red Hat Enterprise Linux, Red Hat Linux, or Solaris, since the most recent ACL technology is not compatible with older systems.

  • nolock — Disables file locking. This setting is occasionally required when connecting to older NFS servers.

  • noexec — Prevents execution of binaries on mounted file systems. This is useful if the system is mounting a non-Linux file system via NFS containing incompatible binaries.

  • nosuid — Disables set-user-identifier or set-group-identifier bits. This prevents remote users from gaining higher privileges by running a setuid program.

  • port=num — Specifies the numeric value of the NFS server port. If num is 0 (the default), then mount queries the remote host's portmapper for the port number to use. If the remote host's NFS daemon is not registered with its portmapper, the standard NFS port number of TCP 2049 is used instead.

  • rsize=num and wsize=num — These settings speed up NFS communication for reads (rsize) and writes (wsize) by setting a larger data block size, in bytes, to be transferred at one time. Be careful when changing these values; some older Linux kernels and network cards do not work well with larger block sizes. For NFSv2 or NFSv3, the default values for both parameters is set to 8192. For NFSv4, the default values for both parameters is set to 32768.

  • sec=mode — Specifies the type of security to utilize when authenticating an NFS connection.

    sec=sys is the default setting, which uses local UNIX UIDs and GIDs by means of AUTH_SYS to authenticate NFS operations.

    sec=krb5 uses Kerberos V5 instead of local UNIX UIDs and GIDs to authenticate users.

    sec=krb5i uses Kerberos V5 for user authentication and performs integrity checking of NFS operations using secure checksums to prevent data tampering.

    sec=krb5p uses Kerberos V5 for user authentication, integrity checking, and encrypts NFS traffic to prevent traffic sniffing. This is the most secure setting, but it also has the most performance overhead involved.

  • tcp — Specifies for the NFS mount to use the TCP protocol.

  • udp — Specifies for the NFS mount to use the UDP protocol.

Many more options are listed on the mount and nfs man pages.

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