How does mounting on the GUI work "under the hood"

Question

UPDATE

Please correct me if I'm wrong: For working on my computer, with a GNU/Linux Distribution named Debian, I know two ways to enter a command, start an application, open a file, etc.:

• a Command Line Interface where I enter text
• a Graphical User Interface [a.k.a GUI]: an interface which provides "windows", symbols etc.

There is something going by the name "Window Manager". As I use GNU/Linux, I do work on the X-Window System [as far as I know].

---

Original Posting

---

Situation: I disabled automount in /etc/fstab for USB Sticks [e.g. /dev/sdb1]. Mounting requires to be root, or at least a sudo entry on the command line but not in a window manager (!). I do not mean automount, I mean "clicking on the symbol" in a window manager opens the device on the GUI without any questions, where on the CLI one must be root.

Question: How does mounting in a GUI work "under the hood"? Is there a configfile for window managers in general or does one have to set this individually?

I do understand and use mount command, I think to understand how to read and configure /etc/fstab and know where to look what the entries there and in /etc/mtabmean.

Answer 1

It depends on your windowing environment (GNOME/KDE/etc.) but in GNOME, for example, you'll see daemons running called, gvfs-*-volume-monitor. These daemons are responsible for mounting devices when running the desktop environment, they have nothing to do with /etc/fstab, and operate completely independently.

As far as a config file, there are some files that are related to this that live in the user's home directory that is running the DE, $HOME/.local/share/gvfs-metadata.

This U&L Q&A titled: What is gvfs and why should I want it on my system?, attempts to explain what GVFS is. It does an OK job of explaining it. But I think what you're really asking about is addressed more by this U&L Q&A titled: Mounting USB disks automatically (How it works).

Answer 2

The simple answer is they cheat. They don't use the fstab. They typically use a udev hook to catch insertion events, mount the disk manually as root, which may be passed to dbus to notify your file manager that you have a new disk or they might use suid utilities instead of dbus for unmounting. Unfortunately there are no standard configuration options for this, and since the desktop movement believes in hiding complexity they don't document this in the user documentation, only in the developer documentation, and they assume a single user system so USB drives only work for the first user to login to an X server.

Answer 3

This is my understanding of the situation, but I'm not an expert so it is less technical than the other answers. This is what I understand after using these systems for many years, I have not studied them in any detail.

There are three main players here and between them they manage the mounts:

• FUSE: This is at the center of everything, as described in its wikipedia page:

  Filesystem in Userspace (FUSE) is an operating system mechanism for Unix-like computer 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 module provides only a "bridge" to the actual kernel interfaces.

  So, basically, this is what allows unprivileged users to mount filesystems.

• gvfs : In the Gnome family of desktop environments (which includes Gnome, Mate, Cinnamon), this is (among other things) a daemon that will automatically mount newly connected drives. It does so via FUSE. I believe (but may well be wrong) the equivalent for the KDE family is called KIO

  The main processes of gvfs are (taken from man gvfs):

  • gvfsd - the main gvfs daemon
  • gvfs-fuse-daemon - mounts gvfs as a fuse filesystem
  • gvfsd-metadata - writes gvfs metadata

• udev : This is a system that detects new devices and allows you to run scripts/commands when they are connected. For example, it is udev that detects a new screen and can mirror your desktop on it:

  udev is a device manager for the Linux kernel. Primarily, it manages device nodes in /dev. It is the successor of devfs and hotplug, which means that it handles the /dev directory and all user space actions when adding/removing devices, including firmware load.

  Specifically, gvfs seems to work through gvfs-udisks2-volume-monitor which is a udisks-based volume monitor. udisks itself however, relies on udev (see man 7 udisks).

So, basically (read "horrible simplification") what happens is that when you connect your drive, udev detects it and alerts the gvfs daemon which will then mount it as a FUSE device.

FUSE and udev will be the same for all desktop environments, what changes is the DE daemon that monitors udev and mounts the drive as a FUSE filesystem.

Answer 4

PolicyKit (or Polkit) is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes.

It is a framework for centralizing the decision making process with respect to granting access to privileged operations (like calling the Mount() method) for unprivileged (desktop) applications.

An authentication agent is used to make the user of a session prove that the user of the session really is the user (by authenticating as the user) or an administrative user (by authenticating as an administrator).

GVFS is a virtual filesystem which allows mounting local and remote filesystems as a user along with trash support. There is also FUSE support that allows applications not using GIO to access the GVFS filesystems, but most DEs do authentication via Policykit for other things as well, like hibernating and shutting down the computer, and for the NetworkManager, so they don't need to use FUSE.

It consists of two parts:

1. A shared library which is loaded by applications supporting GIO;
2. GVFS itself, which contains a collection of daemons which communicate with each other and the GIO module over D-Bus.

The gvfs package needs to be installed, along with polkit-gnome for the polkit rules. Make sure that a graphical authentication agent installed and autostarted.

Configuration files for managing privileges must be different for each distribution. The Arch Wiki tells you to create a file under /usr/share/polkit-1/rules.d/. In Debian, they are located in /etc/polkit-1/.

Sources: Policykit on Debian || Polkit on Arch Wiki || GVFS on Arch Wiki || GVFS on GNOME Wiki!

Answer 5

One common element you are looking for is FUSE, GNOME's gvfs, e.g., uses that under the hood.¹ This is the interface with the kernel, and I believe it is common to all unprivileged (auto)mounting systems on linux [but see comments]. Individual DE's would not create their own version of this since that would require kernel patching.

That homepage link is in fact outdated, because as noted here, FUSE became part of the official kernel a few years ago, but it does describe the origins and purposes of the project (it is not just for unprivileged mounting).

The reason various systems may deviate in style beyond this is the same reason you have various desktop environments: they represent different visions of how/what the GUI should be. They're taking care of the form and function of the user interface, but FUSE does the actual mounting and kernel level stuff. Note that FUSE doesn't really do the "auto" part, it is more about the "unprivileged" part, but the auto part is pretty simple: all you have to do is poll, e.g., /dev. I've written a mounting application that works this way; it just watches for the appearance of new nodes.² That part is maybe a hundred lines or so of C++. Easy-peasy -- no real need for a common API on that level.

¹Or can, if it's doing a truly unprivileged mount. Teresa's answer may cover newer approaches to allowing accesses to normal mounts.

²As hildred observes , udev callbacks would be a better, less hack method.