12

It's quite difficult to find information on how automounting of removable media works in modern Linux distributions.

Usually, the answers are like edit /etc/fstab. But those are not useful.

I want to understand how removable media automounting works. So that I could change mount settings and security policies. For example, by default my SD card is mounted as

root:root and 755, so I can't delete anything from it.

1
  • in most cases the mount is done by a combination of udev and fuse. The rules can be found in /lib/udev/rules.d.
    – Marco
    May 18, 2023 at 16:53

3 Answers 3

18

Usually there are two parts involved in mounting of removable devices: UDisks and some part of your desktop environment like GVfs for GNOME.

UDisks is a daemon that runs as root and provides DBus API for working with storage devices. When you connect a removable device, UDisks will notify your DE that a device appeared and it's up to your DE to decide what to do with the device -- it can tell UDisks mount it right away or just show it in your file manager for you to manually mount it by clicking on it (this is usually configurable for example in KDE in Settings -> Hardware -> Removable Devices).

There is actually one extra daemon involved in this and that's Polkit. Mounting is a privileged operation so you (or your DE) can't just run mount without using sudo, but UDisks can, because it runs as root and it uses its set of polkit rules to determine whether to allow the mount operation without asking for admin password.

If you wish to change how the device is mounted (mount options, mount point etc.) you have two options. First is /etc/fstab, UDisks will use it so if you add your device there it will use the mount point and mount options you specify. Second is to use the configurable mount options feature available in UDisks -- you can specify mount options that will be used for given filesystem or device either in the UDisks /etc/udisks2/mount_options.conf config file, or using a udev rule.

0
13

There are, generically, three ways this might work on a modern Linux system, depending on the exact system configuration.

The ‘normal’ way that most distros are configured to use out of the box involves a DBus service called UDisks, which is, simply put, a fancy privilege separation system that lets normal users mount and unmount devices. The desktop environment and/or the file manager interact with UDisks to get a list of removable devices, then present those in a way the user can directly interact with. In some cases (Audio CDs, MTP/PTP devices, network shares, etc), there is generally a different component involved (GVFS on GNOME and most other GTK+ desktops, KIO on KDE) that handles presenting the device as a regular filesystem, and UDisks may not even be involved at all (in fact, most of the things that require this don’t involve UDisks). On systems that are set up this way, you can manually interact with UDisks using the udisksctl command. UDisks will generally honor any mount options specified for a particular device in /etc/fstab, as well as the specified mount path.

The second most common approach on modern Linux systems is systemd auto-mounts. In short, systemd watches the path where the filesystem should be mounted, and mounts it if something tries to access that path. This only works for statically configured mounts and requires an entry in /etc/fstab with appropriate options or a systemd.automount unit. It is not used much on desktops, but is relatively common for systems without a desktop that interact with removable media regularly.

The third, and most traditional option, is autofs. This is a userspace daemon (and associated kernel driver) that largely works in the same way that systemd automounts do, but has a handful of other features that systemd lacks for this purpose (most notably, it can do network share autodiscovery). It has the same general limitations as systemd auto mounts, though the configuration location is different. These days, it’s only really used on systems that need to access large, dynamically changing, networks of shares or systems that completely lack both UDisks and systemd.

4

In modern distributions everything is handled by daemons. So, even the config files are automatically created. So the most difficult part is finding out which daemon handles what part of the system.

So, removable media (SD card, USB drives) automount is managed by udisks daemon. The detection of attaching and detaching the removable media is handled by udev.

Whenever you attach a new piece of hardware, kernel notifies udev, udev creates a block device and notifies udisks, udisks mounts the device.

The source code of udisks currently lives on github. The latest version is 2.9.4, so It's commonly referred to as udisks2.

If the SD card has a recognized file system, such as FAT32 or exFAT, udisks2 creates a mount point in the /media directory (or /run/media/ or /mnt/) with a unique name based on the device's label or other identifier. It then mounts the SD card at that mount point.

After the SD card is mounted, the file manager (such as Nautilus in Ubuntu) detects the mount point and displays the SD card contents in the file manager user interface.

You must log in to answer this question.

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