All files accessible in a Unix system are arranged in one big
tree, the file hierarchy, rooted at /. These files can be spread
out over several devices. The mount command serves to attach the
filesystem found on some device to the big file tree. Conversely,
the umount(8) command will detach it again. The filesystem is
used to control how data is stored on the device or provided in a
virtual way by network or other services.
The standard form of the mount command is:
mount -t type device dir
This tells the kernel to attach the filesystem found on device
(which is of type type) at the directory dir. The option -t type
is optional. The mount command is usually able to detect a
filesystem. The root permissions are necessary to mount a
filesystem by default. See section "Non-superuser mounts" below
for more details. The previous contents (if any) and owner and
mode of dir become invisible, and as long as this filesystem
remains mounted, the pathname dir refers to the root of the
filesystem on device.
If only the directory or the device is given, for example:
mount /dir
then mount looks for a mountpoint (and if not found then for a
device) in the /etc/fstab file. It's possible to use the --target
or --source options to avoid ambiguous interpretation of the
given argument. For example:
mount --target /mountpoint
The same filesystem may be mounted more than once, and in some
cases (e.g., network filesystems) the same filesystem may be
mounted on the same mountpoint multiple times. The mount command
does not implement any policy to control this behavior. All
behavior is controlled by the kernel and it is usually specific
to the filesystem driver. The exception is --all, in this case
already mounted filesystems are ignored (see --all below for more
details).
Listing the mounts
The listing mode is maintained for backward compatibility only.
For more robust and customizable output use findmnt(8),
especially in your scripts. Note that control characters in the
mountpoint name are replaced with '?'.
The following command lists all mounted filesystems (of type
type):
mount [-l] [-t type]
The option -l adds labels to this listing. See below.
Indicating the device and filesystem
Most devices are indicated by a filename (of a block special
device), like /dev/sda1, but there are other possibilities. For
example, in the case of an NFS mount, device may look like
knuth.cwi.nl:/dir.
The device names of disk partitions are unstable; hardware
reconfiguration, and adding or removing a device can cause
changes in names. This is the reason why it's strongly
recommended to use filesystem or partition identifiers like UUID
or LABEL. Currently supported identifiers (tags):
LABEL=label
Human readable filesystem identifier. See also -L.
UUID=uuid
Filesystem universally unique identifier. The format of the
UUID is usually a series of hex digits separated by hyphens.
See also -U.
Note that mount uses UUIDs as strings. The UUIDs from the
command line or from fstab(5) are not converted to internal
binary representation. The string representation of the UUID
should be based on lower case characters.
PARTLABEL=label
Human readable partition identifier. This identifier is
independent on filesystem and does not change by mkfs or
mkswap operations. It's supported for example for GUID
Partition Tables (GPT).
PARTUUID=uuid
Partition universally unique identifier. This identifier is
independent on filesystem and does not change by mkfs or
mkswap operations. It's supported for example for GUID
Partition Tables (GPT).
ID=id
Hardware block device ID as generated by udevd. This
identifier is usually based on WWN (unique storage
identifier) and assigned by the hardware manufacturer. See ls
/dev/disk/by-id for more details, this directory and running
udevd is required. This identifier is not recommended for
generic use as the identifier is not strictly defined and it
depends on udev, udev rules and hardware.
The command lsblk --fs provides an overview of filesystems,
LABELs and UUIDs on available block devices. The command blkid -p
<device> provides details about a filesystem on the specified
device.
Don't forget that there is no guarantee that UUIDs and labels are
really unique, especially if you move, share or copy the device.
Use lsblk -o +UUID,PARTUUID to verify that the UUIDs are really
unique in your system.
The recommended setup is to use tags (e.g. UUID=uuid) rather than
/dev/disk/by-{label,uuid,id,partuuid,partlabel} udev symlinks in
the /etc/fstab file. Tags are more readable, robust and portable.
The mount(8) command internally uses udev symlinks, so the use of
symlinks in /etc/fstab has no advantage over tags. For more
details see libblkid(3).
The proc filesystem is not associated with a special device, and
when mounting it, an arbitrary keyword - for example, proc - can
be used instead of a device specification. (The customary choice
none is less fortunate: the error message 'none already mounted'
from mount can be confusing.)
The files /etc/fstab, /etc/mtab and /proc/mounts
The file /etc/fstab (see fstab(5)), may contain lines describing
what devices are usually mounted where, using which options. The
default location of the fstab(5) file can be overridden with the
--fstab path command-line option (see below for more details).
The command
mount -a [-t type] [-O optlist]
(usually given in a bootscript) causes all filesystems mentioned
in fstab (of the proper type and/or having or not having the
proper options) to be mounted as indicated, except for those
whose line contains the noauto keyword. Adding the -F option will
make mount fork, so that the filesystems are mounted in parallel.
When mounting a filesystem mentioned in fstab or mtab, it
suffices to specify on the command line only the device, or only
the mount point.
The programs mount and umount(8) traditionally maintained a list
of currently mounted filesystems in the file /etc/mtab. The
support for regular classic /etc/mtab is completely disabled at
compile time by default, because on current Linux systems it is
better to make /etc/mtab a symlink to /proc/mounts instead. The
regular mtab file maintained in userspace cannot reliably work
with namespaces, containers and other advanced Linux features. If
the regular mtab support is enabled, then it's possible to use
the file as well as the symlink.
If no arguments are given to mount, the list of mounted
filesystems is printed.
If you want to override mount options from /etc/fstab, you have
to use the -o option:
mount device**|dir -o options
and then the mount options from the command line will be appended
to the list of options from /etc/fstab. This default behaviour
can be changed using the --options-mode command-line option. The
usual behavior is that the last option wins if there are
conflicting ones.
The mount program does not read the /etc/fstab file if both
device (or LABEL, UUID, ID, PARTUUID or PARTLABEL) and dir are
specified. For example, to mount device foo at /dir:
mount /dev/foo /dir
This default behaviour can be changed by using the
--options-source-force command-line option to always read
configuration from fstab. For non-root users mount always reads
the fstab configuration.
Non-superuser mounts
Normally, only the superuser can mount filesystems. However, when
fstab contains the user option on a line, anybody can mount the
corresponding filesystem.
Thus, given a line
/dev/cdrom /cd iso9660 ro,user,noauto,unhide
any user can mount the iso9660 filesystem found on an inserted
CDROM using the command:
mount /cd
Note that mount is very strict about non-root users and all paths
specified on command line are verified before fstab is parsed or
a helper program is executed. It's strongly recommended to use a
valid mountpoint to specify filesystem, otherwise mount may fail.
For example it's a bad idea to use NFS or CIFS source on command
line.
Since util-linux 2.35, mount does not exit when user permissions
are inadequate according to libmount's internal security rules.
Instead, it drops suid permissions and continues as regular
non-root user. This behavior supports use-cases where root
permissions are not necessary (e.g., fuse filesystems, user
namespaces, etc).
For more details, see fstab(5). Only the user that mounted a
filesystem can unmount it again. If any user should be able to
unmount it, then use users instead of user in the fstab line. The
owner option is similar to the user option, with the restriction
that the user must be the owner of the special file. This may be
useful e.g. for /dev/fd if a login script makes the console user
owner of this device. The group option is similar, with the
restriction that the user must be a member of the group of the
special file.
Bind mount operation
Remount part of the file hierarchy somewhere else. The call is:
mount --bind olddir newdir
or by using this fstab entry:
/olddir /newdir none bind
After this call the same contents are accessible in two places.
It is important to understand that "bind" does not create any
second-class or special node in the kernel VFS. The "bind" is
just another operation to attach a filesystem. There is nowhere
stored information that the filesystem has been attached by a
"bind" operation. The olddir and newdir are independent and the
olddir may be unmounted.
One can also remount a single file (on a single file). It's also
possible to use a bind mount to create a mountpoint from a
regular directory, for example:
mount --bind foo foo
The bind mount call attaches only (part of) a single filesystem,
not possible submounts. The entire file hierarchy including
submounts can be attached a second place by using:
mount --rbind olddir newdir
Note that the filesystem mount options maintained by the kernel
will remain the same as those on the original mount point. The
userspace mount options (e.g., _netdev) will not be copied by
mount and it's necessary to explicitly specify the options on the
mount command line.
Since util-linux 2.27 mount permits changing the mount options by
passing the relevant options along with --bind. For example:
mount -o bind,ro foo foo
This feature is not supported by the Linux kernel; it is
implemented in userspace by an additional mount(2) remounting
system call. This solution is not atomic.
The alternative (classic) way to create a read-only bind mount is
to use the remount operation, for example:
mount --bind olddir newdir mount -o remount,bind,ro
olddir newdir
Note that a read-only bind will create a read-only mountpoint
(VFS entry), but the original filesystem superblock will still be
writable, meaning that the olddir will be writable, but the
newdir will be read-only.
It's also possible to change nosuid, nodev, noexec, noatime,
nodiratime and relatime VFS entry flags via a "remount,bind"
operation. The other flags (for example filesystem-specific
flags) are silently ignored. It's impossible to change mount
options recursively (for example with -o rbind,ro).
Since util-linux 2.31, mount ignores the bind flag from
/etc/fstab on a remount operation (if "-o remount" is specified
on command line). This is necessary to fully control mount
options on remount by command line. In previous versions the bind
flag has been always applied and it was impossible to re-define
mount options without interaction with the bind semantic. This
mount behavior does not affect situations when "remount,bind" is
specified in the /etc/fstab file.
The move operation
Move a mounted tree to another place (atomically). The call is:
mount --move olddir newdir
This will cause the contents which previously appeared under
olddir to now be accessible under newdir. The physical location
of the files is not changed. Note that olddir has to be a
mountpoint.
Note also that moving a mount residing under a shared mount is
invalid and unsupported. Use findmnt -o TARGET,PROPAGATION to see
the current propagation flags.
Shared subtree operations
Since Linux 2.6.15 it is possible to mark a mount and its
submounts as shared, private, slave or unbindable. A shared mount
provides the ability to create mirrors of that mount such that
mounts and unmounts within any of the mirrors propagate to the
other mirror. A slave mount receives propagation from its master,
but not vice versa. A private mount carries no propagation
abilities. An unbindable mount is a private mount which cannot be
cloned through a bind operation. The detailed semantics are
documented in Documentation/filesystems/sharedsubtree.txt file in
the kernel source tree; see also mount_namespaces(7).
Supported operations are:
mount --make-shared mountpoint
mount --make-slave mountpoint
mount --make-private mountpoint
mount --make-unbindable mountpoint
The following commands allow one to recursively change the type
of all the mounts under a given mountpoint.
mount --make-rshared mountpoint
mount --make-rslave mountpoint
mount --make-rprivate mountpoint
mount --make-runbindable mountpoint
mount(8) does not read fstab(5) when a --make-* operation is
requested. All necessary information has to be specified on the
command line.
Note that the Linux kernel does not allow changing multiple
propagation flags with a single mount(2) system call, and the
flags cannot be mixed with other mount options and operations.
Since util-linux 2.23 the mount command can be used to do more
propagation (topology) changes by one mount(8) call and do it
also together with other mount operations. The propagation flags
are applied by additional mount(2) system calls when the
preceding mount operations were successful. Note that this use
case is not atomic. It is possible to specify the propagation
flags in fstab(5) as mount options (private, slave, shared,
unbindable, rprivate, rslave, rshared, runbindable).
For example:
mount --make-private --make-unbindable /dev/sda1 /foo
is the same as:
mount /dev/sda1 /foo
mount --make-private /foo
mount --make-unbindable /foo
