I'm currently writing a basic filesystem abstraction (in C++) and I need to get a list of "useful" mounted devices on linux.

I've found the function(s) getmntent/getmntent_r that allow to me to easily parse /etc/mtab and /proc/mounts however many of the mounted devices aren't "useful" (such as: /sys/fs/cgroup/net_cls). In particular I'm attempting to find mounts which related to a physical device, partition or network share/drive.

The closest I've found is checking if the mnt_fsname (device name) starts with a /, which in the case of my system narrows it down to:

  • /

  • /boot

  • /run/media/[username]/0CA8-1F2D

  • /run/media/[username]/14E0-3E80

Which appears to be what I want (the latter two being partitions on a usb stick). I haven't had a chance to try out a network share/device with it though.

Basically this is meant to be an approximation of windows-like 'drives', hence why I'm interested in physical devices etc., but doesn't prevent a library user navigating to unlisted devices if they so-desire.

So basically the question boils down too:

  • If the device name in a mount entry starts with a / is it guarenteed to be a physical device, partition or network share?

  • Will I be leaving out anything particularly important/useful?

  • Is there a better/more precise way to do this?

  • how about something akin to?: df -x tmpfs -x devtmpfs Jul 29, 2016 at 17:23
  • /proc is not a physical device, partition, or network share, so it is not guaranteed. Trying to implement windows 'drives' on linux sounds like a half-baked plan to begin with, since the linux way is a ton more flexible. Why exactly are you trying to do this?
    – Wyatt Ward
    Jul 29, 2016 at 17:29
  • @Wyatt8740 I can gather devices from multiple sources other than just /proc so that's a non-issue. I'm not so much as trying to implement windows 'drives' on linux, all I'm doing is providing 'system-agnostic' shortcuts to physical drives, paritions and network shares for ease of use. If the library user wants to navigate to a particular directory/device, they're not prevented from doing so.
    – NotVeryMoe
    Jul 29, 2016 at 17:41
  • @Theophrastus Actually that works beautifully. I'll need to figure out someway to use it a bit cleaner though, executing another program and parsing the output is a little clumbersome but not that big a problem - that and it adds another dependancy. But I'll see if I can wrap my head around the source.
    – NotVeryMoe
    Jul 29, 2016 at 17:44
  • Note that recent windows versions also permit mounting to directories.
    – Wyatt Ward
    Jul 29, 2016 at 17:47

2 Answers 2


I don't think there's a notion of “useful mounts” that makes sense in all scenarios. You want to include removable physical drives and network mounts, and exclude filesystems for system access such as those under /dev, /proc and /sys. What about filesystems mounted by the user? Knowing that a filesystem is provided by FUSE doesn't tell you what it is. It could be an archive, a network mount, an alternate view of a directory, a disk image, a way to control some program, …

Checking if the device name starts with / doesn't seem useful to me. For example it would include bind mounts and exclude network mounts.

I think the best you can do is to not reinvent the wheel. If nothing else, by using the same mechanism as others, you won't confuse your users (“why does X list that filesystem but not Y???”). Additionally there's a chance that what the others did might make sense.

So my recommendation is to use Gnome libraries, at least GTK+. GTK+ has a file opening dialog which shows some mounted filesystems under “Places”. Users can control what is listed there to some extent — if they can figure it out, that is. Even if you don't show the file open dialog from GTK+, use the same list of “places” (I don't know how to obtain that, look at the API documentation).

  • Actually that's pretty much perfect. Looking at the second link I believe I should be able to implement something that behaves identically and atleast while it's not a universal standard it's a flexible standard nonetheless!
    – NotVeryMoe
    Jul 30, 2016 at 4:26

„useful“ my be a matter of opinion, but anyway, here is my take:

  const getMount = (mountId, _parentID, _deviceNo, root, mountPoint, mountOptions, _fields, _mountSource, superOptions, blob) => (
      // parentID,
      // deviceNo,
      mountOptions: mountOptions.split(','),
      // fields,
      // mountSource,
      superOptions: superOptions.split(','),

  const mounts = fs.readFileSync('/proc/self/mountinfo', 'utf-8')
    .filter(l => l.length > 0) // filter empty line at end
    .map((m) => getMount(...m.split(' ')))
    .filter((m) =>
      !/^\/(snap|run|sys|proc|dev)($|\/)/.test(m.mountPoint) &&
      !['mqueue', 'tmpfs'].includes(m.superOptions) &&
      !m.superOptions.includes('mqueue') &&
      !m.superOptions.includes('tmpfs') &&
    .map((l) =>

(What I needed were devices, from where generally speaking files could be deleted and thus being relevant to a recycle bin path matters (how to calculate those is another matter))

You must log in to answer this question.

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