A practical guide to Fedora and Red Hat Enterprise Linux, 7th Edition (2014)

---

Objectives

After reading this chapter you should be able to:

Describe the use, history, and architecture of NFS

Mount remote NFS shares

Configure an NFS server to share directories with specific clients

Troubleshoot mount failures

Set up automount to mount directories on demand

The NFS (Network Filesystem) protocol, a UNIX de facto standard developed by Sun Microsystems, allows a server to share selected local directory hierarchies with client systems on a heterogeneous network. NFS runs on UNIX, DOS, Windows, VMS, Linux, and more. Files on the remote computer (the server) appear as if they are present on the local system (the client). Most of the time, the physical location of a file is irrelevant to an NFS user; all standard Linux utilities work with NFS remote files the same way as they operate with local files.

NFS reduces storage needs and system administration workload. As an example, each system in a company traditionally holds its own copy of an application program. To upgrade the program, the administrator needs to upgrade it on each system. NFS allows you to store a copy of a program on a single system and give other users access to it over the network. This scenario minimizes storage requirements by reducing the number of locations that need to maintain the same data. In addition to boosting efficiency, NFS gives users on the network access to the same data (not just application programs), thereby improving data consistency and reliability. By consolidating data, it reduces administrative overhead and provides a convenience to users.

NFS has been pejoratively referred to as the Nightmare Filesystem, but NFSv4 has fixed many of the shortcomings of NFSv3. NFSv4

• Performs well over high-latency, low-bandwidth Internet connections.

• Because it uses a single port, NFSv4 is much easier to set up with firewalls and NAT than NFSv3 was.

• Has strong, built-in security.

• Has lock and mount protocols integrated into the NFS protocol.

• Handles client and server crashes better than NFSv3 because it provides stateful operations.

• Improves performance by making extensive use of caching on the client.

• Supports ACLs (Access Control Lists).

AUTH_SYS authentication

NFSv4 supports AUTH_SYS authentication, the standard method of authentication under NFSv3. Because AUTH_SYS uses UIDs and GIDs to authenticate users, it is easy to crack. NFSv4 uses AUTH_SYS security by default. See the sec option (page 816) for more information.

RPCSEC_GSS authentication

NFSv4 also supports the newer RPCSEC_GSS (see the rpc.gssd man page and www.citi.umich.edu/projects/nfsv4/gssd), which provides secure authentication as well as verification and encryption. RPCSEC_GSS is based on GSS-API (Generic Security Services Application Programming Interface; www.faqs.org/faqs/kerberos-faq/general/section-84.html) and can use Kerberos 5 (best for enterprise or LAN use) and LIBKEY (based on SPKM-3; best for Internet use) among other authentication protocols.

This chapter describes setting up an NFSv4 client and server using AUTH_SYS authentication, the Fedora/RHEL default mode.

Introduction to NFS

Figure 22-1 shows the flow of data in a typical NFS client/server setup. An NFS directory hierarchy appears to users and application programs as just another directory hierarchy. By looking at it, you cannot tell a given directory holds a remotely mounted NFS directory hierarchy and not a local filesystem. The NFS server translates commands from the client into operations on the server’s filesystem.

Figure 22-1 Flow of data in a typical NFS client/server setup

Diskless systems

In many computer facilities, user files are stored on a central fileserver equipped with many large-capacity disk drives and devices that quickly and easily make backup copies of the data. A diskless system boots from a fileserver (netboots—discussed next), a DVD, or a USB flash drive and loads system software from a fileserver. The Linux Terminal Server Project (LTSP.org) Web site says it all: “Linux makes a great platform for deploying diskless workstations that boot from a network server. The LTSP is all about running thin client computers in a Linux environment.” Because a diskless workstation does not require a lot of computing power, you can give older, retired computers a second life by using them as diskless systems.

Netboot/PXE

You can netboot (page 1262) systems that are appropriately set up. Fedora/RHEL includes TFTP (Trivial File Transfer Protocol; tftp-server package) that you can use to set up a PXE (Preboot Execution Environment) boot server for Intel systems. Non-Intel architectures have historically included netboot capabilities, which Fedora/RHEL also supports. In addition, you can build the Linux kernel so it mounts root (/) using NFS. Given the many ways to set up a system, the one you choose depends on what you want to do. See the Remote-Boot mini-HOWTO for more information.

