I can see from your ck-list-sessions output that you are correctly identified as both "local" and "active". That rules out any problems with the consolekit authentication mechanism I think.
The most likely cause now, in my experience with this problem, is you have competing sub-systems fighting over who gets to mount and unmount USB drives. The likely culprits are HAL and udisks2. udisks2 _should_ win, but having HAL on your system is complicating things. Try watching your system log while plugging and unplugging your drive. You should see something like this when you plug in, mount (using your file manager) and then unmount: [root@Bathtub x86_64]# tailf /var/log/messages <snip> Jun 10 12:59:05 Bathtub kernel: usb 2-8.3: new high-speed USB device number 11 using ehci_hcd Jun 10 12:59:05 Bathtub kernel: usb 2-8.3: New USB device found, idVendor=0951, idProduct=1625 Jun 10 12:59:05 Bathtub kernel: usb 2-8.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jun 10 12:59:05 Bathtub kernel: usb 2-8.3: Product: DT 101 II Jun 10 12:59:05 Bathtub kernel: usb 2-8.3: Manufacturer: Kingston Jun 10 12:59:05 Bathtub kernel: usb 2-8.3: SerialNumber: 0019E06B0845F95067600260 Jun 10 12:59:05 Bathtub kernel: scsi14 : usb-storage 2-8.3:1.0 Jun 10 12:59:05 Bathtub kernel: scsi 14:0:0:0: Direct-Access Kingston DT 101 II 1.00 PQ: 0 ANSI: 2 Jun 10 12:59:05 Bathtub kernel: sd 14:0:0:0: [sdh] 7827392 512-byte logical blocks: (4.00 GB/3.73 GiB) Jun 10 12:59:05 Bathtub kernel: sd 14:0:0:0: [sdh] Write Protect is off Jun 10 12:59:05 Bathtub kernel: sd 14:0:0:0: [sdh] Incomplete mode parameter data Jun 10 12:59:05 Bathtub kernel: sd 14:0:0:0: [sdh] Assuming drive cache: write through Jun 10 12:59:05 Bathtub kernel: sd 14:0:0:0: [sdh] Incomplete mode parameter data Jun 10 12:59:05 Bathtub kernel: sd 14:0:0:0: [sdh] Assuming drive cache: write through Jun 10 12:59:05 Bathtub kernel: sdh: sdh1 Jun 10 12:59:05 Bathtub kernel: sd 14:0:0:0: [sdh] Incomplete mode parameter data Jun 10 12:59:05 Bathtub kernel: sd 14:0:0:0: [sdh] Assuming drive cache: write through Jun 10 12:59:05 Bathtub kernel: sd 14:0:0:0: [sdh] Attached SCSI removable disk Jun 10 12:59:24 Bathtub udisksd[1653]: Cleaning up mount point /run/media/richard/KINGSTON (device 8:113 is not mounted) Jun 10 12:59:24 Bathtub udisksd[1653]: Unmounted /dev/sdh1 on behalf of uid 501 Jun 10 13:00:01 Bathtub kernel: sdh: detected capacity change from 4007624704 to 0 Try this yourself and post the output here. A very similar bug was logged against Cauldron in Jan/Feb of this year. It is still open, I believe. In any event, I still have the same problem as you report unless I work around it by doing the following: If it is installed then remove udisks If it is installed then remove hal; that will take away perl-Hal-Cdroms too, which is ok make sure you DO NOT have an entry in /etc/fstab for your CDROM ref: Bug 4642, Bug 3533, Bug 4645, Bug 5051 Richard On 10/06/2012, andre999 <[email protected]> wrote: > Len Lawrence a écrit : >> On 10/06/12 10:59, andre999 wrote: >>> Len Lawrence a écrit : >>>> Mageia 2 fully updated >>>> GNOME Classic >>>> >>>> This is probably a newbie question.... I am not sure when this >>>> started to happen but when, as a user, I try to unmount a USB drive >>>> via the desktop icon I am told that I am not authorized to perform >>>> that operation. After browsing bugzilla and the forums it looked >>>> like the best way to get past this would be to use sudo. However, >>>> editing the sudoers file always throws up a syntax error. I have >>>> tried various commands based on examples but cannot get any to work. >>>> >>>> e.g. >>>> >>>> ALL /bin/umount NOPASSWD >>>> %users /bin/umount NOPASSWD >>>> %users localhost=/bin/umount NOPASSWD >>>> >>>> What is the correct recipe? RTFM only makes my old brain spin. >>>> >>>> Len >>>> >>> >>> try : >>> >>> %users ALL=/bin/umount NOPASSWD: ALL >>> >>> or maybe : >>> >>> %users ALL=/bin/umount device NOPASSWD: ALL >>> >>> where "device" is whatever the usb drive is mounted as. >>> Not workable if "device" is variable. >>> >>> Alternately, you could do : >>> su >>> (enter password) >>> umount ... >>> >>> As to why you are having the problem : >>> It means that the drive was mounted with root privileges, or the >>> privileges of another user. >>> Thus it is requiring root privileges (or that of the other user) to >>> unmount. >>> >>> Was it plugged it when the system was booted ? That could cause it to >>> have root privileges. >>> Is it in a line the /etc/fstab file ? >>> (if so, you just have to add the option "users" in the >>> comma-separated list in the third position in the line.) >>> >>> Or it could be a bug. >>> >> A bug seems doubtful because there do not seem to be any other reports >> of this behaviour. I have been forced to take the direct su/password >> route. >> >> The medium was plugged in at boot time but has been removed and >> replugged a few times. I had not considered that point. What you are >> saying is that removable media are treated as fixed if already plugged >> in at boot time? This is starting to make sense. > > It has happened to me in the past, although currently I have no problem > with a dvd that I sometimes have inserted on boot. (I use Gnome as > well, but haven't yet updated to mga2.) > If that is the cause, either something is not configured right or not > installed, or it is a bug. > If you have systemd activated, a configuration problem is not unlikely. > >> Will investigate fstab, edit if necessary and reboot without the >> drive . And if that works, mend sudoers. > > For fstab, the "users" option lets any user unmount the drive, even if > they didn't mount it. As well as mount it. It is a good option to use > for removable media. >> >> Thanks >> >> Len >> >> > > > -- > André > >
