I've been reading this question about why mount must be run as root (with some exceptions), and I was wondering, if mounting a drive requires root (generally), how does a graphical file manager (Nautilus, Thunar, etc) do it? Does it have anything to do with FUSE?

3 Answers 3


Users operating at the console of a graphical workstation have noted that several programs can be executed without apparently needing root authentication nor a password such as reboot. This process involves the clever use of the SUID program /usr/sbin/userhelper applied in a broader context than originally designed.

The graphical user executes an intermediary aliased program /usr/bin/consolehelper which authorizes actions based on a specific PAM (Programmable Authentication Modules) configuration and then sends the command off to a SUID program to execute the user program with privileges. If the user does not have appropriate authorization, then the requested program is executed under the users’ Linux environment.

As currently deployed, the needed PAM configuration file for reboot contains checks for the user to be logged in at the console or be currently running under the root environment to inhibit password requests.

  • So I can assume that a graphical say, file manager (as per my original question, though I'm glad for the broader context), is using the same method despite not being a graphical console?
    – Joe D
    Commented Sep 17, 2016 at 0:50
  • Additionally, there is a special mode in mount allowing for a user to mount something. Look at the "non-superuser mount" in the mount man page.
    – mdpc
    Commented Sep 17, 2016 at 0:52
  • ah, thank you, I read a little about that but didn't get a chance to read it over, great answer, much appreciated!
    – Joe D
    Commented Sep 17, 2016 at 1:26

It uses udisks. (FUSE is used in the case of network filesystems however). Command-line interfaces to udisks are available for your experimentation. In recent versions it comes with the command-line interface udisksctl.

udisksd runs as root, and accepts the user requests using D-Bus.

udisksd uses PolicyKit PolKit to decide which requests are permitted. Some may require extra privilege e.g. formatting internal drives. This can involve an extra authentication step - similar to Windows UAC prompt, or sudo on the command line. I don't know exactly how the extra authentication is co-ordinated.

Requests over D-Bus are currently made using Unix sockets using SCM_CREDENTIALS, which identifies the process making the request.

One of the factors used in decisions is whether the user is logged in locally, or over the network (e.g. ssh). I believe this information is provided by systemd-logind (in conspiracy with pam-systemd).

  • 1
    udisksctl mount -b /dev/sda1
    – loxaxs
    Commented Jul 1, 2017 at 15:05

Another solution is thru Polkit... Edit /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy

Change everywhere:


... With :


Or otherwise, create a rule : Edit or create: /etc/polkit-1/rules.d/50-udisks.rules

polkit.addRule(function(action, subject) {
  var YES = polkit.Result.YES;
  var permission = {
    // only required for udisks1:
    "org.freedesktop.udisks.filesystem-mount": YES,
    "org.freedesktop.udisks.filesystem-mount-system-internal": YES,
    "org.freedesktop.udisks.luks-unlock": YES,
    "org.freedesktop.udisks.drive-eject": YES,
    "org.freedesktop.udisks.drive-detach": YES,
    // only required for udisks2:
    "org.freedesktop.udisks2.filesystem-mount": YES,
    "org.freedesktop.udisks2.filesystem-mount-system": YES,
    "org.freedesktop.udisks2.encrypted-unlock": YES,
    "org.freedesktop.udisks2.eject-media": YES,
    "org.freedesktop.udisks2.power-off-drive": YES,
    // required for udisks2 if using udiskie from another seat (e.g. systemd):
    "org.freedesktop.udisks2.filesystem-mount-other-seat": YES,
    "org.freedesktop.udisks2.encrypted-unlock-other-seat": YES,
    "org.freedesktop.udisks2.eject-media-other-seat": YES,
    "org.freedesktop.udisks2.power-off-drive-other-seat": YES
  if (subject.isInGroup("users")) {
    return permission[action.id];

Then reboot!

You must log in to answer this question.

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