Red Hat Bugzilla – Bug 427748
removable media (cd, dvd, usb) fail to automount with org.freedesktop.DBus.Error.AccessDenied
Last modified: 2013-03-05 22:54:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; pl-PL; rv:184.108.40.206) Gecko/20071128 Fedora/220.127.116.11-2.fc7 Firefox/18.104.22.168
Description of problem:
After inserting a CD into the drive, a window with the following message pops up:
Can't mount volume.
A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.Hal.Device.Volume" member "Mount" error name "(unset)" destination "org.freedesktop.Hal")
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Insert removable media
Media fails to mount and an error message pops up.
Media should mount successfully, like it did on F-7.
I've found similar problems described on the web, but the proposed solutions, i.e. modifying /etc/dbus-1/system.d/hal.conf to allow a particular group to access removable volumes yielded no results.
Need a lot more detail..
1. are you using GNOME, KDE or other desktop?
2. are you using gdm, kdm or startx?
3. how are you seeing this error? (are you using dbus-send or gnome-mount?)
4. is the ConsoleKit service running?
from a terminal within your desktop session, what does
(In reply to comment #1)
> Need a lot more detail..
> 1. are you using GNOME, KDE or other desktop?
> 2. are you using gdm, kdm or startx?
> 3. how are you seeing this error? (are you using dbus-send or gnome-mount?)
I don't know what is used when I simply insert the media, but I do get the same
error when using gnome-mount.
> 4. is the ConsoleKit service running?
> from a terminal within your desktop session, what does
> echo $XDG_SESSION_COOKIE
I'm not near the machine right now, I'll post this information tomorrow.
(In reply to comment #2)
> (In reply to comment #1)
> > from a terminal within your desktop session, what does
> > echo $XDG_SESSION_COOKIE
> > say?
Looks like one of the recent updates fixed that. I'll reopen if it happens again.