System Administration Guide

Mounting and Unmounting

File systems can be attached to the hierarchy of directories available on a system. This process is called mounting. A mounted file system is attached to the system directory tree at the specified mount point (a directory to which the mounted file system is attached), and becomes available to the system. The root (/) file system is always mounted. Any other file system can be connected or disconnected from the root (/) file system.

You need to determine:

To mount a file system you need:

As a general rule, local disk slices should always be included in the /etc/vfstab file. Any software from servers, such as OpenWindows software or man pages, and home directories from a server can be either included in the /etc/vfstab file or automatically mounted with the automount command, depending on the policy at your site.

When you mount a file system, any files or directories in the mount point directory are unavailable as long as the file system is mounted. These files are not permanently affected by the mounting process, and become available again when the file system is unmounted. However, mount directories are usually empty, because you usually do not want to obscure existing files.

Figure 26-2 shows the root (/) file system with subdirectories sbin, etc, and home:

Figure 26-2 A File System

Graphic

To attach a user's home directory to the empty /export/home directory mount point, first create a directory for the new user. For a user named ignatz, create a directory in /export/home named ignatz, giving it the appropriate permissions and ownership. Then mount the file system. When the ignatz file system is mounted, all of the files and directories in /export/home/ignatz are available, as shown in Figure 26-3. You can also create other user directories in the /export/home directory and use those directories as mount points for other user file systems. See Chapter 28, Mounting and Unmounting File Systems (Tasks)for information on how to perform these tasks.

Figure 26-3 Mounting a Home Directory File System

Graphic


Note -

This example illustrates the concept of mounting. Because /home is, by default, an AutoFS mount point directory, home directory files would be mounted by AutoFS rather than the mount command.


Whenever you mount or unmount a file system, the /etc/mnttab (mount table) file is modified with the list of currently mounted file systems. You can display the contents of the mount table using the cat or more commands, but you cannot edit it as you would the /etc/vfstab file. Here is an example of a mount table file:


$ more /etc/mnttab
/dev/dsk/c0t3d0s0    /       ufs     rw,suid,dev=800018,largefiles 863804345
/dev/dsk/c0t3d0s6    /usr    ufs     rw,suid,dev=80001e,largefiles 863804345
/proc   /proc   proc    rw,suid,dev=2900000     863804345
fd      /dev/fd fd      rw,suid,dev=29c0000     863804345
/dev/dsk/c0t3d0s3   /export ufs     suid,rw,largefiles,dev=80001b  863804347
/dev/dsk/c0t3d0s7   /export/home ufs suid,rw,largefiles,dev=80001f 863804348
/dev/dsk/c0t3d0s4   /export/swap ufs suid,rw,largefiles,dev=80001c 863804348
/dev/dsk/c0t3d0s5   /opt  ufs   suid,rw,largefiles,dev=80001d  863804347
swap    /tmp    tmpfs   dev=2a80000     863804347
$

Unmounting a file system removes it from the file system mount point, and deletes the entry from the /etc/mnttab file. Some file system administration tasks cannot be performed on mounted file systems. You should unmount a file system when:

It is a good idea to unmount a file system before doing a complete backup of it. See Chapter 33, Backing Up and Restoring File Systems (Overview) for more information about doing backups.


Note -

File systems are automatically unmounted as part of the system shutdown procedure.


The Virtual File System Table

The default file system configuration table (the /etc/vfstab file) depends on the selections you make when installing system software. You should edit the /etc/vfstab file for each system to automatically mount local UFS file systems, essential NFS file systems, and any other appropriate file systems.

The following is an example of the /etc/vfstab file. The file system table is an ASCII file. Comment lines begin with #. This example shows an /etc/vfstab file for a system with two disks and two NFS file systems mounted.


$ more /etc/vfstab
#device         device          mount           FS      fsck   mount  mount
#to mount       to fsck         point           type    pass   at boot options
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 /          ufs     1       no      -
/proc           -               /proc           proc    -       no      -
/dev/dsk/c0t0d0s1 -                -            swap    -       no      -
swap            -               /tmp            tmpfs   -       yes     -
/dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr       ufs     2       no      -
/dev/dsk/c0t3d0s7 /dev/rdsk/c0t3d0s7 /files7    ufs     2       no      -
cheers:/export/svr4/man.ja5  -  /usr/man        nfs     -       yes     hard
cheers:/export/svr4/openwinV3.ja4 -     /usr/openwin    nfs     -       yes
    hard
$

Note that, for root (/) and /usr, the mount at boot field value is specified as no because these file systems are mounted as part of the boot sequence before the mountall command is run. If the automount field value is specified as yes, the mountall program redundantly (and unnecessarily) tries to mount these already mounted file systems. See Chapter 5, Shutting Down and Booting a System (Overview) for a description of the booting procedure.

See Chapter 28, Mounting and Unmounting File Systems (Tasks) for descriptions of each of the /etc/vfstab fields and information on how to edit and use the file.

Automounting Directories

