The showmount Command Mounting Remote Filesystems

The nature and format of the both files is the same. Here is an example on the Solaris 2.x platform that corresponds to the previously presented etcdfsdfstab NFS configuration file. cat etcdfssharetab varmail − nfs rw usrshareman − nfs ro filesexport − nfs rw,root=delft:aegean filesos − nfs ro,anon =0 files1export − nfs rw,root=delft:aegean files2export − nfs rw,root=delft:aegean If we carefully compare the two files, the export configuration file etcdfsdfstab and this export status file etcdfssharetab, we see that all of the specified filesystems are exported except the cdrom filesystem. In this case, the discrepancy is easy to explain: if a CD−ROM disk is not inserted into the CD−ROM drive, the cdrom filesystem cannot be exported at all.

18.2.2 Mounting Remote Filesystems

An exported filesystem cannot be used before it is mounted on the client side; mounting an exported system means to mount and later access a remote filesystem through the network. That is the whole idea of NFS. Technically, mounting a remote filesystem is quite different from mounting a local one; from an administrative standpoint the differences are minor, but from the user standpoint there is no difference at all.

18.2.2.1 The showmount Command

Before we start mounting a remote filesystem, we must decide which NFS server to use, and which filesystems are to be exported and available from the server. Any necessary information about the filesystems to be exported can be obtained with the showmount command and a reference to the corresponding server. For example: showmount −e patsy patsy is the NFS server and it belongs to the same domain export list for patsy: patsy hcprophet,indigo1,indigo2,mvaxgr,rs01ch,rs02ch,rs03ch usrshareman everyone etc gatorchem home gatorchem The export list shows the NFS directories filesystems exported by the server patsy, as well as their properties. In this case the list matches the previously presented export configuration file etcexports. Regardless of what the list looks like, it is up to us to decide how to mount the available remote filesystem. As in the case of local filesystems, there is no a magic formula for this; the decision depends on many other factors. 432 Mounting a remote filesystem means attaching it to the clients UNIX overall hierarchical directory structure. The mounted remote filesystems are integrated into an overall directory tree. The same mount command that mounts local filesystems is used for this purpose. The differences are in the way the remote filesystems are identified, and some specific filesystem properties. We have already described the mount command in great detail. Here, only the issues related to remote filesystems will be discussed. The format of the mount command applicable to remote filesystems is: mount server−name:remote−directory local−directory [−o options] where server−name Identifies an NFS server remote−directory Identifies all or part of a directory exported by that server, and must be an absolute pathname starting with a leading local−directory Identifies the mount−point, the clients directory where the remote−directory will be attached to the clients filesystem. It must be an absolute pathname, local−directory must be created before mount is executed, and it is very common to use server−name for the last level name in the local−directory options One or more options applicable for NFS though some of them are only applicable to NFS such as: bgfg If the first attempt fails, retry in background or foreground retry=n The number of times to retry timeo=n Set the time−out to n tenths of second intr Allows keyboard interrupt softhard Return an error if the server does not respond or continue to retry until the server responds The umount command is used to dismount a mounted remote filesystem. There is no difference in using the umount command for locally or remotely mounted filesystems. Generally speaking, remote filesystems are treated just like any local filesystem. The differences are in the type of the filesystem in this case it is the nfs type, and in some options specific to the filesystem type. Consequently, NFS filesystems could, and should, be mounted automatically during the system startup. This means the necessary information for mounting remote filesystems should be appended in the clients filesystem configuration file usually the file etcfstab, or etcvfstab. An example follows: cat etcfstab | grep nfs ..... hcprophet:hcprophet hcprophet nfs rw,hard,bg,intr 0 0 patsy:patsy patsy nfs rw,hard,bg,intr 0 0 rs01ch:home2gigrs rs nfs rw,hard,bg,intr 0 0 mvaxgr:exportDUB1 mvaxgrdisku2 nfs rw,soft,bg,intr 0 0 mvaxgr:exportDUB2 mvaxgrdisku3 nfs rw,soft,bg,intr 0 0 Please note that only NFS−related entries are presented. The very same names in different columns do have different meanings; for example, the first column patsy:patsy identifies the NFS server patsy and the exported directory patsy, while the second column patsy identifies 433 A corresponding entry in the filesystem status file etcmtab or etcmnttab is automatically created for each successfully mounted remote filesystem, just as it would be for any mounted local filesystem.

18.3 Automounter

The automounter, better known as the automount, is a tool that automatically mounts NFS filesystems when they are referenced, and dismounts them when they are no longer needed. Maintaining remote filesystems that are permanently mounted also keeps processor resources permanently busy, with an unavoidable impact on the systems overall performance. It is a good idea to mount a remote filesystem only when its data are needed; otherwise a remote filesystem remains dismounted and the required processor resources are released for other tasks. The price we must pay for this benefit is additional automount−related administration. Using data for the first time takes slightly longer because the corresponding remote filesystem must be automounted. Once mounted, the remote filesystem remains mounted as long as it is used; after a certain time of inactivity the usual time−out is a few minutes the remote filesystem is automatically dismounted. Another benefit of using the automounter is the fact that there is no longer any need to keep filesystem configuration data the file etcfstab or etcvfstab up to date by hand. The information required for a mounting, including the NFS server, filesystem pathnames on the server, local mount points and mount options, are now part of the automount configuration data, which are usually maintained as NIS maps. In that way, the NIS management can also be implemented on the NFS configuration data, so a single NIS map can be handled and spread through the network to all NFS clients. The automounter was, and is, an integral part of the majority of UNIX flavors. A public domain version called amd is also available; it is kernel independent and can be used on almost any UNIX system. There are many motivations for using the automounter: The filesystem configuration data etcfstab and etcvfstab files on every host becomes much less complex. • The automount maps may be maintained using NIS, thereby streamlining the administration of mount tables for all hosts in the network the same way NIS streamlines other information. • The exposure to the risk of hanging a process when an NFS server crashes is greatly reduced; the automounter dismounts all filesystems that are not in use, removing dependencies on file servers that are not currently referenced by the client. • The automounter can extend the basic NFS mount protocol to find the nearest server for replicated, read−only filesystems; in this case that server will handle the mount requests, reducing the load on the more heavily used network hardware. • An automounter is a daemon usually named automountd that automatically and transparently mounts NFS filesystems as needed. It monitors attempts to access directories that are associated with an automount map, as well as all subdirectories and files beneath these directories. For example, on Solaris 2.x platform: 434