186028 2007-07-20 21:19 0000 kde (hal) "unmounted but not ejected" error unless in disk group 2008-04-26 17:27:51 0000 1 1 1 Unclassified Gentoo Linux KDE unspecified All Linux RESOLVED FIXED P2 normal --- 1 bkohler@gmail.com kde@gentoo.org aronparsons@gmail.com damian01w@gmail.com esigra@gmail.com gengor@gentoo.org kyron@neuralbs.com pva@gentoo.org redroyalty@fastmail.fm roberto.castagnola@gmail.com spamtrap@hope-st.ath.cx teidakankan@gmail.com tomsimnett@yahoo.co.uk udev-bugs@gentoo.org bkohler@gmail.com 2007-07-20 21:19:28 0000 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. bkohler@gmail.com 2007-07-26 21:43:37 0000 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. gengor@gentoo.org 2007-08-30 05:10:58 0000 I can confirm hitting this bug, as are others: http://forums.gentoo.org/viewtopic-p-4212031.html niknik79@bossmail.de 2007-11-09 09:16:14 0000 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? tgurr@gentoo.org 2007-11-19 22:12:24 0000 CC'ing udev-bugs to verify the suggestion in comment #3. cardoe@gentoo.org 2007-11-19 22:28:37 0000 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. tgurr@gentoo.org 2007-11-20 19:00:44 0000 *** Bug 165079 has been marked as a duplicate of this bug. *** oblom27@rambler.ru 2007-11-27 09:48:17 0000 (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" kyron@neuralbs.com 2007-11-27 17:22:28 0000 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. cardoe@gentoo.org 2007-11-27 17:30:14 0000 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. kyron@neuralbs.com 2007-11-28 01:19:49 0000 "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. kyron@neuralbs.com 2007-11-28 01:21:58 0000 And true, it has nothing to do with HAL forgot to agree on that point in Comment #9 ;) caster@gentoo.org 2008-02-03 21:10:04 0000 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 julien.etienne@gmail.com 2008-02-19 22:18:31 0000 Created an attachment (id=144017) 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. philantrop@gentoo.org 2008-04-26 17:27:51 0000 Fixed in CVS. 144017 2008-02-19 22:18 0000 kdeeject patch to use HAL to eject media kdeeject.patch text/plain LS0tIC91c3Iva2RlLzMuNS9iaW4va2RlZWplY3Qub3JpZwkyMDA4LTAyLTE5IDIyOjQ1OjI2LjAw MDAwMDAwMCArMDEwMAorKysgL3Vzci9rZGUvMy41L2Jpbi9rZGVlamVjdAkyMDA4LTAyLTE5IDIy OjU3OjI2LjAwMDAwMDAwMCArMDEwMApAQCAtMjUsNyArMjUsMTAgQEAKICAgICAgICMgV2Fybmlu ZywgaXQgaGFzIHRvIGJlIGVpdGhlciBlamVjdCAyLjAueCBvciA+PTIuMS41CiAgICAgICAjIE90 aGVyd2lzZSBpdCBkb2Vzbid0IHdvcmsgYXMgZXhwZWN0ZWQgKGl0IHJlcXVpcmVzIGEKICAgICAg ICMgZnN0YWIgZW50cnkgZm9yIG5vIHJlYXNvbikuCi0gICAgICBlamVjdCAkMSA+L2Rldi9udWxs IDI+JjEKKyAgICAgICNlamVjdCAkMSA+L2Rldi9udWxsIDI+JjEKKyAgICAgIEJMT0NLX1VEST0k KGRjb3Aga2RlZCBtZWRpYW1hbmFnZXIgcHJvcGVydGllcyAiJDEiIHwgaGVhZCAtMSkKKyAgICAg IFsgLW4gIiRCTE9DS19VREkiIF0gfHwga2RpYWxvZyAtLXRpdGxlICJLREUgRWplY3QiIC0tZXJy b3IgIkNhbid0IGZpbmQgVURJIGZvciBVUkwgJDEiCisgICAgICBkYnVzLXNlbmQgLS1zeXN0ZW0g LS1kZXN0PW9yZy5mcmVlZGVza3RvcC5IYWwgIiRCTE9DS19VREkiIG9yZy5mcmVlZGVza3RvcC5I YWwuRGV2aWNlLlZvbHVtZS5FamVjdCBhcnJheTpzdHJpbmc6IiIgPi9kZXYvbnVsbCAyPiYxCiAg ICAgICA7OwogICBlc2FjCiAgIGlmIHRlc3QgJD8gLWVxIDA7IHRoZW4K