Managing NFS and NIS, 2nd Edition - Mike Eisler [62]
The "raw device name" field that is checked with fsck, is replaced with a -.
The filesystem type is nfs, not ufs as for local filesystems.
The fsck pass is set to -.
The options field can contain a variety of NFS-specific mount options, covered in the Section 6.3.2.
Some typical vfstab entries for NFS filesystems are:
ono:/export/ono
-
/hosts/ono
nfs
-
yes
rw,bg,hard
onaga:/export/onaga
-
/hosts/onaga
nfs
-
yes
rw,bg,hard
wahoo:/var/mail
-
/var/mail
nfs
-
yes
rw,bg,hard
The yes in theabove entries says to mount the filesystems whenever the system boots up. This field can be yes or no, and has the same effect for NFS and non-NFS filesystems.
Of course, each vendor is free to vary the server and filesystem name syntax, and your manual set should provide the best sample vfstab entries.
Using mount
While entries in the vfstab file are useful for creating a long-lived NFS environment, sometimes you need to mount a filesystem right away or mount it temporarily while you copy files from it. The mount command allows you to perform an NFS filesystem mount that remains active until you explicitly unmount the filesystem using umount, or until the client is rebooted.
As an example of using mount, consider building and testing a new /usr/local directory. On an NFS client, you already have the "old" /usr/local, either on a local or NFS-mounted filesystem. Let's say you have built a new version of /usr/local on the NFS server wahoo and want to test it on this NFS client. Mount the new filesystem on top of the existing /usr/local:
# mount wahoo:/usr/local /usr/local
Anything in the old /usr/local is hidden by the new mount point, so you can debug your new /usr/local as if it were mounted at boot time.
From the command line, mount uses a server name and filesystem name syntax similar to that of the vfstab file. The mount command assumes that the type is nfs if a hostname appears in the device specification. The server filesystem name must be an absolute pathname (usually starting with a leading /), but it need not exactly match the name of a filesystem exported from the server. Barring the use of the nosub option on the server (see Section 6.2.2 earlier in this chapter), the only restriction on server filesystem names is that they must contain a valid, exported server filesystem name as a prefix. This means that you can mount a subdirectory of an exported filesystem, as long as you specify the entire pathname to the subdirectory in either the vfstab file or on the mount command line. Note that the rw and hard suboptions are redundant since they are the defaults (in Solaris at least). This book often specifies them in examples to make it clear what semantics will be.
For example, to mount a particular home directory from /export/home of server ono, you do not have to mount the entire filesystem. Picking up only the subdirectory that's needed may make the local filesystem hierarchy simpler and less cluttered. To mount a subdirectory of a server's exported filesystem, just specify the pathname to that directory in the vfstab file:
ono:/export/home/stern - /users/stern nfs - yes rw,bg,hard
Even though server ono exports all of /export/home, you can choose to handle some smaller portion of the entire filesystem.
Mount options
NFS mount options are as varied as the vendors themselves. There are a few well-known and widely supported options, and others that are added to support additional NFS features or to integrate secure remote procedure call systems. As with everything else that is vendor-specific, your system's manual set provides a complete list of supported mount options. Check the manual pages for mount(1M), mount_nfs(1M), and vfstab(4).
* * *
Tip
For the most part, the default set of mount options will serve you fine. However, pay particular attention to the nosuid suboption, which is described in Chapter 12. The nosuid suboption is not the default