Old faithful and ever present, mount(8) is ubiquitous. Use it to mount a filesystem as root giving it a comma-separated list of options preceded by the -o flag, the device, and the mountpoint. To mount the Btrfs subvolume named backups on the block device /dev/sdb1 to /run/media/$USER/backups with several mount options, use the following command.

To unmount the device, use the umount command with the device path or the path of the mount point. Here, the previously mounted device is unmounted.

Easy, right?

To automatically mount something, fstab(5) is the de facto standard. The previous command can be translated to the following entry in fstab.

Now this subvolume will be mounted with the appropriate options when the system is booted up. Or, at least, it should…​ Always verify your fstab file after modifying it with findmnt --verify. Here I include the --verbose flag as well and abbreviate the output.

There’s no errors and the warnings don’t appear to be anything serious. Everything should be alright.

Previously when using the mount command, each mount option had to be specified. When mounting a matching entry in fstab, the mount options in fstab are applied automatically. The following command will mount the volume using the mount options specified in fstab for /run/media/$USER/backups.

This is where things start to get complicated. systemd handles dependencies among all sorts of services whether that’s during boot or during runtime. Some things require mounting filesystems, so systemd exposes an interface for specifying and managing these dependencies. The primary unit file for this is the systemd.mount(5) unit.

A companion unit file type exists systemd.automount(5) which, if created, controls automatically mounting the mount point. The automount functionality will automatically mount a volume in an on-demand fashion. When the volume is first accessed, it is mounted as necessary. A timeout may be specified to automatically unmount the volume after a period of time.

An important aspect the mount unit convention is the required naming scheme. The file names of mount and automount units must correspond to the mount point of where the volume will be mounted. The file name is appropriately transformed to remove troublesome characters. Most notably, `/’s are replaced with `-’s.

Given that fstab contains an entry with the user or users mount options, that entry can be mounted by the user without root privileges. This still requires support from someone with superuser access on the system, which is impractical for those users who just want to be able to mount a flash drive. This method doesn’t allow the user to mount the filesystem with any special mount options on the command-line. Mount options may only be specified within fstab.

The fstab entry below allows a user to mount /dev/sdb1 to /run/media/$USER/backups.

Now, a user can mount the volume with the device path or the mount point as done here.

A user can also unmount the entry they have mounted when it is set with the user option.

When the users option is provided, it allows any user to unmount the drive regardless of which user mounted it. This differs from the user option which only allows the user that mounted the volume to unmount it.

While systemd provides user-level services, including mounting, its abilities are limited to that of the mount command. And to that end, its practically usesless for userspace mounting. After trying all sorts of workarounds, the mount command just isn’t called correctly to allow non-root users the ability to mount filesystems. A corresponding fstab entry with the user or users mount option has no effect. This is because systemd hard-codes the mount command with both the device and the mount point. This was shown to end with an error when run as a normal user previously.

The only sensible way to make this possible is by using a {systemd-service} unit rather than a systemd mount unit. A correctly formed mount command will succeed when executed by the user. Given the entry for /run/media/jordan/backups has the user or users mount option set in fstab, a user service file to mount it would look like the following.

To mount the volume, start the service.

Unmounting the volume is just a matter of stopping the service. Do this like so.

If you want to mount automatically when logging in, use the enable subcommand instead of start.

To take this a step, further, it’s possible to create an instantiable systemd unit. This is a fancy way of saying that variable information can be provided in the file name after the @ symbol and before the units extension. This allows creating a single unit file to accommodate a variety of situations. It effectively introduces a variable which can be used to customize the unit.

The previous unit can be made into a generic, instantiable unit which allows mounting a variety of volumes. Thanks goes to byly’s answer on the Unix & Linux Stack Exchange for introducing me to this nifty approach. To follow conventions, the unit will mount the volume under /run/media/$USER. The mount point will be encoded in the name of the service, i.e. sandwiched between the @ and .service suffix. This user service unit, dubbed mount@, looks like this.

This unit uses wildcards, letters prefixed with %. Wildcards are substituted with the appropriate information when the unit is enabled. %u stands for the username of the user using the unit. %I represents the instantiable component provided in the unit’s name.

