I usually use mount to check which filesystems are mounted. I also know there is some connection between mount and /etc/mtab but I'm not sure about the details. After reading How to check if /proc/ is mounted I get more confused.

My question is: How to get the most precise list of mounted filesystems? Should I just use mount, or read the contents of /etc/mtab, or contents of /proc/mounts? What would give the most trustworthy result?


5 Answers 5


The definitive list of mounted filesystems is in /proc/mounts.

If you have any form of containers on your system, /proc/mounts only lists the filesystems that are in your present container. For example, in a chroot, /proc/mounts lists only the filesystems whose mount point is within the chroot. (There are ways to escape the chroot, mind.)

There's also a list of mounted filesystems in /etc/mtab. This list is maintained by the mount and umount commands. That means that if you don't use these commands (which is pretty rare), your action (mount or unmount) won't be recorded. In practice, it's mostly in a chroot that you'll find /etc/mtab files that differ wildly from the state of the system. Also, mounts performed in the chroot will be reflected in the chroot's /etc/mtab but not in the main /etc/mtab. Actions performed while /etc/mtab is on a read-only filesystem are also not recorded there.

The reason why you'd sometimes want to consult /etc/mtab in preference to or in addition to /proc/mounts is that because it has access to the mount command line, it's sometimes able to present information in a way that's easier to understand; for example you see mount options as requested (whereas /proc/mounts lists the mount and kernel defaults as well), and bind mounts appear as such in /etc/mtab.

  • 1
    What's the point of mount maintaining /etc/mtab if it can't be relied upon? Wouldn't it be better if mount presented information from /proc/mounts instead? Commented Feb 12, 2015 at 10:31
  • 2
    @PiotrDobrogost /etc/mtab can record information that the kernel doesn't track, such as the options originally requested, and bind mounts appearing as such instead of appearing as duplicate entries for devices. Nonetheless many distributions are moving towards making /etc/mtab a symlink to /proc/mounts. Commented Feb 12, 2015 at 10:41
  • 3
    Nonetheless many distributions are moving towards making /etc/mtab a symlink to /proc/mounts. Good to hear – adding this information to answer would make it even better. Do you think tracking requested options by the kernel would be feasible and beneficial? Commented Feb 12, 2015 at 11:13
  • 2
    Note that you'll need to un-escape the contents of /proc/mounts. As described on the getmntent(3) page, space (\040), tab (\011), newline (\012) and backslash (\134) need to be handled specially. Especially if user mounts are enabled, you'll need to be very careful when working with these paths.
    – Eric
    Commented Aug 31, 2015 at 15:50
  • 5
    Please see also other answer for using command findmnt which is the preferred way since 2010 and probable the only safe way in near future when mount namespaces will be common.
    – Marki555
    Commented May 18, 2016 at 19:46

As of v. 2.18 (July 2010) util-linux includes a tool that allows you to display a list of currently mounted file systems:


You can switch from the default tree view to list view with -l, define output columns with -o (similar to lsblk), filter results based on filesystem type with -t etc...

findmnt -lo source,target,fstype,label,options,used -t ext4
SOURCE    TARGET      FSTYPE LABEL OPTIONS                           USED
/dev/sda1 /           ext4   ARCH  rw,noatime,discard,data=ordered  17.6G
/dev/sdb2 /media/DATA ext4   DATA  rw,noatime,discard,data=ordered    44M

As of version 2.27 there's also support for JSON output via -J or --json switch:

