We have already used the commands to attach and detach a filesystem from the filesystem, mount and umount. In this section we will learn more about these commands, and about the many options of mount.

Mounting a filesystem attaches it into the Unix filesystem. The attachment point (or mount point) can be any directory. Because the process of attaching the new filesystem to a directory overlays the current contents of that directory with the newly attached filesytem, this attachment point is usually an empty directory. Furthermore, to avoid any issues with ordering the mounts, the empty directory is usually part of the root partition (/), since the root partition is guaranteed to be the first partition mounted. 

The list of things currently mounted is kept in the file /etc/mtab. The mount command (without any options) can be used by any user to output the contents of this file. (See the note on the mtab at the end of this section.) Usually, mounting and unmounting filesystems is a privileged operation, but there are some exceptions to this.

Note: the mount (and umount) command historically was placed in the non-standard directory /etc. On systems that observe this tradition the full path to the command must be used, since this directory is seldom in your PATH.

To attach a filesystem, mount must indicate the filesystem to attach

mount [ -t type ] [ -o mountoptions ] { device | -L label | -U uuid | dir } [ dir ]

If the filesystem is in the fstab, mount will fill in any missing options from it. In this case, it is sufficient to indicate the device, the label or the mount point:

If the filesystem has not been entered in the fstab, you must specify the type, device (or label or uuid) and mount point:

mount has a handful of standard Unix-style options that tell it what to mount. Besides -t type, these are the most important ones:

