| Now that we have a set of resources that the server has shared out, how do we make use of them on the client? Fortunately, this is relatively easy to do because the standard mount command is used to provide access to them. We don't even need to start any daemons ourselves since the ones we need (statd and lockd) are started as part of the normal boot process. Let's run through the commands "manually" the first time, using lithium as our example client. Once we are happy with everything, we'll make the necessary changes to mount the filesystem automatically at every reboot. First let's check that lithium can see the server: lithium# ping helium helium is alive lithium# Good. Helium is responding, so we'll do a quick check to see what resources are available on it. We can use the DFS commands again to do this: lithium# dfshares helium RESOURCE SERVER ACCESS TRANSPORT helium:/data/remote_files helium - - lithium# Now we'll create a directory on the client to mount the server's resources on: lithium# mkdir -p /data/remote_files lithium# Finally we can mount the resource. We mentioned above that the standard mount command is used; only the syntax is slightly differentwe commonly refer to the device as "hostname:resource," as shown below: lithium# mount -F nfs helium:/data/remote_files /data/remote_files lithium# Lots of other options can be used at mount time to control the way NFS functions. We'll cover some of these later in the chapter. The process we described in "Client-Server Communication" on page 431 has now started. This means that the filehandle has been returned to the client's mount process and the relevant files on the client and server have been updated to show that the mount has taken place. Let's look at them to see the changes. Here's the client's /etc/mnttab first: lithium# cat /etc/mnttab helium:/data/remote_files /data/remote_files nfs rw,dev=2d40002 1003587797 lithium# Meanwhile, the server's /etc/rmtab now contains the following entry to show that lithium has the device mounted: helium# cat /etc/rmtab lithium:/data/remote_files helium# Again, we can use one of the DFS commands, dfmounts, to confirm that helium is aware we have its resource: lithium# dfmounts helium RESOURCE SERVER PATHNAME CLIENTS - helium /data/remote_files lithium lithium# All of this means that we should be able to see that the device has been mounted: lithium# df -k Filesystem kbytes used avail capacity Mounted on <lines removed for clarity> helium:/data/remote_files 504305 443210 53626 93% /data/remote_files lithium# Lastly, we can add the entry to /etc/vfstab to force the mount to occur automatically at boot-time. For now, we'll just use a basic entry without any options (we'll add these later in the chapter). After we have added this line, the file will look like the one shown below: lithium# cat /etc/vfstab # #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # <lines remove for clarity> helium - /data/remote_files /data/remote_files nfs - yes bg lithium# This states that we wish to mount helium's resource, /data/remote_files, and that it's an NFS-based filesystem. We don't need to fsck it, as this will be carried out on its local machine. We do want it mounted at boot-time, but we don't need to mount it with any special options. We use the mount option "bg," which will cause the mount to take place in the background so that if, for any reason, helium were not available when lithium rebooted, no part of the boot would be blocked. The default option is to mount the filesystem in the foreground and if the remote server is not available the boot of the local server would hang until the request timed out (around three hours later). It's interesting to see the options the resource has actually been mounted with. We can use a variation of the mount command to do this: lithium# mount -p <lines removed for clarity> helium:/data/remote_files - /data/remote_files nfs - yes rw lithium# The output shows the resource has been mounted in read-write mode. We can also see that it is formatted in the same way as the entries in /etc/vfstab, so as well as providing us with information about the mounted devices, it also allows us to easily add the correct contents to the file if we wish. | 
