Is it possible to allow some particular users (e.g. members of a group) to mount any filesystem without superuser privileges on Linux?

Another question might have been "in what ways a user can harm a system by mounting filesystems?"


10 Answers 10


There are a couple approaches, some of them mostly secure, others not at all.

The insecure way

Let any use run mount, e.g., through sudo. You might as well give them root; it's the same thing. The user could mount a filesystem with a suid root copy of bash—running that instantly gives root (likely without any logging, beyond the fact that mount was run).

Alternatively, a user could mount his own filesystem on top of /etc, containing his/her own copy of /etc/shadow or /etc/sudoers, then obtain root with either su or sudo. Or possibly bind-mount (mount --bind) over one of those two files. Or a new file into /etc/sudoers.d.

Similar attacks could be pulled off over /etc/pam.d and many other places.

Remember that filesystems need not even be on a device, -o loop will mount a file which is owned (and thus modifiable) by the user.

The mostly secure way: udisks or similar

The various desktop environments have actually already built solutions to this, to allow users to mount removable media. They work by mounting in a subdirectory of /media only and by turning off set-user/group-id support via kernel options. Options here include udisks, udisks2, pmount, usbmount,

If you must, you could write your own script to do something similar, and invoke it through sudo—but you have to be really careful writing this script to not leave root exploits. If you don't want your users to have to remember sudo, you can do something like this in a script:

if [ $UID -ne 0 ]; then       # or `id -u`
    exec sudo -- "$0" "$@"

# rest of script goes here 

The will-be-secure someday way: user namespaces

Linux namespaces are a very lightweight form of virtualization (containers, to be more specific). In particular, with user namespaces, any user on the system can create their own environment in which they are root. This would allow them to mount filesystems, except that has been explicitly blocked except for a few virtual filesystems. Eventually, FUSE filesystems will probably be allowed, but the most recent patches I could find don't cover block devices, only things like sshfs.

Further, many distro kernels have (for security reasons) defaulted to not allowing unprivileged users to use user namespaces; for example Debian has a kernel.unprivileged_userns_clone that defaults to 0. Other distros have similar settings, though often with slightly different names.

The best documentation I know of about user namespaces is an LWN article Namespaces in operation, part 5: User namespaces.

For now, I'd go with udisks2.

  • Thanks for your answer! BTW, would you reckon it is secure to allow users in the group mount to be able to mount filesystems like root does? I will read the namespaces document you've linked, and try to implement this mount group thing, at least as an exercise.
    – user27225
    Commented Oct 18, 2013 at 16:16
  • 1
    @derobert since you were talking about user namespaces, you may want to check out Plan 9 from Bell Labs (it's the successor to UNIX, made by the same people). it models the file tree as a per-process namespace (and there's no such thing as root). fascinating stuff.
    – strugee
    Commented Oct 21, 2013 at 4:11
  • 2
    @derobert Can we get an update on the "The will-be-secure someday way: user namespaces" section?
    – mas
    Commented Jan 4, 2019 at 14:07
  • 2
    @malan OK, I've updated it. If anything, I think using user namespaces for this looks to be even further into the future.
    – derobert
    Commented Jan 4, 2019 at 19:08
  • 4
    @derobert How sad. I read the answer, saw it was from 2015, and thought "I wonder if we have this now!"
    – mas
    Commented Jan 5, 2019 at 13:54

You can do it, but you need to modify the entry in /etc/fstab corresponding to the filesystem you want to mount, adding the flag user to this entry. Non-privilege users would then be able to mount it.

See man mount for more details.

  • 1
    This is the only answer I can find with googling. I have found out that on FreeBSD, one can allow users to mount filesystems with setting a variable (namely vfs.usermount). I want sth. analogous to that. I use many removable drives with many partitions on each and it would be cumbersome to add a dozen or two entries to fstab for each of them.
    – user27225
    Commented Oct 18, 2013 at 14:43
  • Ugly workaround could be to let udev manage the entries as new devices appear and disappear.
    – Jester
    Commented Oct 18, 2013 at 14:44
  • i have not found this to work on Mint or Ubuntu. Yes, the default user account can mount without root, but 'standard'/'desktop' users cannot mount it.
    – johny why
    Commented Jun 8, 2015 at 7:24
  • 1
    The users option might be useful too. Commented Jun 16, 2020 at 8:52

