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

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.

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

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.

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

* Support GVFS for auto-mount handling on removable devices

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

Also xfe does mount/umount.

Ozi

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.

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

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.

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.

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".

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.

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.

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.

Geoff