• -a  automount all filesystems indicated as automount (auto) in the fstab. This can be combined with -t type to automount only filesystems of type type
• -L label mount the filesystem with this label. (The label can be used instead of the device file.)
• -U UUID mount the filesystem with this uuid. (See the last paragraph in this section for how to find filesystems' labels and UUIDs.)
  

Besides these standard Unix-style options, mount accepts a large number of options that modify how the filesystem is mounted. Some of these options are filesystem-specific. Each of these options is identified by a word. A comma-separated list of these option words, which we will refer to as mountoptions, is created and given to mount in a single Unix-style option -o mountoptions.  Each of these 'mount options' has a default setting, which is encapsulated in a set named defaults. The options indicated in mountoptions, if any, are deviations from the settings in defaults. 

Example:   -o user,sync

This tells mount to mount the filesystem with the two filesystem-specific 'mount options' user and sync. These two options counter two of the 'mount options' that are part of the defaults set: nouser and async.

Here are the 'mount options' that are most commonly used in -o mountoptions

• defaults  this is the defaults set. It is used in the fstab only. It contains at least

• ro / rw  mount the filesystem read-only or read-write (rw is the default)
• remount  the filesystem is already mounted. Change its mount parameters as indicated here and leave it mounted. You cannot change the mount point with remount, only the options. remount is used most frequently to toggle between the ro and rw option of a filesystem, for a purpose we will see later.
• auto / noauto (when used in the fstab) indicates whether filesystem should be mounted automatically when the system is started (in response to mount -a).
• exec / noexec  whether to allow the execution of programs on this filesystem. It has been suggested that this option be turned on for public temporary filesystems (/tmp). This is discussed in a later section.
  
• suid / nosuid  whether to allow the set-user-id bit to have effect on programs executed from this filesystem. Again, this is a good idea to turn on for public temporary filesystems (/tmp). This is discussed in a later section.
• dev / nodev  whether device files should be honored on this filesystem. The nodev option should be on for all filesystems except the root (and perhaps /boot) filesystem.
  
• acl / noacl  (ext filesystems only) whether access-control-lists should be effective on this filesystem. Whether acl is the default is discussed in a later section.
• user  whether a non-privileged user can mount this filesystem. Once mounted, only that user can umount it.
• users  whether a non-privileged user can mount and umount this filesystem. Any user can mount it, and any user can unmount it.
• loop  mount using the loop device. This is discussed in a later section.
• sb=n  (ext filesystems only) ignore the default superblock, instead using the superblock at block n. Warning:  The  block number  here  is in 1k  blocks, so, depending on your filesystem's blocksize, you may have to translate from the block numbers of the duplicate superblocks output by mkfs . (To find out where the spare superblocks are on your filesystem, as well as the blocksize the filesystem was created with, use mke2fs -n.)
• barrier/nobarrier (ext3/ext4/xfs only) erect write barriers. This is the default on ext4 but not on ext3. The default setting on xfs is not specified in the documentation. barrier is also indicated by barrier=1 and nobarrier is indicated by barrier=0. (It is also unclear if barrier=0 and barrier are synonyms on all filesystems - one or the other may be required. See the mount man page for your filesystem.)
• bind/rbind can be used to remount all or part of a mounted filesystem in a second location. This is discussed briefly in a later section.

mke2fs has a base set of options that it implements on each filesystem. These are described in the base_features  and in the per-filesystem features directives in /etc/mke2fs.conf. Base options can be overridden with your own set by use of the -O (capital o) option followed by your own base options set in the mke2fs command.

For a full set of 'mount options', see the mount(8) man page. It is important to know that this is where these options are documented, since they are the same options used in the /etc/fstab and are not documented in the fstab(5) man page.

Most mount commands are very simple, as in  mount -t ext3 /dev/hda3 /xxx .  In most cases, like this one, the defaults set of 'mount options' is sufficient; however, there are very important situations where special 'mount options' are needed. 

Changing the ro/rw option on a filesystem

When the system has been booted to single-user mode, it may be necessary to change the rw option on the root filesystem to ro in order to check it by hand. (The root filesystem may be checked in single-user mode if it is mounted read-only. I know this seems strange: having the filesystem mounted read-only means that the checking program can alter it without losing data.)

mount -o remount,ro root-device

Another situation where the use of ro/rw is needed occurs during a rescue operation, where you have booted from a rescue CD and the rescue system has found your filesystem(s) on the disk and mounted them read-only. If you need to modify data on the disk you must remount the filesystem read-writefirst:

mount -o remount,rw device

Mounting an image

An image file (such as an ISO image) is a filesystem contained in a file. You can mount the image just like a filesystem using the loop device. If you have an empty directory /mnt/iso for this purpose, for example,

The output of the mount command then shows the line

Unmounting a filesystem

A filesystem cannot be unmounted if a process is accessing a file on it. (In the vernacular, the filesystem is busy). If this occurs, you will get the following message from umount

# umount /spare
umount: /spare: device is busy
umount: /spare: device is busy
#

Prior to unmounting the filesystem, you must clear any processes that are accessing it. The ids of processes using the filesystem and what they are using it for can be obtained by using either of the commands fuser (traditional) or lsof.  fuser has options to allow you to kill the processes it finds, but it is less dangerous to investigate what the processes are and kill them yourself by hand. Note that both lsof and fuser are general-purpose commands. They can be used to investigate what processes are accessing any filesystem component.

lsof is recursive by default. If you give it the mount point of the filesystem in question, it will output all processes who have open files anywhere beneath the directory. 

fuser, by default, only applies to the paths listed. If you give it the -m option, it outputs the users of the filesystem that the paths are on. In addition, the -v (verbose) option is helpful with fuser, as its default output is rather terse:

The most interesting item in the output of fuser and lsof besides the process id is the type of access. This is indicated as FD in the lsof output, and as ACCESS in the fuser output. In this field, a c (for fuser) or cwd (for lsof) indicates a process is using the directory as its current working directory. The other access shown in the examples above (indicated as f in fuser, and as 1w for lsof) indicates that a process has the file open. Here the specific file path is indicated by lsof.

fuser is the traditional tool for investigating what processes are using pieces of data, but lsof can do the same thing, and it is more versatile. These programs are more useful for more than preparing to unmount a filesystem. Either fuser or lsof could be used, for example, to determine whether anyone is accessing a file before updating it.

If you want to discover all the open files in (beneath) a directory that is not a mount-point, the correct method is

The documentation warns that this can be extremely resource-intensive for large directory trees and it should be used with caution.

Removable Devices

Recent efforts to automate the mounting of removable filesystems on linux have resulted in a daemon process that responds to the insertion of new devices. Probably the original motivation for this was to respond to USB events, but this technique now governs all removable devices. The facility that provides this service is called HAL. (This may be a reference to the movie 2001: A space odessy, but the acronym stands for Hardware Abstraction Layer.) HAL's daemon is hald (but, annoyingly, the corresponding subsystem is haldaemon.) If hald is running, the discovery of a removable device inserted results in automatically:

• updating the filesystem table fstab (on some versions of linux, but not in RedHat)
• creating a mount point beneath a special directory, such as  /media
• mounting the device.

The discovery of the new device might occur at boot in the case of fixed removable devices such as a cd or dvd, or it might occur while the system is running in response to a new USB event. On Redhat, where the fstab is not updated to reflect the removable, the only way to determine the device the removable uses is by the output of mount. See the note on this at the end of the File System Table section.

Note: on some systems, the insertion of a CD or other removable device while logged in at the console does not trigger an automatic mount. In this case, the device may be statically entered into the fstab (as discussed in the next section), rather than under the control of hald. If this occurs, you have two choices: issue the mount command yourself as root (or try mount -a), or simply log off and back on to the console to try to trigger an automatic mount.

The mtab

mount maintains a file of currently mounted filesystems in /etc/mtab. This file is simply output when mount is used without options. When a mount operation occurs, the file is updated. You should know this in case the root filesystem is mounted read-only, in which case the mtab reflects the state of the filesystems the last time / was writable! In this case  you should examine the true dynamic picture of mounted filesystems, /proc/mounts. This situation often occurs when booting to single-user mode due to a fstab problem or to circumvent a forgotten root password.

Labels, UUIDs, and device files

You can identify a filesystem several ways - by its device file, its label, or its UUID. For temporary mounts, any of these identifiers is fine. For automated mounts, such as in the file system table, the device file should not be used, since devices are assigned dynamically at boot. If hardware is rearranged, the device file assignments can change!

Finding the label or UUID associated with a filesystem can be accomplished easily - when the system is booted, the devices are scanned and a record is made of the UUID, and the label, if one has been assigned. These UUIDs and labels are shown in the directories /dev/disk/by-uuid and /dev/disk/by-label as symlinks to the assigned device files. You can also get a listing using the command blkid.