Here is the wiki for configuring polkit rules for udisks/udisks2 in order to mount partitions by non-root (e.g. users) group.

Save the code below to /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];

Assume you are in the "users" group, using the following command to mount a partition (no need sudo).

# udisks2
udisksctl mount --block-device /dev/sda1

# udisks
udisks --mount /dev/sda1
  • 2
    Seems like the way to go but did not work for me. Commented Mar 18, 2016 at 17:16
  • How do I make this work on 18.04? I've read that .conf files require polkit 0.106, while Ubuntu 18.04 ships 0.105.
    – Marcus
    Commented Nov 24, 2019 at 14:44
  • worked for me. I was trying to mount partitions in Dolphin(Fedora 31,KDE) and getting password prompt. I just replaced 'users' with 'wheel'. If you are in storage group, you can write 'storage' there. Commented Dec 1, 2019 at 19:11

1 Look where it works

On Xubuntu it works out of the box to mount and eject USB mass storage, hard disk partitions, CD/DVDs and probably more.

Let's assume that the solution Ubuntu chose, using policyKit, is secure enough.

2 Pick the relevant part

On XFCE on Debian 8.3 I needed to allow user to mount and eject filesystems from thunar without password. What worked for me is to cherry-pick a permission file from Ubuntu.

Adding the lines below as root to a file named /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla should do the trick:

[Mounting, checking, etc. of internal drives]

3 Profit!

