/etc/mtab in Linux?
Why is it needed and advantages of having it?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
% file /etc/mtab /etc/mtab: symbolic link to ../proc/self/mounts % file /proc/mounts /proc/mounts: symbolic link to self/mounts %
/etc/mtab is a compatibility mechanism. Decades ago, Unix did not have a system call for reading the existing mount information. Instead, programs that mounted filesystems were expected to coöperatively and voluntarily maintain a table in
/etc/mtab of what was mounted where.
For obvious reasons, this was not an ideal mechanism.
Linux gained the notion of a "procfs", and one of the things that it gained was a kernel-maintained version of this table, in the form of a
mounts pseudo-regular file. The "system call" to read the mount information out of the kernel became an open-read-close sequence against that file, followed by parsing the result from human-readable to machine-readable form (something that has some subtle catches, as you can see from the bug reports from just over a fortnight ago).
/etc/mtab thus has popularly become a symbolic link to
/proc/mounts, allowing programs that had hardwired that name to keep reading a mount table from that file, which the programs that mounted and unmounted filesystems no longer have to explicitly do anything themselves to keep up to date. (Some of them still will, though, if
/etc/mtab turns out to be a writable regular file. And there are a few corner cases where the normalized information in
mounts that lacks all non-kernel stuff is not quite what is needed; although they do not outweigh the general problems with
Each process can nowadays have its own individual view of what is mounted, and there are as a consequence now individual
mounts files for each process in the procfs, each process's own table being accessible to it via the
self symbolic link as
/proc/mounts is also now a compatibility mechanism. (Interestingly, neither per-process
mounts nor the format of
mounts are documented in the current Linux doco, although the similar
mountinfo pseudo-regular file is.)
SunOS/Solaris has a similar mechanism. The
/etc/mnttab file is actually a single-file filesystem, and in addition to reading the table, via an open file descriptor to that file, with the
read() system call, one can watch for mount point changes with
poll() and obtain various further pieces of information with
/etc/mnttab is likewise the name of the file, but as of version 11 it was still a regular file whose contents were coöperatively maintained by the system utility programs.
AIX does not export a human-readable text table that programs have to parse, and there is no equivalent file. The BSDs, similarly, have fully-fledged system calls,
getfsstat() on FreeBSD and OpenBSD, for programs to obtain the mount table from the kernel in machine-readable form without marshalling it through a human-readable intermediate form.
/proc/self/mountinfowith \r in mount path. #35137. GNU coreutils bugs.
/proc/mounts. Documentation/filesystems/proc.txt. Linux 5.1.
fstab-decode. Bug #567071. Debian bugs.
getfsstat(). FreeBSD System Calls Manual. 2016-12-27.
The programs mount and umount traditionally maintained a list of currently mounted filesystems in the file /etc/mtab. This real mtab file is still supported, but on current Linux systems it is better to make it a symlink to /proc/mounts instead, because a regular mtab file maintained in userspace cannot reliably work with namespaces, containers and other advanced Linux features.
On mounting without recording in
Mount without writing in /etc/mtab. This is necessary for example when /etc is on a read-only filesystem.
Many more nuances are given in the manual page.