[Mageia-discuss] Cannot unmount media as user

[RICHARD WALKER]

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 at 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 <andre999mga at laposte.net> 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é
>
>