findmnt -Jo source,target,label,uuid -t ext4
   "filesystems": [
         "source": "/dev/nvme0n1p5",
         "target": "/",
         "label": "ARCH",
         "uuid": "f21a53194-b02a-4e92-ad96-fdf9b8bc1db9",
         "children": [
               "source": "/dev/nvme0n1p6",
               "target": "/run/media/data",
               "label": "DATA",
               "uuid": "321e288a-e67c-4b68-8d0b-89720210921f"

For more details read the man page (and findmnt --help to get the list of available columns).

  • 1
    This answer provides the most comprehensive list, including the most obscure mounts like /sys/fs/bpf, /sys/fs/cgroup, /sys/firmware/efi/efivars etc. A lot to wade through, but grep is your friend. Commented Jan 31, 2020 at 15:44
  • 1
    Thank you very much. This solves the problem when you just wish to know the target in a single list, this way I can use it in a script to invoke the right device, just by greping a part of the target's name. Commented May 23, 2020 at 0:38
  • Most importantly it has a --json for easy python parsing. Commented Jul 10, 2022 at 23:29
  • 1
    Wow, this is amazing. It's already structured and it even has json support. Finally, we can get rid of the mess mount produces! This command should be more popular and become the new default. The original mount is an utter & useless joke compared to this!
    – Akito
    Commented Nov 23, 2022 at 1:57
  • very good answer! in the man pages there is also the avail option which I find really useful, showing also how much space left on the volume: findmnt -lo source,target,fstype,label,options,used,avail -t ext4
    – xaratustra
    Commented Nov 25, 2022 at 10:55

Maybe because it has been 5 years since this question was answered things have changed. The cat /proc/mounts creates a lot of info you do not care about. Today, IMHO, I find this to be the ultimate solution.

df -h --output=source,target

when you read the man pages there are all kinds of options you can do but this is what you what. For example to clean up the results even more you can exclude file types of "tmpfs" with this command:

df -hx tmpfs --output=source,target

df works on the filesystem level and not the file level.

The commands above will include network mounts as well.

To see a little more information use this:

df -hT

NOTE With slow mounted network connections this can take several minutes!

If you don't have or care about mounted network connections (and you have root permissions) than this is even better:

sudo lsblk -f
  • You don't have to be root but some of the fields/columns (such as Label) will have null data, which might still be okay in that the questions wants to know what filesystems are mounted.
    – Rick
    Commented Feb 18, 2016 at 23:55
  • Ubuntu. However I just discovered "findmnt" that doesn't use root and it lists network mounted filesystems. I was thinking of editing my answer to include that knowledge.
    – Rick
    Commented Feb 19, 2016 at 0:03
  • :-) I tired to give your answer a vote but can't until I have a rep of 15+
    – Rick
    Commented Feb 19, 2016 at 0:07
  • 1
    Btw, if you're trying to use --output with something like Ubuntu 12 which doesn't accept those options, check out don_crissti's findmnt answer below which does. Commented Jun 8, 2016 at 2:36
  • findmnt seems to need higher capabilities (tested with root; root has all capabilities) to display labels. Commented Jun 27, 2016 at 16:11

Most of the time, mount is the most convenient method. For a complete and exact list of currently mounted filesystems, you should read the contents of /proc/mounts (e.g., with cat /proc/mounts).

For example, if mounting / readwrite failed and it was then mounted readonly as a fallback, /etc/mtab (which the mount command reads from to tell you what's mounted, and writes to--if it can--when it changes what is mounted) would not be updated to reflect that / (which contains /etc/mtab) is currently mounted readonly. In this situation, running mount would typically tell you (incorrectly) that / was mounted readwrite.

Under normal conditions (i.e., when the filesystem that contains it can be written to), /etc/mtab contains a list of currently mounted filesystems. This is not to be confused with /etc/fstab, which contains a list of filesystems that are supposed to get mounted automatically when the system starts up.

Of course, if the /proc virtual filesystem is itself not mounted, then you cannot read any of the virtual files in it, which would include /proc/mounts. This very rarely is the case. In this situation, mount is probably your best option for seeing what's mounted.


If the mounted source for some reason is no longer accessible (in my case my domain password expired), the mount point directory is empty and (at least for me) the mount no longer shows up in /proc/mount.

I desperately searched for any such mounts since I suspected there was some mount that frequently tried to access my domain account with old credentials (every few seconds) and thereby frequently locked the account. That´s why I found this question in the first place. But /proc/mounts was not the solution for me.

I knew I had probably done some mounting from an Ubuntu server with a command like the below, but was unsure of what mount_point_dir I could have used, since none of my regular mount_points seemed to be mounted.

$ mount.cifs <remotetarget> <mount_point_dir>

I finally found a verification that there actually existed some mounting with authorization problems from the syslog in /var/log/syslog. I saw a lot of lines in this log with the following statements:

CIFS VFS: Free previous auth_key.response
Status code returned 0xc0000234 STATUS_ACCOUNT_LOCKED_OUT

That confirmed my suspicions and I could then get further confirmation from looking at the Stats and DebugData under the /proc/fs/cifs folder.

See further information here.

Although I never actually saw the information about the target mount_point_dir, only the mounted source, this was enough for me to solve my issue, since this motivated me to do a reboot of the server, after which the mounts were gone and also the account locking problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .