Description of problem: Burnt dvd with k3b & closed it. Eject & insert dvd
Cannot mount volume
"Error org.freedesktop.Hal.PermissionDenied" Not in active session
50% (it's not the 1st time this happens)
another report here
I'm still unable to mount USB, CD or DVD because permissin denied for HAL. This
works under root account but not under normal user.
The system is up-to-date development tree (5/23/2007).
This seems that there is similar already closed bug #240654. It does not work
even SELinux in targeted and permissive mode.
Milan, I think you meant bug #229465 :)
Anyway, I'm bitten by this, too, so I'm attaching a few (hopefully) relevant
pieces of information:
* ConsoleKit service is running
* SELinux in permissive mode, but no avc denials in /var/log/messages
* $XDG_SESSION_COOKIE does not exist
* I'm logged via gdm
# cat /var/lib/hal/acl-list
/dev/adsp u 42
/dev/audio u 42
/dev/dsp u 42
/dev/mixer u 42
/dev/sequencer u 42
/dev/sequencer2 u 42
/dev/snd/controlC0 u 42
/dev/snd/pcmC0D0c u 42
/dev/snd/pcmC0D0p u 42
/dev/snd/pcmC0D1p u 42
/dev/snd/pcmC0D2c u 42
/dev/snd/seq u 42
/dev/snd/timer u 42
I have the same problem. Here are my infos:
I have disabled SELinux trying to see if this is an SELinux problem, but still
Before this automount feature works flawlessly (I think Test1 and Test2) until
last week when I was trying to backup my data using USB flash disk. I am up to
date with the latest releases.
Original Fedora 7 Test 4 does not have the problem so the bug is inside latest
devel tree change since F7t4 release.
I tryed to downgrade gdm and hal* packages to the versions from F7t4
(gdm-2.18.0-11.fc7, hal-0.5.9-5.fc7, ConsoleKit has not been changed since F7t4)
but it did not helped. Latest sync with current devel tree did not helped too.
I don't know what package may caused the problem with hal.permissiondenied.
Created attachment 155662 [details]
The list of packages for update from pure F7t4 to the latest devel tree
One of the package listed in the update list causes hal.permission denied
problem. But I don't know which of them... :-(
I tryed to downgrade gnome-session, gnome-vfs2, gnome-volume-manager and
notification-daemon with no luck.
The debug messages from HAL daemon:
11:08:37.156 [I] blockdev.c:127: Add callouts completed
11:08:37.156 [I] hald.c:103: Added device to GDL;
11:08:37.214 [W] ci-tracker.c:235: Error doing GetSessionForUnixProcess on
ConsoleKit: org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.ConsoleKit was not provided by any .service files
11:08:37.214 [I] hald_dbus.c:4477: Caller ':1.37' does not have access to device
My guess is that gdm is the culprit. Does this work if you go to runlevel 3 (as
root: 'telinit 3'), log in on the console and startx?
I solved the problem by running ConsoleKit daemon before HAL daemon (ie full
reboot instead start/stop cycles). So this was my fault, sorry.
The problem is that HAL daemon does not report more closely where the problem is
or does not suggest what I have to check. The second problem is that ConsoleKit
daemon died sometimes when I walked from runlevel 5 to 3 and back with
ConsoleKit start/stop (will try to reproduce and fill separate BZ).
OK, so I can close this bug. (and yes, hald could use better error reporting)
How about the rest of the reporters who aren't using ConsoleKit? Don't think its
ok to close.
Since it's not 100% reproductible, I can't test without gdm. One could try
running without it for a few weeks and see if error still occurs to test..
(In reply to comment #10)
> How about the rest of the reporters who aren't using ConsoleKit? Don't think its
> ok to close.
Uhm, hal requires ConsoleKit; it's not an option not to use it if you want to
use the hal built for Fedora.
> Since it's not 100% reproductible, I can't test without gdm. One could try
> running without it for a few weeks and see if error still occurs to test..
Yes, and as you correctly said that (e.g. CK crashing) should be filed against
ConsoleKit, not hal.
Thanks for reply David,
I didn't know about CK being pushed to us :)
Ok, so I have in rc.d:
$ ls *Cons*
$ ls *hal*
(I haven't made any changes to order), which fixes it for Milan but still
doesn't work for me sometimes. SElinux is disabled.
It's ok to leave this closed now. When it happens again for me, what information
should I save & provide?
When you experience a problem, try run: /etc/init.d/ConsoleKit status
The console-kit-daemon should be running.