[Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

msi · 2017-02-04 18:05:50

I'm having trouble managing access to removable media for normal users on Devuan Jessie.

I first installed Devuan without any graphical user interface and then built on that. As I didn't install a full-featured desktop environment (using stand-alone Openbox), removable media access for normal users is not handled correctly out of the box and should be manually configured through polkit. The question is: How?

Without further configuration, I'm unable to mount external USB drives through my file manager (PCManFM/Thunar). I can, however, mount a CD-ROM, but have no permission to unmount it. It is also possible to mount USB devices through the file manager with usbmount. But unmounting still doesn't work then and I would rather not use usbmount.

What I want is this:

enable normal users to mount/unmount removable media through the file manager using udisks2 on the basis of a reasonable polkit rule applying to the "storage" group (which I've already created using addgroup)
mount devices to /media/[current_user]/[label] (which is what udisks2 does)

I'm already able to (un)mount removable USB devices with correct file permissions using udisksctl via the command line. But I always have to give my root password. So, this all comes down to a permission problem and writing the correct polkit rule.

Drawing on the info at https://github.com/coldfix/udiskie/wiki … #policykit, I created a file in /etc/polkit-1/localauthority/50-local.d, named it 10-udisks.pkla and put the following lines into it:

[udisks2]
Identity=unix-group:storage
Action=org.freedesktop.udisks2.filesystem-mount;org.freedesktop.udisks2.encrypted-unlock;org.freedesktop.udisks2.eject-media;org.freedesktop.udisks2.power-off-drive
ResultAny=yes

Unfortunately, after rebooting the machine, nothing has changed. What could I be doing wrong?

Last edited by msi (2017-03-05 22:30:47)

ralph.ronnquist · 2017-02-04 20:24:23

What was wrong with using pmount/pumount ?

msi · 2017-02-04 22:26:09

ralph.ronnquist wrote:

What was wrong with using pmount/pumount ?

Well, I don't know how to make PCManFM use pmount for (un)mounting removable media. Also, udisks2 in conjunction with polkit seems to be sort of the standard way to handle this. I really like the per-user mount points feature in udisks2, too.

Last edited by msi (2017-02-11 20:40:04)

ralph.ronnquist · 2017-02-05 03:15:27

Not sure what 'the standard way' means to you, but for example, the group name 'storage' is not listed at https://wiki.debian.org/SystemGroups. I suppose, that might not be normative for Devuan, since Devuan is not Debian, but to me it implies that polkit is not standard.

In any case, whether standard or not doesn't help towards your problem, which rather seems to be, how to configure udisks and/or polkit to work the way you want.

Geoff 42 · 2017-02-05 11:32:22

Alternatively you could use Spacefm instead of PCManFM. SpaceFM is able to use udevil to mount and unmount file systems when they are plugged in. See the thread at https://dev1galaxy.org/viewtopic.php?pid=449#p449.

Geoff

msi · 2017-02-05 16:55:53

ralph.ronnquist wrote:

Not sure what 'the standard way' means to you, but for example, the group name 'storage' is not listed at https://wiki.debian.org/SystemGroups. I suppose, that might not be normative for Devuan, since Devuan is not Debian, but to me it implies that polkit is not standard.

You are right about storage not being a standard group. But that's not connected to policykit. You could use the plugdev group instead. The storage group was part of the pre-systemd setup in Arch Linux, it's purpose being to grant "access to removable drives such as USB hard drives, flash/jump drives, MP3 players" and "enable the user to mount storage devices." (https://wiki.archlinux.org/index.php/Us … emd_groups) Thinking about it again, there's actually no reason to create the storage group at all. So, I deleted it and substituted "storage" with "plugdev" in /etc/polkit-1/localauthority/50-local.d/10-udisks.pkla.

Also, I found out that the kind of problems I was having can arise from starting X directly from a tty, which I normally do. There seem to be ways to fix this by creating a reasonably equipped ~/.xinitrc file. As my attempts to do that weren't successful, I simply gave XDM a shot. Et voilà, apparently this made things work. I then removed XDM with apt-get purge and also deleted ~/.xinitrc, since I don't normally need it. Surprisingly, (un)mounting and accessing USB drives through PCManFM and Thunar still worked flawlessly, which had me think that it doesn't actually have anything to do with XDM, which hadn't pulled any dependencies on installation.

So, now I was able to handle USB devices through PCManFM. What still didn't work, were CDs. Just as before, I was able to mount a CD but unable to unmount it. Also, CDs were being mounted to /media/cdrom0, which probably means they are not being handled by udisks2.

Then I tried SpaceFM and udevil. That totally worked. However, I needed to give apt "adwaita-icon-theme-", so it wouldn't pull a whole lot of stuff I don't need. The latter had already been an issue throughout the installation process of my Devuan system.

Any ideas on how to solve the CD unmounting problem in PCManFM? I'm not sure if I want to go with SpaceFM. I'm used to working with PCManFM and it was able to handle CDs correctly on very much the same setup in Debian Jessie.

PS: I think there should be a removable media guide for minimal desktops.

Last edited by msi (2017-03-05 15:40:41)

msi · 2017-02-11 20:37:11

After tinkering with udisks2, udisks, udevil, SpaceFM and PCManFM for several hours on a testing machine as well as on my main system, installing and removing packages back and forth, I discovered that the solution to not being able to unmount CDs should be very simple. It's obviously about getting the policykit rules for udisks2 right in the local authority file in /etc/polkit-1/localauthority/50-local.d (which I've chosen to rename 10-removable_storage.pkla).

If I simply allow members of the plugdev group to perfom any udisks2 action, then I'm also able to unmount and eject CDs through PCManFM without any problem. To achieve this, /etc/polkit-1/localauthority/50-local.d/10-removable_storage.pkla needs to look like this:

[udisks2 permissions]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2*
ResultAny=yes
ResultActive=yes
ResultInactive=yes

However, allowing everything is never a good choice. In this case, allowing any udisks2 action to be performed by members of the plugdev group enables me to unmount system partitions as an unprivileged user. Though this isn't possible through PCManFM since it doesn't display the partitions of my hard drive as seperate devices, I can use the udisksctl commandline utility to do it. As an example, I unmounted and remounted my /boot partition:

msi@moon:~$ udisksctl unmount -b /dev/sda1
Unmounted /dev/sda1.

msi@moon:~$ udisksctl mount -b /dev/sda1
Mounted /dev/sda1 at /boot.

I was also able to force my in-use /home partition to be unmounted during normal system operation, just by adding the "-f" parameter. To fully comprehend the infernal security disaster created by the above, you might want have a look into the list of all udisks2 policykit actions that have now been unleashed to play with for anyone on the system (see https://udisks.freedesktop.org/docs/lat … ions-file).

So the question now is, which udisks2 rules have to be put into policykit's local authority file to enable normal users to handle CDs without enabling them to crash the system at the same time.

By the way, all of the above also works for Thunar.

On a side note, I can also confirm now that installing XDM has no part in making this work.

PS: Don't forget to install cryptsetup in case you want to (un)lock encrypted drives through the file manager.

Last edited by msi (2017-02-11 21:14:11)

msi · 2017-02-11 23:20:58

I've now found a way to unmount CDs using a bit of a less insecure (though still unsane) configuration. Going through the list of available policykit actions for udisks2, I discovered that allowing "org.freedesktop.udisks2.filesystem-unmount-others" in addition to all the actions allowed in the setup I began with makes it possible to unmount CDs as well.

So, /etc/polkit-1/localauthority/50-local.d/10-removable_storage.pkla currently looks like this:

[udisks2 permissions]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2.filesystem-mount;org.freedesktop.udisks2.encrypted-unlock;org.freedesktop.udisks2.power-off-drive;org.freedesktop.udisks2.eject-media;org.freedesktop.udisks2.filesystem-unmount-others
ResultAny=yes
ResultActive=yes
ResultInactive=yes

The description for "org.freedesktop.udisks2.filesystem-unmount-others" reads: "Unmount a device mounted by another user". Therefore, this configuration will enable unprivileged users to unmount anything (if they are in the plugdev group), but that's it.

The question this inevitably leads to is: Why would a CD be mounted by another user than the one asking the file manager to mount it? The thing is that this doesn't even seem to be the case. When I check the list of mounted devices with mount after mounting the CD, I get this:

/dev/sr0 on /media/cdrom0 type iso9660 (ro,nosuid,nodev,noexec,relatime,user=msi)

When I delete "org.freedesktop.udisks2.filesystem-unmount-others" from the local authority file and then try to unmount a CD via udisksctl, this happens:

msi@moon:~$ udisksctl unmount -b /dev/sr0
==== AUTHENTICATING FOR org.freedesktop.udisks2.filesystem-unmount-others ===
Authentication is required to unmount HL-DT-ST DVDRAM GH22NS50 (/dev/sr0) mounted by another user
Authenticating as: root
Password:

Am I missing anything here?

I wonder how desktop environments like LXDE or Xfce solve this.

Last edited by msi (2017-02-12 00:04:53)

msi · 2017-02-26 21:09:10

Not getting anywhere near solving the problem, I installed Debian Jessie on a testing machine to see if the same issue would occur there. Well, it doesn't. Everything works fine with the set of policykit rules I had used in the first place and there is no need to allow "org.freedesktop.udisks2.filesystem-unmount-others".

This seems to be a systemd-related issue. In Debian Jessie, udisks2 depends on libpam-systemd as well as on libsystemd0; the Devuan fork doesn't. So, what now?

As for using SpaceFM as an alternative, I've just been told today on the project's official IRC channel that "development is dead".

golinux · 2017-02-26 21:30:37

FWIW on my Devuan Jessie Xfce, I have both udisks2 and libsystemd0 installed but not libpam-systemd. Drives do not automount but do with a click on a right button menu option of the icon that pops up on my desktop.

msi · 2017-03-05 20:11:39

I've had the developer of udiskie take a look at all this. He suggested that it's not actually a problem with udisks2 but with some other element of PCManFM's mount procedure, possibly gvfs. He told me to try to mount and unmout removable devices through udisksctl without "org.freedesktop.udisks2.filesystem-unmount-others" in place in order to verify that.

As can be seen below, that worked seemlessly:

msi@moon:~$ udisksctl mount -b /dev/sdb
Mounted /dev/sdb at /media/msi/SONY.
msi@moon:~$ udisksctl unmount -b /dev/sdb
Unmounted /dev/sdb.

msi@moon:~$ udisksctl mount -b /dev/sr0
Mounted /dev/sr0 at /media/cdrom0.
msi@moon:~$ udisksctl unmount -b /dev/sr0
Unmounted /dev/sr0.

golinux wrote:

FWIW on my Devuan Jessie Xfce, I have both udisks2 and libsystemd0 installed but not libpam-systemd. Drives do not automount but do with a click on a right button menu option of the icon that pops up on my desktop.

I tried Devuan Jessie with a full installation of LXDE (except for a login manager) today. That didn't change anything for the better. You just can't unmount a CD without giving your root password.

So, what about gvfs then? Well, it uses dbus. Reading through various forum posts, I saw that some people have solved problems with accessing removable devices by creating an .xinitrc file containing

exec dbus-launch [window manager]

The manpage for dbus-launch reads:
"The dbus-launch command is used to start a session bus instance of dbus-daemon from a shell script. It would normally be called from a user's login scripts."

As it seems, gvfs uses dbus as an interface to communicate with other system processes that can then perfom actions like, for example, mount a removable device. However, just starting your X session with startx doesn't provide that interface per se. You have to explicitly request that within your .xinitrc file. For Openbox, it would have to look like this:

exec dbus-launch --exit-with-session openbox-session

This solves the problem, but it also brings a new one in that this configuration – for whatever reason – totally ignores the xterm settings (font size etc.) in my .Xresources file.

Thinkg about and trying to understand what dbus is, it crossed my mind that when there's a dbus interface for the X session, there's probably no need for all those policykit rules I've been amusing myself with lately. So, I shoved aside /etc/polkit-1/localauthority/50-local.d/10-removable_storage.pkla to see what happens. Well, nothing happens and everything works fine – if you count out the xterm issue.

If, maybe, someone could breifly explain dbus, policykit and their relation, that would really help.

fsmithred · 2017-03-05 20:44:11

Good stuff. I'm gonna play with that when I get a chance. I don't have the answer to your last question, but this might be helpful -

https://wiki.archlinux.org/index.php/Xresources

xinitrc
If you are using a copy of the default xinitrc as your .xinitrc it already merges ~/.Xresources.
If you are using a custom .xinitrc add the following line:
[[ -f ~/.Xresources ]] && xrdb -merge -I$HOME ~/.Xresources
Warning: Never background the xrdb command within ~/.xinitrc. Otherwise, programs launched after xrdb may look for resources before it has finished loading them.

msi · 2017-03-05 22:29:52

Thanks for the hint! However, I felt that line looked really complex for doing nothing but pull in settings from ~/.Xresources. And so did other people in the Arch Linux forums (see https://bbs.archlinux.org/viewtopic.php?id=208894).

Actually, it's enough to just put the following into your ~/.xinitrc (running order matters):

xrdb -load ~/.Xresources
exec dbus-launch --exit-with-session openbox-session

You could even omit "-load" since that is xrdb's default action. But that would make the whole thing look unnecessarily cryptic to me.

Btw, my ~/.Xresources file looks like this:

xterm*font:	9x15
xterm*geometry:	100x24
xterm*background: black
xterm*foreground: white

I'm marking this topic als solved. Explanations on dbus and policykit as well as other comments still welcome.

Last edited by msi (2017-03-05 22:37:22)

Ozi · 2017-03-15 02:43:08

PCMan File Manager is a GTK+ based file manager, featuring:

* Support GVFS for auto-mount handling on removable devices

These work for me: gvfs-backends, gvfs-fuse.

Also xfe does mount/umount.

Ozi

msi · 2017-03-24 21:10:26

Ozi, this is not about missing packages. I'm not 100% sure about my following explanation, but it should be alright (i'm ignoring policykit here):

In the above case, the problem was that PCManFM was unable to communicate with gvfs (well, sort of). PCManFM and gvfs use D-Bus, a system for interprocess communication, to communicate with each other. Now, for things like communication between the file manager and gvfs in your X session, D-Bus uses per-user instances of its message bus deamon (visually speaking, one telephone network per user for the communication between the programs this user works with). If you just start X from the command line without further configuration, that message bus deamon won't be started. Therefore, PCManFM won't be able to call gvfs and ask it to mount a device. Putting

exec dbus-launch

into your ~/.xinitrc file instructs the xinit program to start that per-user d-bus deamon for the session and so provide means of communication between PCManFM and gvfs.

Ozi wrote:

Also xfe does mount/umount.

Well, I'd be interested in how Xfe does that.

Last edited by msi (2017-03-24 21:13:19)

rfgmm · 2018-03-04 08:01:22

My Devuan started to missbehave like this after the update of today, I was'nt able to remove mounted external storage devices and to manage the Network, through network-manager-applet.

I fixed the network-manager-applet with a policykit file ... and now I am heading to look about the mounting/unmounting problem

rfgmm · 2018-03-04 08:32:10

msi wrote:

I've now found a way to unmount CDs using a bit of a less insecure (though still unsane) configuration. Going through the list of available policykit actions for udisks2, I discovered that allowing "org.freedesktop.udisks2.filesystem-unmount-others" in addition to all the actions allowed in the setup I began with makes it possible to unmount CDs as well.
So, /etc/polkit-1/localauthority/50-local.d/10-removable_storage.pkla currently looks like this:
[udisks2 permissions]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2.filesystem-mount;org.freedesktop.udisks2.encrypted-unlock;org.freedesktop.udisks2.power-off-drive;org.freedesktop.udisks2.eject-media;org.freedesktop.udisks2.filesystem-unmount-others
ResultAny=yes
ResultActive=yes
ResultInactive=yes

this worked for me, thanks...

I am able to mount external storage again. (and unmount it )
it was the update of today.

Last edited by rfgmm (2018-03-04 08:32:47)

phloggu · 2018-06-01 18:19:52

To make the polkit rules really work in KDE uninstall gvfs and related packages.

vlax · 2020-07-08 18:29:34

msi wrote:

In the above case, the problem was that PCManFM was unable to communicate with gvfs (well, sort of). PCManFM and gvfs use D-Bus, a system for interprocess communication, to communicate with each other. Now, for things like communication between the file manager and gvfs in your X session, D-Bus uses per-user instances of its message bus deamon (visually speaking, one telephone network per user for the communication between the programs this user works with). If you just start X from the command line without further configuration, that message bus deamon won't be started. Therefore, PCManFM won't be able to call gvfs and ask it to mount a device. Putting
exec dbus-launch
into your ~/.xinitrc file instructs the xinit program to start that per-user d-bus deamon for the session and so provide means of communication between PCManFM and gvfs.

thanks for this informative and to learn paragraph,

useful for me since I had problems with automount using Thunar/PcmanFM after I start login to X without lxdm

PS : I think I prefer Thunar

Last edited by vlax (2020-07-09 23:44:26)

The officially official Devuan Forum!

#1 2017-02-04 18:05:50

[Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#2 2017-02-04 20:24:23

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#3 2017-02-04 22:26:09

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#4 2017-02-05 03:15:27

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#5 2017-02-05 11:32:22

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#6 2017-02-05 16:55:53

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#7 2017-02-11 20:37:11

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#8 2017-02-11 23:20:58

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#9 2017-02-26 21:09:10

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#10 2017-02-26 21:30:37

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#11 2017-03-05 20:11:39

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#12 2017-03-05 20:44:11

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#13 2017-03-05 22:29:52

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#14 2017-03-15 02:43:08

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#15 2017-03-24 21:10:26

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#16 2018-03-04 08:01:22

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#17 2018-03-04 08:32:10

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#18 2018-06-01 18:19:52

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

#19 2020-07-08 18:29:34

Re: [Solved] Removable media unaccessible as normal user (PCManFM/Thunar)

Board footer