Dataless systems

Another type of Linux system is a dataless system, in which the client has a disk but stores no user data (only Linux and the applications are kept on the disk). Setting up this type of system is a matter of choosing which directory hierarchies are mounted remotely.

df: shows where directory hierarchies are mounted

The df utility displays a list of the directory hierarchies available on the system, along with the amount of disk space, free and used, on each. The –h (human) option makes the output more intelligible. Device names in the left column that are prepended with hostname: specify directory hierarchies that are available through NFS.

[zach@guava ~]$ cd; pwd

[zach@guava ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/fedora-root 37G 3.8G 32G 11% /
...
/dev/sda1 477M 99M 354M 22% /boot
plum:/home/zach 37G 3.8G 32G 11% /home/zach

When Zach logs in on guava, his home directory, /home/zach, is on the remote system plum. Using NFS, the /home/zach directory hierarchy on plum is mounted on guava as /home/zach. Any files in the zach directory on guava are hidden while the zach directory from plum is mounted; they reappear when the directory is unmounted. The / filesystem is local to guava.

The df –T option adds a Type column to the display. The following output shows the directory mounted at /home/zach is an nfs4 directory hierarchy; / and /boot are local ext4 filesystems.

$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/fedora-root ext4 37G 3.8G 32G 11% /
...
/dev/sda1 ext4 477M 99M 354M 22% /boot
plum:/home/zach nfs4 37G 3.8G 32G 11% /home/zach

The df –t option displays a single filesystem type. With an argument of nfs4 it displays NFS directory hierarchies:

$ df -ht nfs4
Filesystem Size Used Avail Use% Mounted on
plum:/home/zach 37G 3.8G 32G 11% /home/zach

Security

By default, an NFS server uses AUTH_SYS (page 803) authentication, which is based on the trusted-host paradigm (page 302) and has all the security shortcomings that plague other services based on this paradigm. In addition, in this mode NFS file transfers are not encrypted. Because of these issues, you should implement NFS on a single LAN segment only, where you can be (reasonably) sure systems on the LAN segment are what they claim to be. Make sure a firewall blocks NFS traffic from outside the LAN and never use NFS over the Internet. To improve security, make sure UIDs and GIDs are the same on the server and clients (page 817).

Alternately, you can use RPCSEC_GSS (page 803) authentication, one of the new security features available under NFSv4. RPCSEC_GSS provides authentication, verification, and encryption. This chapter does not cover setting up an NFS server that uses RPCSEC_GSS authentication.

More Information

Web

NFSv4 secure installation tutorial: nfsv4.bullopensource.org/doc/kerberosnfs/krbnfs_howto_v3.pdf

NFS: nfs.sourceforge.net, www.citi.umich.edu/projects/nfsv4, wiki.linux-nfs.org

GSS-API: www.faqs.org/faqs/kerberos-faq/general/section-84.html

PXE boot server tutorial (TFTP): alteeve.ca/w/Setting_Up_a_PXE_Server_in_Fedora

Local

man pages: autofs (sections 5 and 8), automount, auto.master, exportfs, exports, mountstats, nfs (especially see SECURITY CONSIDERATIONS), rpc.idmapd, rpc.gssd, rpc.mountd, rpc.nfsd, and showmount

HOWTO

NFS-HOWTO: nfs.sourceforge.net/nfs-howto

Book

NFS Illustrated by Callaghan, Addison-Wesley (January 2000)

Running an NFS Client

This section describes how to set up an NFS client, mount remote directory hierarchies, and improve NFS performance. See page 819 for a list of error messages and troubleshooting tips.

Prerequisites

Install the following packages:

• nfs-utils (installed by default)

• rpcbind (installed by default; not needed with NFSv4)

Check rpcbind is running

A new Fedora/RHEL system boots with rpcbind installed and running; For NFSv3 only (not NFSv4) rpcbind must be running before you can start the nfs service. Use the systemctl status command to make sure rpcbind is running.

# systemctl status rpcbind.service

JumpStart I: Mounting a Remote Directory Hierarchy

To set up an NFS client, mount the remote directory hierarchy the same way you mount a local directory hierarchy (page 520).

The following examples show two ways to mount a remote directory hierarchy, assuming dog is on the same network as the local system and is sharing /home and /export with the local system. The /export directory on dog holds two directory hierarchies you want to mount: /export/progsand /export/oracle. The example mounts dog’s /home directory on /dog.home on the local system, /export/progs on /apps, and /export/oracle on /oracle.

First run mkdir on the local (client) system to create the directories that are the mount points for the remote directory hierarchies:

# mkdir /dog.home /apps /oracle

You can mount any directory hierarchy from an exported directory hierarchy. In this example, dog exports /export and the local system mounts /export/progs and /export/oracle. The following commands manually mount the directory hierarchies one time:

# mount dog:/home /dog.home
# mount -o ro,nosuid dog:/export/progs /apps
# mount -o ro dog:/export/oracle /oracle

By default, directory hierarchies are mounted read-write, assuming the NFS server is exporting them with read-write permissions. The first of the preceding commands mounts the /home directory hierarchy from dog on the local directory /dog.home. The second and third commands use the–o ro option to force a readonly mount. The second command adds the nosuid option, which forces setuid (page 196) executables in the mounted directory hierarchy to run with regular permissions on the local system.

nosuid option

If a user has the ability to run a setuid program, that user has the power of a user with root privileges. This ability should be limited. Unless you know a user will need to run a program with setuid permissions from a mounted directory hierarchy, always mount a directory hierarchy with thenosuid option. For example, you would need to mount a directory hierarchy with setuid privileges when the root partition of a diskless workstation is mounted using NFS.

nodev option

Mounting a device file creates another potential security hole. Although the best policy is not to mount untrustworthy directory hierarchies, it is not always possible to implement this policy. Unless a user needs to use a device on a mounted directory hierarchy, mount directory hierarchies with the nodev option, which prevents character and block special files (page 518) on the mounted directory hierarchy from being used as devices.

fstab file

If you mount directory hierarchies frequently, you can add entries for the directory hierarchies to the /etc/fstab file (page 811). (Alternately, you can use automount; see page 821.) The following /etc/fstab entries mount the same directory hierarchies as in the previous example at the same time that the system mounts the local filesystems:

$ cat /etc/fstab
...
dog:/home /dog.home nfs4 rw 0 0
dog:/export/progs /apps nfs4 ro,nosuid 0 0
dog:/export/oracle /oracle nfs4 ro 0 0

A file mounted using NFS is always of type nfs4 on the local system, regardless of what type it is on the remote system. Typically you do not run fsck on or back up an NFS directory hierarchy. The entries in the third, fifth, and sixth columns of fstab are usually nfs (filesystem type), 0 (do not back up this directory hierarchy with dump [page 606]), and 0 (do not run fsck [page 525] on this directory hierarchy). The options for mounting an NFS directory hierarchy differ from those for mounting an ext4 or other type of filesystem. See the section on mount (next) for details.

Unmounting directory hierarchies

Use umount to unmount a remote directory hierarchy the same way you unmount a local filesystem (page 523).

mount: Mounts a Directory Hierarchy

The mount utility (page 520) associates a directory hierarchy with a mount point (a directory). You can use mount to mount an NFS (remote) directory hierarchy. This section describes some mount options. It lists default options first, followed by nondefault options (enclosed in parentheses). You can use these options on the command line or set them in /etc/fstab (page 811). For a complete list of options, refer to the mount and nfs man pages.

Following are two examples of mounting a remote directory hierarchy. Both mount the /home/public directory from the system plum on the /plum.public mount point on the local system. When called without arguments, mount displays a list of mounted filesystems, including the options the filesystem is mounted with.

The first mount command mounts the remote directory without specifying options. The output from the second mount command, which lists the mounted filesystems, is sent through a pipeline to grep, which displays the single (very long) logical line that provides information about the remotely mounted directory. All the options, starting with rw (read-write) are defaults or are specified by mount.

# mount plum:/home/public /plum.public
# mount | grep plum
plum:/home/public on /plum.public type nfs4
(rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=60
0,retrans=2,sec=sys,clientaddr=192.168.206.180,local_lock=none,addr=192.168.206.181)
# umount /plum.public

The next mount command mounts the remote directory specifying the noac option (–o noac; next). The output from the second mount command shows the addition of the noac option. When you specify noac, mount adds the acregmin, acregmax, acdirmin, and acdirmax options (all next) and sets them to 0.

# mount -o noac plum:/home/public /plum.public
# mount | grep plum
plum:/home/public on /plum.public type nfs4 (rw,relatime,sync,vers=4.0,rsize=131072,wsize=131072,namlen=255,acregmin=0,acregmax=0,acd
irmin=0,acdirmax=0,hard,noac,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.
168.206.180,local_lock=none,addr=192.168.206.181)

Attribute Caching

A file’s inode (page 515) stores file attributes that provide information about a file, such as file modification time, size, links, and owner. File attributes do not include the data stored in a file. Typically file attributes do not change very often for an ordinary file; they change even less often for a directory file. Even the size attribute does not change with every write instruction: When a client is writing to an NFS-mounted file, several write instructions might be given before the data is transferred to the server. In addition, many file accesses, such as that performed by ls, are readonly operations and, therefore, do not change the file’s attributes or its contents. Thus a client can cache attributes and avoid costly network reads.

The kernel uses the modification time of the file to determine when its cache is out-of-date. If the time the attribute cache was saved is later than the modification time of the file itself, the data in the cache is current. The server must periodically refresh the attribute cache of an NFS-mounted file to determine whether another process has modified the file. This period is specified as a minimum and maximum number of seconds for ordinary and directory files. Following is a list of options that affect attribute caching:

ac (noac)

(attribute cache) Permits attribute caching. The noac option disables attribute caching. Although noac slows the server, it avoids stale attributes when two NFS clients actively write to a common directory hierarchy. See the example in the preceding section that shows that when you specifynoac, mount sets each of the following four options to 0, which in effect specifies that attributes will not be cached. Default is ac.

acdirmax=n

(attribute cache directory file maximum) The n is the number of seconds, at a maximum, that NFS waits before refreshing directory file attributes. Default is 60 seconds.

acdirmin=n

(attribute cache directory file minimum) The n is the number of seconds, at a minimum, that NFS waits before refreshing directory file attributes. Default is 30 seconds.

acregmax=n

(attribute cache regular file maximum) The n is the number of seconds, at a maximum, that NFS waits before refreshing regular file attributes. Default is 60 seconds.

acregmin=n

(attribute cache regular file minimum) The n is the number of seconds, at a minimum, that NFS waits before refreshing regular file attributes. Default is 3 seconds.

actimeo=n

(attribute cache timeout) Sets acregmin, acregmax, acdirmin, and acdirmax to n seconds. Without this option, each individual option takes on its assigned or default value.

Error Handling

The following options control what NFS does when the server does not respond or when an I/O error occurs. To allow for a mount point located on a mounted device, a missing mount point is treated as a timeout.

fg (bg)

(foreground) Exits with an error status if a foreground NFS mount fails. The bg (background) option retries failed NFS mount attempts in the background. Default is fg.

hard (soft)

With the hard option, NFS retries indefinitely when an NFS request times out. With the soft option, NFS retries the connection retrans times and then reports an I/O error to the calling program. In general, it is not advisable to use soft. As the mount man page says of soft, “Usually it just causes lots of trouble.” For more information refer to “Improving Performance” on page 810. Default is hard.

retrans=n

(retransmission value) NFS generates a server not responding message after n timeouts. NFS continues trying after n timeouts if hard is set and fails if soft is set. Default is 3.

retry=n

(retry value) The number of minutes that NFS retries a mount operation before giving up. Set to 0 to cause mount to exit immediately if it fails. Default is 2 minutes for foreground mounts (fg) and 10,000 minutes for background mounts (bg).

timeo=n

(timeout value) The n is the number of tenths of a second NFS waits for a response before retransmitting. For NFS over TCP, the default is 600 (60 seconds). See the nfs man page for information about the defaults used by NFS over UDP. On a busy network, in case of a slow server, or when the request passes through multiple routers, increasing this value might improve performance. See “Timeouts” on the next page for more information.

Miscellaneous Options

Following are additional useful options:

lock (nolock)

Permits NFS locking. The nolock option disables NFS locking and is useful with older servers that do not support NFS locking. Default is lock.

nfsvers=n

The n specifies the NFS version number used to contact the NFS server (2, 3, or 4). The mount fails if the server does not support the specified version. By default, the client negotiates the version number, starting with 4, followed by 3 and then 2.

port=n

The n specifies the number of the port used to connect to the NFS server. A 0 causes NFS to query rpcbind on the server to determine the port number. When this option is not specified, NFS uses port 2049.

rsize=n

(read block size) The n specifies the maximum number of bytes read at one time from an NFS server. Refer to “Improving Performance.” Default is negotiated by the client and server and is the largest both can support.

wsize=n

(write block size) The n specifies the maximum number of bytes written at one time to an NFS server. Refer to “Improving Performance.” Default is negotiated by the client and server and is the largest both can support.

udp

Uses UDP for an NFS mount. Default is tcp.

tcp

Uses TCP for an NFS mount. Default is tcp.

Improving Performance

hard/soft

Several parameters can affect the performance of NFS, especially over slow connections such as a line with a lot of traffic or a line controlled by a modem. If you have a slow connection, make sure hard (default; page 809) is set so timeouts do not abort program execution.

Block size

One of the easiest ways to improve NFS performance is to increase the block size—that is, the number of bytes NFS transfers at a time. Try not specifying rsize and wsize (previous) so the client and server set these options to their maximum values. Experiment until you find the optimal block size. Unmount and mount the directory hierarchy each time you change an option. See the Linux NFS-HOWTO at nfs.sourceforge.net/nfs-howto for more information on testing different block sizes.

Timeouts

NFS waits the amount of time specified by the timeo (timeout; page 809) option for a response to a transmission. If it does not receive a response in this amount of time, NFS sends another transmission. The second transmission uses bandwidth that, over a slow connection, might slow things down even more. You might be able to increase performance by increasing timeo.

You can test the speed of a connection with the size of packets you are sending (rsize and wsize; both above) by using ping with the –s (size) option. The –c (count) option specifies the number of transmissions ping sends.

$ ping -s 4096 -c 4 plum
PING plum (192.168.206.181) 4096(4124) bytes of data.
4104 bytes from plum (192.168.206.181): icmp_seq=1 ttl=64 time=0.460 ms
4104 bytes from plum (192.168.206.181): icmp_seq=2 ttl=64 time=0.319 ms
4104 bytes from plum (192.168.206.181): icmp_seq=3 ttl=64 time=0.372 ms
4104 bytes from plum (192.168.206.181): icmp_seq=4 ttl=64 time=0.347 ms

--- plum ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.319/0.374/0.460/0.056 ms

The preceding example uses a packet size of 4096 bytes and shows a fast average packet round-trip time of about one-half of a millisecond. Over a modem line, you can expect times of several seconds. If the connection is dealing with other traffic, the time will be even longer. Run the test during a period of heavy traffic. Try increasing timeo to three or four times the average round-trip time (to allow for unusually bad network conditions, such as when the connection is made) and see whether performance improves. Remember that the timeo value is given in tenths of a second (100 milliseconds = one-tenth of a second).

/etc/fstab: Mounts Directory Hierarchies Automatically

The /etc/fstab file (page 524) lists directory hierarchies that the system might mount automatically as it comes up. You can use the options discussed in the preceding sections on the command line or in the fstab file.

The following line from the fstab file on guava mounts the /home/public directory from plum on the /plum.public mount point on guava:

plum:/home/public /plum.public nfs4 rsize=8192,wsize=8192 0 0

A mount point should be an empty, local directory. (Files in a mount point are hidden when a directory hierarchy is mounted on it.) The type of a filesystem mounted using NFS is always nfs4, regardless of its type on its local system. You can increase the rsize and wsize options to improve performance. Refer to “Improving Performance” on page 810.

The next example from fstab mounts a filesystem from dog:

dog:/export /dog.export nfs4 timeo=50,hard 0 0

Because the local system connects to dog over a slow connection, timeo is increased to 5 seconds (50-tenths of a second). Refer to “Timeouts” on page 810. In addition, hard is set to make sure NFS keeps trying to communicate with the server after a major timeout. Refer to hard/soft on page 810.

The final example from fstab shows a remote-mounted home directory. Because dog is a local server and is connected via a reliable, high-speed connection, timeo is decreased and rsize and wsize are increased substantially:

dog:/home /dog.home nfs4 timeo=4,rsize=16384,wsize=16384 0 0

Setting Up an NFS Server

Prerequisites

Install the following packages:

• nfs-utils (installed by default)

• rpcbind (installed by default; not needed for NFSv4)

• system-config-nfs (Fedora; optional)

Check rpcbind is running

A new Fedora/RHEL system boots with rpcbind installed and running; For NFSv3 only (not NFSv4) rpcbind must be running before you can start the nfs service. Use the systemctl status command to make sure rpcbind is running.

# systemctl status rpcbind.service

Enable and start nfs

Run systemctl to cause the nfs service to start each time the system enters multiuser mode and then start the nfs service. Use the systemctl status command to make sure the service is running.

# systemctl enable nfs.service
# systemctl start nfs.service

After modifying nfs configuration files, give the second command again, replacing start with restart to cause nfs to reread those files.

Notes

Troubleshooting

See page 819 for a list of error messages and troubleshooting tips.

SELinux

When SELinux is set to use a targeted policy, NFS is protected by SELinux. You can disable this protection if necessary. For more information refer to “Setting the Targeted Policy with system-config-selinux” on page 475.

Firewall

When NFSv4 is using AUTH_SYS authentication, as it does by default, it uses port 2049. When NFS is using rpcbind to assign a port, which NFSv4 does not do by default, it uses port 111. If the NFS server system is running a firewall or is behind a firewall, you must open one or both of these ports. Give the following commands to open the ports each time the system boots (permanently) and on the running system; see page 906 for information on firewall-cmd.

# firewall-cmd --add-port=2049/tcp
# firewall-cmd --permanent --add-port=2049/tcp
# firewall-cmd --add-port=2049/udp
# firewall-cmd --permanent --add-port=2049/udp
# firewall-cmd --add-port=111/tcp # not usually needed
# firewall-cmd --permanent --add-port=111/tcp # not usually needed
# firewall-cmd --add-port=111/udp # not usually needed
# firewall-cmd --permanent --add-port=111/udp # not usually needed

Security

NFSv3 (and not NFSv4) uses TCP wrappers to control client access to the server. As explained on page 485, you can set up /etc/hosts.allow and /etc/hosts.deny files to specify which clients can contact rpc.mountd on the server and thereby use NFSv3. The name of the daemon to use in these files is mountd.

JumpStart II: Configuring an NFS Server Using system-config-nfs (Fedora)

Open the NFS Server Configuration window (Figure 22-2) by giving the command system-config-nfs from an Enter a Command window (ALT-F2) or a terminal emulator. From this window you can generate an /etc/exports file, which is almost all there is to setting up an NFS server. If the system is running a firewall, see “Firewall” in the preceding section. The system-config-nfs utility allows you to specify which directory hierarchies you want to share and how they are shared using NFS. Each exported hierarchy is called a share.

Figure 22-2 NFS Server Configuration window

To add a share, click Add on the toolbar. To modify a share, highlight the share and click Properties on the toolbar. Clicking Add displays the Add NFS Share window; clicking Properties displays the Edit NFS Share window. These windows are identical except for their titles.

The Add/Edit NFS Share window has three tabs: Basic, General Options, and User Access. On the Basic tab (Figure 22-3) you can specify the pathname of the root of the shared directory hierarchy, the names or IP addresses of the systems (clients) the hierarchy will be shared with, and whether users from the specified systems will be able to write to the shared files.

Figure 22-3 Edit NFS Share window

The selections in the other two tabs correspond to options you can specify in the /etc/exports file. Following is a list of the check box descriptions in these tabs and the option each corresponds to:

General Options tab

Allow connections from ports 1024 and higher: insecure (page 816)

Allow insecure file locking: no_auth_nlm or insecure_locks (page 815)

Disable subtree checking: no_subtree_check (page 816)

Sync write operations on request: sync (page 816)

Force sync of write operations immediately: no_wdelay (page 816)

Hide filesystems beneath: nohide (page 816)

Export only if mounted: mountpoint (page 816)

User Access tab

Treat remote root user as local root: no_root_squash (page 817)

Treat all client users as anonymous users: all_squash (page 817)

Local user ID for anonymous users: anonuid (page 818)

Local group ID for anonymous users: anongid (page 818)

After making the changes you want, click OK to close the Add/Edit NFS Share window and click OK again to close the NFS Server Configuration window. There is no need to restart any daemons.

Manually Exporting a Directory Hierarchy

Exporting a directory hierarchy makes the directory hierarchy available for mounting by designated systems via a network. “Exported” does not mean “mounted”: When a directory hierarchy is exported, it is placed in the list of directory hierarchies that can be mounted by other systems. An exported directory hierarchy might be mounted (or not) at any given time.