Description of problem: I've updated my box to KDE 3.5.4, logged out and in to load the new KDE, played with a USB disk and when I right-clicked the desktop icon and tried to safely remove it, it didn't do anything. The icon didn't change to the one that denotes an unmounted device, and mount sayd it was still mounted. I had to unmount it as root. I've tried it on another box with KDE 3.5.3, it was all OK. Then I unplugged it, upgraded the box to 3.5.4, restarted the session, replugged and did the same stuff with the flash disk andhit the same problem with safe removal as on the first box. Version-Release number of selected component (if applicable): kdebase-3.5.4-0.2.fc5 How reproducible: Always Steps to Reproduce: See above Actual results: See above Expected results: it should work as before Additional info: CDs are OK
Also happening with SD card reader. Resulted in corruption of my SD card when I clicked on Safely Remove, waited, and then removed SD card. In my case the icon for the SD reader has never correctly shown mounted/unmounted state, so I was caught off guard by the failure to unmount the device. Probably affects all USB storage devices. Since this bug leads to data loss I'd recommend increasing severity to high.
Oh! If KDE doesn't correctly show if the card is mounted or not then it's another bug. Changing the severity of this one anyway - I can imagine folks not checking the icon change and unplugging the device while still mounted.
I can confirm this behaviour. As ordinary user one has to use command line tools like gnome-umount to unmount the device correctly.
it's strange, i still cannot reproduce it on my test machine with current FC5-update. there's a short list of the packages which works on my machine kdelibs-3.5.4-0.1.fc5 kdebase-3.5.4-0.2.fc5 util-linux-2.13-0.20.4 hal-0.5.7-3.fc5.2 dbus-0.61-3.fc5.1 Could you please update all packages from FC-update and try again? Thanks
*** Bug 203504 has been marked as a duplicate of this bug. ***
There seem to be multiple media-manager related entries in the KDE 3.5.4 changelog at http://www.kde.org/announcements/changelogs/changelog3_5_3to3_5_4.php -- scroll down to "media manager" and take a look. I suspect one of those is what broke it. It would be nice if there were an error message somewhere, instead of things just silently not working ... One possible suspect is this: "Fix unmounting on systems that use supermount. Fixes bug 116209. See SVN commit 551890."
NB: here's the link to the KDE bug I referred to above http://bugs.kde.org/show_bug.cgi?id=116209
i have taken a look at #116209 , the fix is correct and does not cause this problem. Aas i said above it works for me with current FC5-update. Could you please update all packages from FC-update and try again? Thanks
This may be caused by a buggy /usr/bin/eject on FC5. eject < 2.1.5 is known to be bad (as disussed on the kde-packagers mailing list recently).
Out of curiosity, I just tried building an RPM (based on the FC5 spec file) out of the latest package of eject (2.1.5) and upgrading to it. It doesn't seem to have made a difference; I still have to "gnome-umount -p disk" (as myself; don't need to be root) to unmount my USB memory stick.
(In reply to comment #4) > it's strange, i still cannot reproduce it on my test machine with current > FC5-update. > > there's a short list of the packages which works on my machine > kdelibs-3.5.4-0.1.fc5 > kdebase-3.5.4-0.2.fc5 > util-linux-2.13-0.20.4 > hal-0.5.7-3.fc5.2 > dbus-0.61-3.fc5.1 > > My current set: kdelibs-3.5.4-0.1.fc5 kdebase-3.5.4-0.2.fc5 util-linux-2.13-0.20.4 hal-0.5.7.1-2.fc5 dbus-0.61-3.fc5.1 So, I match you in everything but hal. yumex shows no updates available for hal on my system. The problem is affecting me on two different systems now, an i386 one and an AMD64.
If it's a problem with eject then it should be completely reassigned to its maintaner, right? CC'ing Than.
Ah, eject is owned by Than, too :) Sorry for the spam.
See also upstream kde bug: http://bugs.kde.org/show_bug.cgi?id=131540
eject-2.1.5-0.1.fc5 will be pushed into FC5-update today. It fixes this above problem. Thanks for your report.
Works fine on my i386 system after updating to new eject. Thanks for the fix!
yes, it corrects the bug, but it opens a security hole: _Every_ user can now eject _any_ device, no permissions are checked.
Than: thanks for the quick fix! M. Steinborn: not sure I follow. Even the user with console lock cannot eject e.g. a hard disk, the call fails. And if he can eject an ejectable medium, it's good, isn't it? He's sitting on the console. And other users? I just tried to run eject as a user who didn't own the console lock, and a messagebox was displayed with text 'The password you typed is invalid. Please try again.' (which actually appears to be a bug in usermode) but nothing was ejected so I don't see a problem.
I am sorry to tell you that yopu did not follow. The point is: The new version of "eject" (eject-2.1.5-0.1.fc5) must be safe on its own, indepently of kde/gnome/etc. You will agree to this sentence, don't you? Let's assume sume devices (e.g. CDROMs) are mounted by fstab (if you are running vmware-server, you may want so). Let's furethermore assume "user2" mounted the CD-Rom device (he can do so because fstab contains the line /dev/hdc /media/cdrom iso9660,udf defaults,noauto,user,ro 0 0 ). Then only root and user1 can unmount "/media/cdrom" resp. "/dev/hdc". Right? But: Any lokal user (ownning /dev/console) can "eject /dev/hdc") and therefore unmounting the cdrom. Is the problem now clear? PS: At first tests I had problems with /etc/pam.d, there were some *.rpmnew-files and therefore old files had been used. I must correct the last post: but it opens a security hole: _Every_ *lokal* user *owning /dev/console* can now eject _any_ device, no permissions are checked. The same problem would occur with an usb-hdd mounted by root not intended to be unmountable by any non-root user. Every lokal user owning /dev/console can eject it and therefore unmount it. Have I described the problem more understandable this time?
An addition: The eject-commands have to be entered on a shell, not by any GUI.
Ah, I got your point now. However, there are three possible scenarios: 1) people log into your system locally in GUI. Then, you don't have a static entry for removable media in fstab, and once the person sitting on the console puts e.g. a CD in, fstab is modified and the device is mounted. Only this user and root can later eject it. 2) GUI isn't used, people log in remotely. Then, removable media aren't used on that system at all and there's no need to worry about eject. 3) the box is accessible both remotely and locally, and a user puts a CD in, goes away to work on the system remotely. Another user comes, logs in locally, obtains console lock and can eject the medium although he didn't mount it. I can imagine this scenario e.g. in a computer lab, however, working in this environment has never been easy - removable media, although mounted by user1, has always been accessible by user2 at least for reading, a local user was always able to reboot the machine, kill locked X-server etc...
Problem solved with FC5 updated to 2006-10-09 KDE 3.5.4-0.3.fc5