![[Return to Library]](BOOKSHLF.GIF)
![[Contents]](TOC.GIF)
![[Previous Chapter]](REW.GIF)
![[Next Section]](NEXT.GIF)
![[Next Chapter]](FF.GIF)
![[Index]](INDEX.GIF)
![[Help]](HELP.GIF)
The Network File System (NFS) is a facility for sharing files in a heterogeneous environment. This chapter describes describes the NFS environment, how to plan for NFS, how to configure your system for NFS, and how to manage NFS servers and clients, including how to export and import file systems.
For introductory information on NFS, see nfs_intro(7).
In the NFS environment, systems can have the following roles:
Your system can be set up as an NFS server, an NFS client, or both.
![[Previous Section]](PREV.GIF)
If your network is running NIS or Berkeley Internet Name Domain (BIND) to distribute host information, you do not need to list each server that is referenced in a client's /etc/fstab file in the client's local /etc/hosts file. However, the server's host information must be in the NIS or BIND database.
Similarly, if your network is running NIS or BIND to distribute host information and the client information is listed in the hosts database, you do not have to list each client that is referenced in a server's /etc/exports file in the server's local /etc/hosts file.
The automount daemon offers an alternative to mounting remote file systems with the /etc/fstab file, allowing you to mount them on an as-needed basis.
When a user on a system using the automount daemon invokes a command that must access a remotely mounted file or directory, the automount daemon mounts that file system or directory and keeps it mounted for as long as the user needs it. When a specified amount of time elapses (the default is 5 minutes) without the file system or directory being accessed, the automount daemon unmounts it.
You specify the file systems to be mounted in automount maps. These maps may be customized to suit your environment and administered in the following ways:
See Appendix C for information on writing automount maps.
NIS allows you to create and distribute customized maps and, typically, is used to distribute automount maps. Therefore, if NIS is used on your network to distribute automount maps, your system must be an NIS client. When NIS is used to distribute automount maps, the administrator of the NIS master server creates and administers the maps for the NIS domain.
If many clients in an environment remotely mount a file system by specifying it in their /etc/fstab file, that file system is a good candidate for inclusion in a map distributed by NIS. Carefully constructed automount maps can allow client systems to eliminate a large part of their /etc/fstab files. If the location of a file system that is included in a distributed automount map changes, or its server changes, the administrator of automount maps changes the map on the NIS master server. The change is then propagated throughout the domain without users on the client systems having to edit their /etc/fstab files.
See Section 7.3.1 for information on configuring a master NIS server to serve automount maps.
Local automount maps might be useful to you under the following circumstances:
Administering the automount daemon locally is the same as administering it when NIS distributes the maps, except that you, as administrator of your system, create and manage automount maps.
A local auto.master map serves the same function as one distributed in an NIS domain. If a local auto.master is specified, the automount daemon consults it for the location of other maps, their local mount points, and the mount options. You can use an auto.master map that is distributed by NIS, a local auto.master map, both, or neither, if the automount daemon is invoked correctly.
Appendix A contains a worksheet that you can use to record the information that you need to provide to configure NFS. If you are viewing this manual online, you can use the print feature to print a copy of this part of the worksheet.
Figure 8-1 shows Part 7 of the Configuration Worksheet. The following sections explain the information you need to record in Part 7 of the worksheet.
Otherwise, check NO.
In addition, you can start nfsiod daemons from the command line. See nfsiod(8) for information on starting nfsiod daemons from the command line.
Otherwise, check NO.
Note
If you mount your user area from a server, make sure that your UID on the client is the same as your UID on the server. NFS uses your client UID to check against file access permissions on the server. If your UID is different on the client and server, you cannot modify your own NFS mounted files (assuming that you have the permissions on the mounted files set so that only you can modify them). Since the server does the access checking, the only UID allowed to modify the files is the one that the server knows.
Digital recommends that you use the NFS Configuration application of the Common Desktop Environment (CDE) Application Manager for configuring NFS on systems with graphics capabilities. You can configure clients, servers, and designate imported and exported filesystems.
See nfsconfig(8X) for more information on the BIND Configuration Application.
To invoke the NFS Configuration application, log in as root and do the following:
To exit the NFS Configuration application, choose File then Exit.
Note
For systems without graphics capabilities, you can use the nfssetup utility. See nfssetup(8) for more information.
The NFS Configuration application also has an extensive online help system. You can use it instead of the instructions in this section to configure NFS on your system.
To configure an NFS server, do the following:
If you run the PC-NFS daemon, you must export to the client the directories you want to mount on the PC client. Also, you must export the /usr/spool/pcnfs directory to the PC client to enable the client to utilize network printing. For information on exporting directories, see Section 8.4.1.
If your system is also going to be an NFS client, see Section 8.3.2 for information on configuring an NFS client. If your system is to export directories or import directories, go to Section 8.4.1 or Section 8.5.1, respectively.
To configure an NFS client, do the following:
See Section 8.1.2 for information on automount and Appendix C for information on automount maps.
You can later change the automount daemon argument list by using a rcmgr command to set the AUTOMOUNT_ARGS variable.
For more information, see automount(8) and rcmgr(8).
If you want to import directories, go to Section 8.5.1.
This section describes how to perform the following NFS server tasks:
You might have to reconfigure NFS on your system, whether to make a client system a server system or to increase the number of NFS daemons. See Section 8.2 for this information.
Exporting a file system or directory makes it available for client systems on the network to mount remotely. If you want your system to be an NFS server and to export file systems and directories, be aware that your system will be less secure. However, depending on how you export your files, you can minimize the security risks.
To export a file system using the NFS Configuration Application, do the following:
To export a file system or directory, do the following:
/usr/local [1] /usr/staff/doe host3 [2] /usr/staff -ro host7 [3] /usr2 host7 host3 host1 [4] /usr/scratch -rw=host2 [5] /usr/src -rw=host1:host2 host5 host7 [6]
See exports(4) for more information on the /etc/exports file.
#
ps -e | grep daemon_name
If they are running, go to the next step. If they are not running, start them by using the following commands:
#
/sbin/init.d/nfs start
#
/sbin/init.d/nfsmount start
The file system or directory is exported automatically when a mount request is received.
NFS servers use the standard operating system file access protection scheme. This scheme protects files from all users except root. An NFS client sends user and group IDs to the server along with an NFS file access request. The server uses this information to allow or disallow the request.
The /etc/exports file defines an export list for each of the file systems and directories that a client can mount. When creating entries in the /etc/exports file, remember the following:
Halting export of a directory or file system prevents client systems from accessing the particular directory or file system. You can still export other directories or file systems.
To halt the export of a directory or file system, do the following:
#
showmount -e
#
ps -e | grep nfsd
#
kill -9 process_id1 process_id2 ...
By default under NFS, a superuser (root) on a client system does not have superuser privileges on the server and cannot do the following:
For security reasons, you typically should not allow a remote superuser access to your system as superuser unless both the remote host and superuser are trusted. However, in a friendly network environment, you can explicitly allow superuser access over the network.
To allow a superuser on a client access to your server system, edit the /etc/exports file on your server and add the -root=0 option to the entry you want to make available. The -root=0 option maps the remote superuser's identification to UID 0. All future mount requests will be honored with root mapping. By default, this option allows superuser access from any client system on the network. To restrict the superuser access to specific systems, use the -root=host_list option, where host_list is a list of host names. See exports(4) for more information.
By default, NFS servers regard superusers and those users without UNIX authentication (personal computer systems) as anonymous users. This class of users can only access files that are accessible to the world. To prevent anonymous users from accessing file systems or directories, use the -anon=-1 option. If you still want to allow client superusers access to the file systems or directories, specify the -root option in addition to the -anon option. The -root option overrides the -anon option for client superusers only.
A superuser on a client system can assume the identity of any other user on the client system by substituting the UID number. The client superuser could then have the access rights of another user on the server. Therefore, to protect sensitive exported data on the server, make root the owner of the data files and do not export the directory or file system with root mapping. This is useful if you need to export other files in the file system.
The following example shows entries in an /etc/exports file:
/usr/games -root=0 host8 [1] /usr/templates -root=host8 [2]
If the /usr/spool/mail directory is remotely mounted from the server, you might not be able to send mail to superuser (root) on the server. The reason is most systems do not export the /usr/spool/mail directory with the root=0 option. To enable clients to send mail to root, set the root and admin aliases to the login name or names of the system administrators for that system. Then, users can address all mail intended for the administrators of that system as follows:
admin@system
To enable clients to send mail to root, follow these steps:
CN MAILER-DAEMON postmaster
The line should then look as follows:
CN MAILER-DAEMON postmaster admin
This adds the name admin to the class N.
Alternatively, you can run the Mail Configuration application and add admin as a local user. See Chapter 11 for more information.
#
/sbin/init.d/sendmail restart
If you are enabling clients to send mail to root, remember the following:
The following example shows the steps involved in enabling clients to send mail to root.
#
vi /var/adm/sendmail/sendmail.cf
.
.
.
#
vi /var/adm/sendmail/aliases
.
.
.
#
/sbin/init.d/sendmail restart
The following example shows entries in the /var/adm/sendmail/aliases file for the system administrators john, mary, and joe:
admin:john,mary,joe root:admin
Only privileged users can attach to Internet domain source ports known as privileged ports. By default, NFS does not check to see if a client is bound to a privileged port. You might want to activate NFS server port monitoring to be sure that file access requests were generated by the client kernel rather than forged by an application program.
Although this operating system enforces the privileged port convention, some operating systems do not. If hosts running a different operating system are on your network, activating port checking might not improve security, but could prevent those systems from functioning properly as NFS client systems.
To start NFS server port monitoring, enter the following command:
#
/usr/sbin/nfsportmon on
To stop source port monitoring, enter the following command:
#
/usr/sbin/nfsportmon off
Monitoring the NFS load allows you to see the number of NFS requests, both client and server, being executed on the local machine. You should periodically monitor NFS requests to determine whether you need additional NFS daemons.
To monitor NFS requests, use the nfsstat command with the following syntax:
nfsstat -n
See nfsstat(8) for more information on monitoring NFS load.
The following example shows the client and server activity on a local machine:
#
/usr/bin/nfsstat -n
nfs: calls badcalls 69228 0 Server nfs V2: null getattr setattr root lookup readlink read 1 0% 24 0% 0 0% 0 0% 60 0% 0 0% 5 0% wrcache write create remove rename link symlink 0 0% 58030 83% 20 0% 0 0% 0 0% 0 0% 0 0% mkdir rmdir readdir statfs 0 0% 0 0% 0 0% 2 0% Server nfs V3: null getattr setattr lookup access readlink read 0 0% 667 0% 1009 1% 2598 3% 101 0% 200 0% 1408 2% write create mkdir symlink mknod remove rmdir 1280 1% 376 0% 71 0% 200 0% 0 0% 676 0% 70 0% rename link readdir readdir+ fsstat fsinfo pathconf 100 0% 100 0% 468 0% 0 0% 1750 2% 2 0% 0 0% commit 10 0% Client nfs: calls badcalls nclget nclsleep 224664 0 224664 0 Client nfs V2: null getattr setattr root lookup readlink read 0 0% 51328 22% 1069 0% 0 0% 41643 18% 455 0% 28793 12% wrcache write create remove rename link symlink 0 0% 64665 28% 589 0% 1052 0% 352 0% 250 0% 250 0% mkdir rmdir readdir statfs 171 0% 170 0% 2689 1% 1814 0% Client nfs V3: null getattr setattr lookup access readlink read 0 0% 2038 0% 2180 0% 8534 3% 430 0% 450 0% 3136 1% write create mkdir symlink mknod remove rmdir 3158 1% 1048 0% 243 0% 450 0% 1 0% 1848 0% 242 0% rename link readdir readdir+ fsstat fsinfo pathconf 452 0% 350 0% 1240 0% 0 0% 3506 1% 3 0% 0 0% commit 75 0%
Your system can be an NFS client if the following conditions exist:
This section describes how to perform the following NFS client tasks:
You can mount a remote file system or any subdirectory within a remote file system onto a local mount point. While mounted, it is treated as a file system by the local system. The file system or subdirectory must also be entered in the remote system's /etc/exports file.
To mount a remote file system or directory on systems with graphics capabilities, use the NFS Configuration Application as follows:
Note
Place mount points to different servers in separate directory trees. Some directories (such as /usr) in complex production environments might be too large for you to adhere strictly to this recommendation. In such cases, try to minimize the number of mount points to different servers that occur in any given directory.
See nfsconfig(8X) for more information.
To manually mount a remote file system or directory, do the following:
Typically, people create a directory with the same name as the remote host because it is easier to remember where the remotely mounted file systems and directories reside.
mount -t nfs server_name:/filesystem /mount_point
mount -t nfs filesystem@server_name /mount_point
The following example mounts the reference pages from the remote host host2 onto the local directory /mnt:
#
mount -t nfs host2:/usr/ref /mnt
#
/usr/sbin/mount
/dev/ra0a on / (rw) /dev/ra0g on /usr (rw) host2:/usr/ref on /mnt type nfs (rw, hard, intr) host7:/usr on /host7 type nfs (rw, hard, nintr)
Use this step for Digital layered products and third-party layered products that have been created in accordance with Digital guidelines. See Programming Support Tools for information on creating linking scripts for layered products.
To automatically mount a remote file system or directory at startup time, do the following:
/usr@host7 /host7 nfs rw,bg 0 0
The bg option causes remote mount requests to be tried once in the foreground and then retried in the background if the initial mount fails. See Section 8.5.1.4 for a list of the some options. See fstab(4) for information on the /etc/fstab file format.
The files will also be mounted automatically each time the system is rebooted.
Use this step for Digital layered products and third-party layered products that have been created in accordance with Digital guidelines. See Programming Support Tools for information on creating linking scripts for layered products.
Occasionally, a server system will go down or be slow to respond to client NFS requests; when you mount the file system, choose one of the following mount command options to control how NFS operations are to proceed under those conditions:
When you use the interrupt option, intr, with the hard option, you can type an interrupt character and prevent your system from indefinitely attempting to reach an unreachable server system. The intr option is the default with the hard option.
See mount(8) for further information on mount command options.
The automount daemon allows you to automatically mount a remote file system or directory at the time of access. If you are using automount, determine whether you are using local automount maps or NIS-distributed automount maps. See Section 8.1.2 for a description of local and NIS-distributed automount maps.
To use local automount maps, do the following:
Note
If you are modifying an existing auto.master map, you must stop and restart automount in order to read the revised map.
When the automount daemon starts, it uses the local auto.master file to determine the location of other maps, their local mount points, and the mount options.
If the NFS Configuration Application indicates that the automount daemon is already running, do the following:
To use NIS-distributed automount maps, do the following:
All automount maps are served from the NIS master server in the domain. When the automount daemon starts, it uses the master auto.master file to determine the location of other maps, their local mount points, and the mount options.
If the NFS Configuration Application indicates that the automount daemon is already running, do the following:
See automount(8) for information on the automount command and its arguments.
You can specify arguments for the automount daemon from the command line, in a local auto.master map, in an NIS-distributed auto.master map, or some combination of the three. However, it is important to know that the automount daemon reads and carries out its instructions in the following order:
When you invoke the automount daemon without any options, it looks for a distributed NIS map called auto.master. If it finds one, it checks the master map for information about the location of other maps, their local mount points, and the mount options. If it does not find one, and if no local auto.master is specified, the automount daemon exits.
You can pass command arguments to the automount daemon from the NFS Configuration Application, the command line, or from an entry in the /etc/rc.config file in one of the following ways:
#
automount /net -hosts \
/home /etc/auto.home -rw,intr \
/- /etc/auto.direct -ro,intr
/net -hosts /home /etc/auto.home -rw,intr /- /etc/auto.direct -ro,intr
If this NIS auto.master map is distributed, typing automount at the superuser prompt (#) produces the same results as the previous command line.
#
automount -f /etc/auto.master
#
automount -f /etc/auto.master \
/src /etc/auto.src -ro,soft
#
automount -f /etc/auto.master /home -null
#
automount -f /etc/auto.master \
/home /mine/auto.home -rw,intr
See automount(8) for more information on the automount command and its options.
To unmount a remote file system or directory, do the following:
umount {filesystem| directory }
The mounted file systems and directories are displayed.
See umount(8) for more information on umount command options.
The following command unmounts the /mnt local directory, containing the reference pages mounted in Section 8.5.1.2:
#
umount /mnt
The following command unmounts all NFS file systems:
#
umount -A -t nfs
The following command unmounts all file systems exported from host2:
#
umount -h host2