Bugzilla Bug 186028

When I right click a usb storage device in konqueror and  go to "Safely
Remove", it gives me an error box stating "The device was successfully
unmounted, but could not be ejected".  I am in the plugdev group, and the
actual mounting/unmounting works great, it just always throws this error
telling me that the 'eject' part failed.

After much searching, I've found that adding my user to the 'disk' group fixes
the problem.  Shouldn't it be enough to just be in the plugdev group?

Reproducible: Always

Steps to Reproduce:
1. Build kde with USE=hal enabled for automounting etc.
2. Log into kde as a user belonging to 'plugdev' group but not 'disk' group.
3. Plug in a usb storage device and allow kde to automount it.
4. Browse to system:/media in konqueror, right click your usb device, and
choose "safely remove".

Actual Results:  
Error dialog stating "The device was successfully unmounted, but could not be
ejected".

The error dialog's title bar reads "Error - kio_media_mounthelper".

Expected Results:  
Since I am already in the plugdev group, it should do the unmount/eject
procedure without any extra priveleges.

maybe im barking up the wrong tree here.  

it works fine for cdrom because my cdrom's device node gets root:cdrom
ownership and i'm in the cdrom group.  i don't think i'll be able to do the
same with my usb storage until i make udev give usb storage devices something
like root:usbstorage ownership and put my users in that group. any thoughts on
whether the 'disk' group is really appropriate for usb storage devices?

or maybe there is a way to get kde to realize that it's stupid to try 'eject' a
usb drive, and it should skip ejecting for usb storage.

I can confirm hitting this bug, as are others:

http://forums.gentoo.org/viewtopic-p-4212031.html

is anyone doing something about this? the fix is straightforward, a one line
udev rule as shown in the forum thread quoted by Gordon:

echo -e '# removable disks\nACTION=="add", SUBSYSTEM=="block",
KERNEL=="sd[a-z][0-9]", ATTRS{removable}=="1", GROUP="plugdev"\n' >>
/etc/udev/rules.d/51-local.rules

why not include this in the standard udev setup?

CC'ing udev-bugs to verify the suggestion in comment #3.

block devices shouldn't be owned by the plugdev group. Block devices should be
owned by disk or cdrom.

it looks like KDE is directly calling "eject" or some similar code to "eject"
and not using the HAL method Eject(). The issue would be mitigated if KDE used
the Eject() method.

*** Bug 165079 has been marked as a duplicate of this bug. ***

(In reply to comment #5)
> block devices shouldn't be owned by the plugdev group. Block devices should be
> owned by disk or cdrom.
> 
> it looks like KDE is directly calling "eject" or some similar code to "eject"
> and not using the HAL method Eject(). The issue would be mitigated if KDE used
> the Eject() method.
> 

KDE calls kdeeject. It's a script that calls /usr/bin/eject.
User can't eject by permition.
It may fix by change owner or by "chmod u+s /usr/bin/eject"

A user can eject a CD...so I don't thinks that's a fix. I believe the "HAL
patch" in Comment #3 is more appropriate.

This has nothing to do with HAL. And a disk is a disk and should be owned by
group disk. KDE just needs to do things right.

"a disk is a disk and should be owned by group disk." I don't agree with that.
A removable USB flash disk, of type as described in Comment #3 is definitely
not the same as the SATA or PATA disk used to mount as root /. Furthermore, I
don't believe it is "wise" to give users the "disk" group ownership when all
one wants is to be able to remove his USB key.

And true, it has nothing to do with HAL forgot to agree on that point in
Comment #9 ;)

Upstream has bug about this, which seems to have been fixed year ago but
probably regressed in a newer kde version -
http://bugs.kde.org/show_bug.cgi?id=130427

Created an attachment (id=144017) [details]
kdeeject patch to use HAL to eject media

This patch fixes the issue for me.
This patch needs HAL to work, but if you have the issue you are already using
HAL.

Fixed in CVS.