To use the instantiable unit, the directory for the mount point must exist in /run/media/$USER. Additionally, an entry in fstab that mounts to that mount point must set the user or users mount option. Given those requirements, use the instantiable service as demonstrated here. To mount /run/media/run/$USER/backups, start the service with the name mount@backups.

Unmount it by stopping the service of the same name.

Now it’s time to move on to a more practical tool for mounting volumes from userspace.

There’s a tool for easily mounting volumes in userspace. It’s udisks2 and it streamlines userspace mounting and changing up those default mount options. If you’re accustomed to a desktop environment on Linux, you’ve likely benefitted from udisks2. That’s because it’s what graphical applications such as file managers use to mount drives on your behalf.

Mounting and unmounting are done with the udisksctl command. To mount a volume, use the mount subcommand. Unlike the mount program, only the block device is specified. The mount point is determined by udisks2. Depending on how udisks2 was compiled, the volume will be mounted in a subdirectory of either be /run/media/ or /media/. Use the -b flag before the block device. Mount options should be provided as a comma-separated list following the --options flag.

Here, I mount /dev/sdb1 with specific Btrfs mount options.

Drat. udisks2 doesn’t allow the options I want. In version 2.9.0 of udisks2, a newer version than ships with Ubuntu 18.04, it’s possible to configure the allowed and default mount options as described in the following sections. A newer version of udisks2 can be installed on Ubuntu 18.04 by following the instructions in the post Install udisks2 From Source. It turns out the only allowed mount option here is noatime, so the simpler command below will still mount the volume.

Unmount the volume using the unmount subcommand followed by the -b flag and the block device.

udev(7) is the subsystem for handling device events on Linux. It is a robust method for triggering certain actions when devices are detected. udev rules can be used with udisks2 to specify the allowed or default mount options for specific devices. This can be for an individual device, a class of devices or some other subset of devices.

A system’s udev rules reside in rules files in standard directories, such as /etc/udev/rules.d. To create a new rule, create a new file in this directory. udisks2 recommends using the prefix 99- to ensure that the rule runs last.

udev rules pretty much boil down to matching on a device on certain criteria. To work with udisks2, there is a required format including a specific header for block devices and a closing LABEL. Modifying the mount options is done through a few variables used in the same way as the keys in the configuration file. The variables are named differently than the keys, but follow the same naming convention. Defaults are set with the variable UDISKS_MOUNT_OPTIONS_DEFAULTS and allowed options with UDISKS_MOUNT_OPTIONS_ALLOW. Filesystem-specific variables place the filesystem type in all caps in between the UDISKS_MOUNT_OPTIONS portion at the beginning and the _ALLOW or _DEFAULTS part at the end. Btrfs defaults can be changed by setting the variable UDISKS_MOUNT_OPTIONS_BTRFS_DEFAULTS. When setting filesystem-specific options, you should match the rule on the filesystem type provided by the variable ID_FS_TYPE. There’s more to it that that, but this isn’t supposed to be a udev tutorial so I’ll show a couple of examples.

The udev rule here applies specific Btrfs default mount options to all USB devices. These are the same defaults set above in the global configuration file. This also mounts USB devices as read-write.

To enable a new rule, either reboot your system or reload the udev daemon as demonstrated by the command here.

The following rule matches on an exact USB device and applies the same default Btrfs options.

To determine the id attributes for your hardware, query the information with udevadm. Here I filter the output of such a query for /dev/sdb1 to just show the ID_VENDOR, ID_MODEL, and ID_SERIAL_SHORT attributes.

For more examples and information, refer to the udisks2 documentation.

GIO is a filesystem layer abstraction GNOME and GTK. GTK and GNOME applications use GIO to interact with filesystems. GIO also bundles a command-line tool which can be used to mount and unmount filesystems. It can’t be used to control mount options directly. However, since it uses udisks2 to mount physical media, default mount options configured for udisks2 carry over. GIO has the added convenience of being able to unlock and mount an encrypted volume in a single command. It can also use encryption keys saved in a user’s keyring to unlock encrypted volumes without requiring a password every time. Follow the steps below to mount and unmount the /dev/sdb1 volume.