4

If I would have known how much 'customization' it takes to get LXDE and its default file manager, pcmanfm, just working, I would probably have never chosen to try it.

I've got a problem. Lots of people have it. All of these people report the same problem with pcmanfm. The people in the forums have about half a dozen magic recipes that get it to work finally. But I want to know what's actually causing pcmanfm not to work, because I want to increase my understanding of the way Linux works, not just follow someone's instructions.

I am talking about the rather unhelpful "Not Authorized" window that pops up whenever I insert media.

Lots of people have this problem.

I managed to fix this before. I ended up doing some sort of magic with an xml file. (Was it udisks? Was it polkit-gnome? I don't know, but they're both on the list of magic recipes for solving this issue.) I changed every entry that said something to say something else. And finally, I could see my media. (I couldn't even mount it manually I should add.)

I fixed it before and... What happened? I used apt-get, installed a new package (udev, because I was trying to fix other mounting issues that it seems people stopped having when hal became deprecated), and bang, the problem's back.

So, I must like torment, because it's certainly in the cards.

This is not an easy answer question. If you didn't click any of the links above, you won't be able to tell what I'm talking about.

My question is, what's at the bottom of this? At a real, bare bones, we built these systems on top of Unix and sometimes they don't work as well as the original Unix level?

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
ixtmixilix
  • 13,040
  • 27
  • 82
  • 118
  • Not sure about debian, but Arch Linux now ships with udisks2, so the interface names in polkit must be changed. – daisy Oct 22 '12 at 10:19

3 Answers3

7

Firstly, make sure that dbus and consolekit are running -- usually this means prepending ck-launch-session dbus-launch to your exec statement.

You will also want to check that your user is in the storage group (you can check with groups). Most distributions ship with the storage group's policies configured on install, but in case they aren't, you may want to try rolling your own policy (it is possible that this was removed/modified when udev was upgraded).

[[ -d /etc/polkit-1/localauthority/50-local.d ]] || mkdir -p /etc/polkit-1/localauthority/50-local.d
cat > /etc/polkit-1/localauthority/50-local.d/99-allow_storage_mount.pkla << 'EOF'
[Storage Permissions]
Identity=unix-group:storage
Action=org.freedesktop.udisks.filesystem-mount;org.freedesktop.udisks.drive-eject;org.freedesktop.udisks.drive-detach;org.freedesktop.udisks.luks-unlock;org.freedesktop.udisks.inhibit-polling;org.freedesktop.udisks.drive-set-spindown
ResultAny=yes
ResultActive=yes
ResultInactive=no
EOF
Chris Down
  • 122,090
  • 24
  • 265
  • 262
  • 2
    For the record, in case anybody else Googleing desperately for the answer gets here. I'm on Arch Linux and I had to _remove_ `ck-launch-session` from my `~/.xinitrc` to get rid of the "Not Authorized" window. – Thorbjørn Lindeijer May 13 '12 at 09:15
  • 2
    I found out why. When upgrading 'slim' from 1.3.2 to 1.3.3, you have to remove this to avoid nested ConsoleKit sessions. See https://wiki.archlinux.org/index.php/ConsoleKit#ck-launch-session and https://wiki.archlinux.org/index.php/SLiM – Thorbjørn Lindeijer May 13 '12 at 09:21
1

I had recently the same issue with LXDE on Debian testing.

At the end @jw013 showed me a bug (see this question), where one can understand that the problem is that XDM and some other Display Manager do not talk with ConsoleKit, and do not set the correct information for PoliciKit (in particular the session results as inactive).

I solved all my authorization problems switching to a different Display Manager, in my case LightDM, but I'm sure that also GDM is good for this.

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
enzotib
  • 50,671
  • 14
  • 120
  • 105
0

The bottom of this is, people write software in their own ways, making their own assumptions. When the assumptions made by one application is different from that of another application, the two applications won't work out of the box with each other. That's why there are package maintainers for each OS distribution. One of the tasks of a maintainer is to patch applications so that they will work together. Assumptions can and will change, so things will break at times, before the maintainers have time to patch it.

In your case, I'd think that the maintainers (are there maintainers or are you gluing things together yourself?) missed a change in the XML config file, or that the testers missed this use case. Depending on the situation you can either wait until the maintainers find out and fix it, or fix it and forget it, or report it to a bug tracker if it's available, or get the source code and code up a patch :)

phunehehe
  • 20,030
  • 27
  • 99
  • 151