You can mount file systems shared through NFS by using a method called automounting. Running in the background, the AutoFS program mounts and unmounts remote directories as they are needed. Whenever a user on a client system running AutoFS accesses a remote file or directory available through AutoFS, it mounts the file system on the user's system. The remote file system remains mounted as long as the user remains in the directory and is using a file. If the remote file system is not accessed for a certain period of time, it is automatically unmounted. AutoFS mounts and unmounts file systems as required without any intervention on the part of the user other than changing into or out of a directory.

You can mount some file hierarchies with AutoFS, and others using the /etc/vfstab file and the mount command. A diskless machine must have entries for root (/), /usr, and /usr/kvm in the /etc/vfstab file. Because shared file systems should always remain available, do not use AutoFS to mount /usr/share.

AutoFS works with the file systems specified in maps. These maps can be maintained as NIS, NIS+, or local /etc files.

The AutoFS maps can specify several remote locations for a particular file. This way, if one of the servers is down, AutoFS can try to mount from another machine. You can specify which servers are preferred for each resource in the maps by assigning each server a weighting factor.

AutoFS starts automatically when a system enters run level 3. You can also start it from a command line. See the NFS Administration Guide for complete information on how to set up and administer AutoFS.

By default, the Solaris system software automounts /home.

Sharing Files From a Server

NFS is a distributed file system that can be used to "tie together" computers that are running different operating systems. For example, systems running DOS can share files with systems running UNIX.

NFS makes the actual physical location of the file system irrelevant to the user. You can use NFS to allow users to see all the relevant files, regardless of location. Instead of placing copies of commonly used files on every system, NFS allows you to place one copy on one system's disk and let all other systems access it across the network. Under NFS, remote file systems are virtually indistinguishable from local ones.

A system becomes an NFS server if it has file systems to share or export over the network. A server keeps a list of currently exported file systems and their access restrictions (such as read/write or read-only).

You may want to share resources, such as files, directories, or devices from one system on the network (typically, a server) with other systems. For example, you might want to share third-party applications or source files with users on other systems.

When you share a resource, you make it available for mounting by remote systems.

You can share a resource in these ways:

The default /etc/dfs/dfstab file shows you the syntax and an example of entries:


$ more /etc/dfs/dfstab
#   Place share(1M) commands here for automatic execution
#   on entering init state 3.
#
#   Issue the command '/etc/init.d/nfs.server start' to run the NFS
#   daemon processes and the share commands, after adding the
#   very first entry to this file.
#
#   share [-F fstype] [ -o options] [-d ""]  [resource]
#   .e.g,
#   share  -F nfs  -o rw=engineering  -d "home dirs"  /export/home2
share -F nfs /var/mail
$

Add one entry to the /etc/dfs/dfstab file for each resource that you want to have shared automatically. Each entry must be on a separate line, using this syntax:


share [-F nfs] [-o specific-options] [-d "description"] pathname

Table 26-4 describes these variables.

Table 26-4 Variables for /etc/dfstab Entry

Option 

Description 

-F nfs

Indicates that the file system type is NFS. If you have only one distributed file system package installed, nfs is the default, and you can omit the -F option.

-o specific-options

Regulates how the resource is shared. Specific options, separated by commas, that can follow the -o flag include:

rw - Shares pathname read/write to all clients (by default), except those that are specified under ro=.

ro - Shares pathname read-only to all clients, except those that are specified under rw=.

ro=client[:client] - Shares pathname read-only to the listed client machines or netgroup names (overriding rw).

rw=client[:client] - Shares pathname read/write to the listed client machines or netgroup names (overriding ro).

anon=uid - Lets you specify a different UID for ``anonymous'' users--users whose UID is 0, the UID of root on Solaris systems--when accessing pathname. By default, anonymous users are mapped to user nobody, which has the UID UID_NOBODY. User nobody has ordinary user privileges, not root privileges.

root=host[:host] - Lets a user from host, whose UID is 0, access pathname as root; root users from all other hosts become anon. If this option is not specified, no user from any host is granted access to pathname as root.

secure - Shares a resource with additional user authentication required (See NFS Administration Guide for more information).

kerberos - Shares a resource with Kerberos authentication. (See "Administering Kerberos Version 4 Authentication" for more information.)

-d description

Is a comment that describes the resource to be shared. If you use the -d option, the description is stored in the sharetab file. However, clients do not see the description displayed when they use the dfshares command to list the resources shared on that system.

pathname

Is the full name of the resource to be shared, starting at root (/).

You cannot specify both rw and ro without arguments, and you cannot specify the same client in the rw= list and the ro= list. If no read/write option is specified, the default is read/write for all clients.


Caution - Caution -

Granting root access to other hosts has far-reaching security implications; use the root= option with extreme caution.


See Chapter 28, Mounting and Unmounting File Systems (Tasks) for information on how to share files and file systems. See the NFS Administration Guide for a complete description of NFS.


Note -

Arguments that accept a client or host list (ro=, rw=, and root=) are guaranteed to work over UDP, but may not work over other transport providers.


Under NFS, a server shares resources it owns so clients can mount them. However, a user who becomes root as a client is denied access as root to mounted remote resources. When a user logged in as root on one host requests access to a remote file shared through NFS, the user's ID is changed from 0 to the user ID of the user name nobody. The access rights of user nobody are the same as those given to the public for a particular file. For example, if the public has only execute permission for a file, then user nobody can execute only that file.