Mounting makes file systems, files, directories, devices, and special files available for use at a particular location. It is the only way a file system is made accessible. The mount command instructs the operating system to attach a file system at a specified directory.
You can mount a file or directory if you have access to the file or directory being mounted and write permission for the mount point. Members of the system group can also perform device mounts (in which devices or file systems are mounted over directories) and the mounts described in the /etc/filesystems file. A user operating with root user authority can mount a file system arbitrarily by naming both the device and the directory on the command line. The /etc/filesystems file is used to define mounts to be automatic at system initialization. The mount command is used to mount after system startup.
A mount point is a directory or file at which a new file system, directory, or file is made accessible. To mount a file system or a directory, the mount point must be a directory; and to mount a file, the mount point must be a file.
Typically, a file system, directory, or file is mounted over an empty mount point, but that is not required. If the file or directory that serves as the mount point contains any data, that data is not accessible while it is mounted over by another file or directory. In effect, the mounted file or directory covers what was previously in that directory. The original directory or file that has been mounted over is accessible again once the mount over it is undone.
When a file system is mounted over a directory, the permissions of the root directory of the mounted file system take precedence over the permissions of the mount point. The one exception involves the .. (dot dot) parent directory entry in the mounted-over directory. In order for the operating system to access the new file system, the mount point parent directory information must be available.
For example, if the current working directory is /home/frank, the command cd .. changes the working directory to /home. If /home/frank directory is the root of a mounted file system, the operating system must find the parent directory information in the /home/frank directory in order for the cd .. command to succeed.
For any command that requires parent directory information in order to succeed, users must have search permission in the mounted-over directory. Failure of the mounted-over directory to grant search permission can have unpredictable results, especially since the mounted-over directory permissions are not visible. A common problem is failure of the pwd command. Without search permission in the mounted-over directory, the pwd command returns this message:
pwd: Permission denied
This problem can be avoided by always setting the permissions of the mounted-over directory to at least 111.
There are two types of mounts, a remote mount and a local mount. Remote mounts are done on a remote system on which data is transmitted over a telecommunication line. Remote file systems, such as Network File System (NFS), require that the files be exported before they can be mounted. Local mounts are mounts done on your local system.
Each file system is associated with a different device (logical volume). Before you can use a file system, it must be connected to the existing directory structure (either the root file system or to another file system that is already connected). The mount command makes this connection.
The same file system, directory, or file can be accessed by multiple paths. For example, if you have one database and several users using this database, it can be useful to have several mounts of the same database. Each mount should have its own name and password for tracking and job-separating purposes. This is accomplished by mounting the same file system on different mount points. For example, you can mount from /home/server/database to the mount point specified as /home/user1, /home/user2, and /home/user3:
/home/server/database /home/user1 /home/server/database /home/user2 /home/server/database /home/user3
A file system, directory, or file can be made available to various users through the use of symbolic links. Symbolic links are created with the ln -s command. Linking multiple users to a central file ensures that all changes to the file are reflected each time a user accesses the file.
Mounts can be set to occur automatically during system initialization. There are two types of automatic mounts. The first type consists of those mounts that are required to boot and run the system. These file systems are explicitly mounted by the boot process. The stanzas of such file systems in the /etc/filesystems file have mount = automatic. The second type of automatic mount is user-controlled. These file systems are mounted by the /etc/rc script when it issues the mount all command. The stanzas of user-controlled automatic mounts have mount = true in /etc/filesystems.
The /etc/filesystems file controls automatic mounts; they are done hierarchically, one mount point at a time. They can also be placed in a specific order that can be changed and rearranged.
The /etc/filesystems file is organized into stanzas, one for each mount. A stanza describes the attributes of the corresponding file system and how it is mounted. The system mounts file systems in the order they appear in the /etc/filesystems file. The following is an example of stanzas within the /etc/filesystems file:
/: dev=/dev/hd4 vol="root" mount=automatic check=false free=true vfs=jfs log=/dev/hd8 type-bootfs /home: dev=/dev/hd1 vfs=jfs log=/dev/hd8 mount=true check=true vol="/home" free=false /usr: /dev=/dev/hd2 vfs=jfs log=/dev/hd8 mount=automatic check=false type=bootfs vol="/usr" free=false
You can edit the /etc/filesystems file to control the order in which mounts occur. If a mount is unsuccessful, any of the following mounts defined in the /etc/filesystems file continue to mount. For example, if the mount of the /home file system is unsuccessful, the mount for the /usr file system continues and be mounted. Mounts can be unsuccessful for reasons such as typographical errors, dependency, or a system problem.
Diskless workstations must have the ability to create and access device-special files on remote machines to have their /dev directories mounted from a server. Because servers cannot distinguish device-special files intended for a client from those intended for the server, a user on the server might be able to access the physical devices of the server using the special files of the client device.
For example, the ownership for a tty is automatically set to the user using the tty. If the user IDs are not the same on both the client and server, a nonprivileged user on the server can access a tty that is being used by a different user on the server.
A user who is privileged on a client can create device-special files to match physical devices on the server and have them not require privilege for access. The user can then use an unprivileged account on the server to access the normally protected devices using the new device-special files.
A similar security problem involves the use of setuid and setgid programs on the client and server. Diskless clients must be able to create and runsetuid and setgid programs on the server for normal operation. Again, the server cannot distinguish between those programs intended for the server and those intended for the client.
In addition, the user IDs and group IDs might not match between the server and client, so users on the server might be able to run programs with capabilities that were not intended for them.
The problem exists because the setuid and setgid programs and device-special files should only be usable on the machine that created them.
The solution is to use security options to the mount command that restrict the ability to use these objects. These options can also be used in stanzas in the /etc/filesystems file.
The nosuid option in the mount command prevents the execution of setuid and setgid programs that are accessed via the resulting mounted file system. This option is used for any file system that is being mounted on a particular host for use only by a different host (for example, exported for diskless clients).
The nodev option in the mount command prevents the opening of devices using device special files that are accessed via the resulting mounted file system. This option is also used for any file system that is being mounted for use only by a different host (for example, exported for diskless clients).
Although the file system of a diskless workstation is mounted from a server /exports directory, to the diskless machine, the file system looks just like the file system on a standalone machine.
The following shows the relationship between server exports, and the diskless workstation mount points:
| Server Exports | Diskless Imports |
|---|---|
| /export/root/HostName | / (root) |
| /export/exec/SPOTName | /usr |
| /export/home/HostName | /home |
| /export/share | /usr/share |
| /export/dump | Used by diskless client as dump space |
| /export/swap | Used by diskless clients as remote paging space. |
For more information about the /export directory, see Understanding the /export Directory.
In general, users on a server do not have any access to the /export directory.
The /export/root directory must be exported with read/write permissions, and the root user on the server must have access. However, you might want to mount this directory with the following options of the mount command:
| nosuid | Prevents a user on the server from running the setuid programs of the client |
| nodev | Prevents a user from accessing the server devices using a device-special file of the client. |
An alternative to mounting the /export/root directory with these options is to avoid giving users running on the server any access to the /export/root directory.
The /export/exec directory is exported with read-only permissions and must provide root access. However, you might want to mount this directory with the following options of the mount command:
| nosuid | Prevents a user on the server from running the setuid programs of the client. If you are exporting the server /usr directory, you cannot use the nousid option. |
| nodev | Prevents a user from accessing the server devices using a device-special file of the client. |
The /export/share directory is exported with read-only permissions and must provide root access. Because this directory generally contains only data (no executables or devices), you do not need to use the mount security options.
There are several ways to mount a user /home directory:
| nosuid | Prevents a user on the server from running the setuid programs of the client. |
| nodev | Prevents a user from accessing the server devices using a device-special file of the client. |
Export the /export/dump/Clienthostname directory with read/write permissions and root access. Users on the server do not have any access to the /export/dump/Clienthostname files.
Export the /export/swap/Clienthostname file with read/write permissions and root access. No security measures are necessary. Users on the server do not have any access to the /export/swap/Clienthostname files.