(What I did actually was pick a little more from the file with same name on Ubuntu 16.04 and it worked for me. If you need it, it mostly looks like the content of https://gist.github.com/kafene/5b4aa4ebbd9229fa2e73 )

  • 1
    Only this works in debian like systems, don't know why putting rules on /etc/ didn't work.
    – Anwar
    Commented Feb 10, 2019 at 5:33
  • Does not work on debian stretch. Commented Apr 15, 2019 at 8:35
  • 1
    Works on Debian Buster on XFCE! Thanks! Commented Sep 27, 2019 at 14:38

You can configure sudo to allow a set of users to run the mount command.

Update: as to how you can damage a system by mounting? For example, you can create a setuid root shell on a filesystem which you can then mount and execute to get root privileges.

  • I have thought of this, but won't this require the user to run the command with sudo? Also, isn't it the root user mounting the file system, only behind the scenes, with this method?
    – user27225
    Commented Oct 18, 2013 at 14:32
  • Yes, they would need sudo and yes it would run in the name of root. To solve the first issue, you could alias mount to sudo mount or use a wrapper script.
    – Jester
    Commented Oct 18, 2013 at 14:43
  • What I would like to have is to mount the filesystem without the agency of the root user. Masking this agency with anything is not what I'm after at all.
    – user27225
    Commented Oct 18, 2013 at 14:48
  • Note that even adding user to fstab only works because mount is setuid root. The kernel is checking for root or CAP_SYS_ADMIN capability so you can't really get around involving root.
    – Jester
    Commented Oct 18, 2013 at 14:51
  • You can configure, how? This doesn't help.
    – Nuzzolilo
    Commented Jan 1, 2016 at 8:23

Simple secure way without sudo, acl, etc...

Look for to which group device file belongs to

ls -l /dev/sda2                                                                                                                                                                
brw-rw---- 1 root disk  /dev/sda2

Saw that device file belongs to group disk

Now add our user to group disk

usermod -G disk -a username

And now in /etc/fstab

/dev/sda2   /mnt/backups    ext4    noauto,group,suid,dev,async      0   2

or with UUID

UUID=c90324c1-3fba-119c-913c-5f913afdca8b   /mnt/backups    ext4    noauto,group,suid,dev,async      0   2

Now all users in group disk, for now it's only username, can mount certain disk.

  • disk group membership give access to all disks on system, better to set group membership on mount point aka /mnt/backups but then you have to be root to mount.
    – MortenB
    Commented Feb 25, 2020 at 15:46

guestmount libguestfs trickery

sudo apt-get install libguestfs-tools

# Workarounds for Ubuntu 18.04 bugs.
# https://serverfault.com/questions/246835/convert-directory-to-qemu-kvm-virtual-disk-image/916697#916697
sudo rm -rf /var/cache/.guestfs-*
echo dash | sudo tee /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/zz-dash-packages
sudo chmod +r /boot/vmlinuz-*

# Create a test image.
mkdir sysroot
dd if=/dev/urandom of=sysroot/myfile bs=1024 count=1024
virt-make-fs --format=raw --type=ext2 sysroot sysroot.ext2

# Mount it, have fun, unmount!
mkdir -p mnt
# /dev/sda becuase we have a raw filesystem.
guestmount -a sysroot.ext2.qcow2 -m /dev/sda mnt
cmp sysroot/myfile mnt/myfile
guestunmount mnt

Relies on:

  • userland implementation of the filesystems
  • FUSE

Docs: http://libguestfs.org/guestmount.1.html

Tested on Ubuntu 18.04, libguestfs-tools 1:1.36.13-1ubuntu3.


To answer your question in parenthesis, since a filesystem is a placeholder for files, then a user can potentially carry out harmful operations on that filesystem, such as delete files.

Summarising the other 2 questions I will say this:

  • fstab is great for mounting at boot time permanent storage. It is not so great when you want to plug in usb drives or mount occasionally some network shares.

  • sudo mount is also alright if you are on ubuntu* systems. You will still need to type in a password though.

  • udev will take care of mounting things like usb sticks, cameras and flash cards in ubuntu* systems (but not in less user friendly distros like debian, slackware, etc)

I'll add that, historically, the unix way to give authority to some users (or groups) to do stuff is through the sudoers file.

There are MANY guides to use it out there so I will not suggest any particular. I will say that I used the Linux documentation project website to learn about it.

What is more with sudoers is that you can mount devices and shares transparently - even without providing a password if you choose to do so (be extra careful about that).

What I usually do in a control environment is I use sudoers file to allow users of certain group to mount network shares transparently. So I add the commands mount.nfs and mount.cifs in the sudoers file that allowing operations such as "mount the home folder of user from a network file server, when the user logs on to a client terminal" and studd like that.

  • 1
    If you're using sudo to let user's mount their home folders upon login, you should look at autofs.
    – derobert
    Commented Oct 18, 2013 at 16:11
  • I use these together; I could not figure out how to use autofs on its own to mount the /home/$USER from the fileserver, to the location /home/$USER/fromFS/ on the client pc.
    – nass
    Commented Oct 18, 2013 at 16:15

I'am on ubuntu 22.04

My root mount in fstab is like this: UUID=myuuid / ext4 errors=remount-ro,user=owner 0 1

So, i dont have a owner user into passwd conf file, but i think this owner is the absolute owner of the mount point (directory) ... / has root owner /home/whateveruser has whateveruser owner /media/myuser/mypendrive has myuser owner

We dont need to specify user=listofusers. Owner is sufficient to get root and effective logged user(s)

My usb 3.0 pendrive is getting almost 200 MB transfer rate, after i set user=owner at / ext4 mount point.

I dont know if that works like i said, but i can boot with no mount errors nor systemd errors ;)


Maybe we could use this options:

user=owner (root, disk, whatever directory owner) and/or group=owner (root, disk, whatever directory owner)

owner is whatever authenticated user from group(x)

we know / is owned by root /home/myuser us owned by myuser etc ...

Mounting respecting individual directory permissions match

  • we have to match mount point owner with directory owner ;) owner user|group Commented Nov 26, 2022 at 20:55

You must log in to answer this question.