Press "Enter" to skip to content

A Tour of Mount in Linux

Shahriar 1

I had windows 10 installed on my laptop because of serious incompatibility of ROG laptops with Linux and my desire to play some games after years of living in bash! This continued for a year and I really like windows 10 cool features like WSL and Hyper-V (with Docker!), however being in love with rolling-release distros and being fed up with windows in the past year. And the fact that I was yearning for terminal, I installed Solus OS earlier this week on a separate partition without removing windows.

And now we get to the point which I wanted to listen to some music which resided on another ntfs volume. And trying to automatically mount the drive with Solus, It occurred to me that how much has really changed in hardware representation in Linux in general. Then it became to write this post about mounting in Linux and new tools for it.

A little background

when you have a storage device (like a hard disk) attached to your computer, Linux kernel, being in charge of talking to hardware, detects the device and creates a file representing the device in /dev like /dev/sda. For each partition that is detected from the device’s partition table, another file is created like /dev/sda1

Some files are also created in sysfs (/sys) in newer kernels and expose more advanced control and info to the user. (which are not talked about in this post)

For actually being able to read/write into a device, you should mount it first. The mount command mounts a storage device or filesystem, making it accessible and attaching it to an existing directory structure.

in order to mount a volume you should invoke the mount command. First, you will create a directory (should be empty)

Then you mount the volume to that:

To see all mounted volumes and their options you can use mount command or findmnt (both are provided by util-linux and are available in all distros):

For unmounting the device you should use umount:

either the device containing the file system or the mount point can be specified.

A word about permissions

All device files created in /dev are only accessible to root. Therefore in a general sense, only root can mount stuff. This is very important and you need to keep that in mind. If a filesystem has Linux permission support (linux native filesystems like ext2, ext3, ext4, btrfs, xfs, etc), they are leveraged and files on the drive are treated like other files in your linux system. But some filesystems like FAT derivatives (FAT32, exFAT, etc) are not capable of storing permission information. So by default they become only available too root unless you specify some options at mount time to allow other users. consider this example:

also this neat one-liner which mounts them accessible to your user:

or all users…


A filesystem controls how data is stored and retrieved. usually necessary options and filesystem are detected by the mount command, but you can specify them manually like this:

You can view all filesystems supported by your kernel by reading this file:

The first column signifies whether the file system is mounted on a block device. Those beginning with nodev are not mounted on a device. The second column lists the names of the file systems supported.

The mount command cycles through the file systems listed here when one is not specified as an argument.

To see existing filesystems on drives use lsblk command like this:

(loop devices are apparently being used by snapd. I will write about it in another article, it’s very cool!)

As I said earlier these are filesystem types supported by the kernel, you might ask so where else can a filesystem be implemented? And the answer is FUSE.

Filesystem in Userspace (FUSE) is a mechanism for Unix-like operating systems that lets non-privileged users create their own file systems without editing kernel code. This is achieved by running file system code in user space, while the FUSE kernel module provides only a “bridge” to the actual kernel interfaces.

However you should know that reading/writing on a FUSE filesystem involves a lot more overhead because of code providing filesystem functionality being in userland and each call to a function for that matter will traverse kernel and userland a couple of times more than a regular file operation involving a driver in kernel. Nonetheless it is a very useful feature in a lot of scenarios. (like mounting writable ntfs or a filesystem over the network)

There are also a myriad of other filesystems in the Linux world, such as overlay filesystems , so I suggest you to read references at the end of the post for further reading.

Once we know the basics of mounting in linux, we are going to learn how to automate that and what happens when Linux is booted regarding mounts.


The fstab file can be used to define how disk partitions, various other block devices, or remote filesystems should be mounted into the filesystem.

Each filesystem is described on a separate line. Fields on each line are separated by tabs or spaces. Lines starting with ‘#’ are comments. Blank lines are ignored. 

The mount command will use fstab, if just one of either directory or device is given, to fill in the value for the other parameter. When doing so, mount options which are listed in fstab will also be used. (user option can be set in fstab to allow non-root users to mount)

All specified devices within /etc/fstab will be automatically mounted on startup and when the -a flag is used with mount, unless the noauto option is specified. Devices that are listed and not present will result in an error unless the nofail option is used.

It is very recommended to use UUID or other unique identifiers instead of relying on kernel name descriptors (sda1, sdb2, …) as they may change after reboot!

UUID is the preferred method. You can find out the UUID with lsblk -f 

Modernizing mounting

In the early 2000s, the first attempt to cope with this was called HAL – Hardware Abstraction Layer, which did what it said on the tin, provided a layer between device nodes and the user of the nodes, so storage devices (and other hardware) can be added and removed without rebooting this system and without rewriting the /etc/fstab file.

After deprecation of HAL, everything gets replaced a dizzying number of times (DeviceKit, devfs, etc) as better approaches are discovered in a fast moving period of hardware development, udev eventually won and was the main thing for the rest of the decade.

When a device is added or removed from the system, the Linux kernel notices and sends out an event. udev is a daemon that waits around listening for these events and then responding accordingly. udev runs in user space not kernel space. 


Building on top of new technologies (D-Bus, udev), udisks was created. It has modernized the mounting on userland.

udisks provides:

  • a daemon, udisksd, that implements well-defined D-Bus interfaces that can be used to query and manipulate storage devices.
  • a command-line tool, udisksctl, that can be used to query and use the daemon The actions that a user can perform using udisks are restricted using polkit.

It is the tool that handles all the work and permission checking when you simply click on the fancy usb flash drive icon that has appeared on your desktop after inserting it into your PC.

We will cover the use of udisksctl for basic mounting/unmounting in this post. But it is important to know that all functionality provided here is just a wrapper around D-Bus calls which is easily programmable will be very useful in storage management automation. (like the clicking mentioned, etc)

 To see a list of disks attached to the system (serial numbers are replaced):

To see detailed info about disk:

To actually mount a filesystem using this new tool:

And then to unmount:

systemd mount units

Considering the merger of udev and systemd, and the ubiquity of systemd in modern Linux distros. It is recommended to ditch old-school habits and start having fun with cool new functionality made available to use. 

Adding entries in fstab is no longer the main way to mount a device at startup. In fact all entries in /etc/fstab are converted to systemd mount units at boot. 

Example systemd .mount file:

Important: Mount units must be named after the mount point directories they control.

Example: the mount point /home/lennart must be configured in a unit file home-lennart.mount.

So we create a file like this:

Of course you should signal systemd to load the unit file after you’re done editing:

You can view state of the mount like other units:

Important: If you want it to be mounted on each boot, you should also include an [Install] section in the unit file:

 And the enable the unit to be started at boot:

I hope you liked this post. There are still things that were left out of this post about mounting in Linux. But I leave them up to you to explore if you are interested. Overlay filesystems, FUSE and AutoFS are useful and are recommended for reading.


  1. Guy Guy

    Nice article, well done.

Leave a Reply

Your email address will not be published. Required fields are marked *