Network File Service (NFS) and the Automounter:

  NFS was designed to address the problem of having filesystems only
  existing on one host.  It is quite simple, and only requires:

    1.  Kernel support of NFS filesystems on the client
    2.  An NFS-aware mount command on the client
    3.  A mountd application on the server
    4.  A nfsd application on the server

  The client computers mount(8) application contacts the mountd on
  the server.  The server's mountd does some access control, and then
  either notifies the client that it has access, or tells it that
  it doesn't.  If the client has access, the filesystem is added
  to clients list of mounted filesystems, and from there, filesystem
  reads and writes are directed through the client computers kernel
  to the servers nfsd.

  About the only place that we will notice the effects of NFS are
  in the structure of the mount command.  When mounting a block
  special device file, we use a command of the form:

    mount /device/file /local/mount/point

  (where /device/file is the block-special device file, and /local/mount/point
  is where the filesystem should be mounted).  With NFS, we will use a
  mount command of the form:

    mount remote-host:/remote/directory /local/directory

  (where remote-host is the fileserver host, /remote/directory is the
  directory on the fileserver host to use, and /local/directory is the
  directory on the client computer to make the filesystem visible under).

  Because NFS takes place in the kernel on the client computer, there is
  little we can do there in terms of administration (until we get to the
  automounter below), but on the server we need to have a way to specify
  which directories to "export" (make available to NFS clients), and a way
  to specify which client machines should be able to use the exported
  directories.  Many systems (including Linux) use the file /etc/exports to
  list these, but it will vary (Solaris uses /etc/dfs/dfstab).

  On a Linux machine, the exports file could look something like:

       /dir1   host(ro)
       /dir2   @netgroup(rw)

  The first line says that the directory /dir1 should be exported only
  to host "host", and it should be exported read-only.  The second line
  says that the directory /dir2 should be exported read-write to all of
  the hosts in the NIS host netgroup "netgroup".

  Automounter:

    One of the most popular uses of NFS is with user home directories.
    Since the number of home directories increases with the number of
    users, any site with a large number of users and a large number of
    machines is going to have an organizational problem.  Each machine
    would have to have a list of all of the available home directories,
    this list would have to be updated whenever the location of a home
    directory was changed (for example if the directory was moved to
    another fileserver for more space).

    A solution to this is the automounter.  There are two main
    implementations: BSD amd, and Sun automount.  BSD amd is (almost
    unpleasantly) over-configurable.  It can be used for a superset of
    the tasks that the Sun Automounter can be used for.  It has also
    had a history of security problems.  There is nothing really
    superior about one implementation over the other when it comes to
    NFS mounting directories.  We recommend the Sun automount.  Linux
    has a Sun automount clone called automount.

    With both implementation, the automounter process runs on a directory
    (called an automount point).  When a user requests a subdirectory (by
    trying to cd into it), the automounter mounts the directory "just in
    time".  Periodically, it tries to unmount the directory, and it will
    succeed whenever no one is using it.

    However, this still doesn't provide any help to the system administrator
    --- the directories and remote directories to mount still need to
    be available to every host.  The big win with amd and Sun automount is
    that this list can be provided by NIS.