This started to happening to me in kde-3.5.4, with the new mount/unmount code in the media manager. Editing media_safelyremove.desktop as suggested above solved the problem for me.

kdeeject needs to use HAL method to ject the devices.
See :

error() {
	kdialog --title "Safely Remove" --error "$1"
	exit 1
}

BLOCK_UDI=$(dcop kded mediamanager properties "$1" | head -1)
[ -n "$BLOCK_UDI" ] || error "Can't find UDI for URL $1"

STORAGE_UDI=$(hal-get-property --udi $BLOCK_UDI --key block.storage_device)
[ -n "$STORAGE_UDI" ] || error "Can't find device for volume $BLOCK_UDI"

for TMP in $(hal-find-by-property --key block.storage_device --string $STORAGE_UDI); do
	[ $(hal-get-property --udi $TMP --key block.is_volume) = true ] || continue
	[ $(hal-get-property --udi $TMP --key volume.is_mounted) = true ] || continue
	ERROR=$(dcop kded mediamanager unmount $TMP)
	[ -n "$ERROR" ] && error "$ERROR"
done

dbus-send --system --dest=org.freedesktop.Hal "$BLOCK_UDI" org.freedesktop.Hal.Device.Volume.Eject array:string:""

Can you still reproduce this bug with 3.5.4? If yes what is the version of the "eject" command on your system?

yes
[admin@info1 Mandriva 2007]$ eject -V
eject version 2.1.5 par Jeff Tranter (tranter@pobox.com)


Ok the issue is the following :
- removable media entries are no longer in /etc/fstab by HAL since version 0.5.4 IIRC
- So eject can't eject media which are not in fstab ( unless you are root ).
- Thus we need to use Hal method to eject the media, and if this fail, then we could try eject command as a fallback

kdeeject needs to be modified in the following way :

if HAL version > 0.5.4 Then
   if device volume.is_disc == FALSE Then
        for all block in volume
               if  block.is_volume  && volume.is_mounted Then
                     dcop kded mediamanager unmount
        done
   Else
       dcop kded mediamanager unmount
   fi
   dbus-send --system --dest=org.freedesktop.Hal blockdevice_udi org.freedesktop.Hal.Device.Volume.Eject array:string:""
else
   eject $1
fi
          

Created attachment 17589 [details]
HAL support for kdeeject

HAL support for kdeeject.
I modified only the Linux part ( I hope ) and check for HAL version as for HAL
< 0.5 entries was written in fstab and the eject method may not exist.

Created attachment 17634 [details]
New version of HAL support for kdeeject

Ok this new patch version :
- check for HAL userland tools presence before trying to use them
- doesn't try to get UDI from mediamanager to avoid bug #130424 side effects
- use mediamanager to umount the volume, and if this failed, try to use HAL
method
- if HAL is not available fallback to the old eject method

Works for me. Thanks!

this is fixed in kde 3.5.5

The issue is still present in kdebase-3.5.8 (for example see gentoo bug report http://bugs.gentoo.org/show_bug.cgi?id=186028 ).

I have fixed the problem using the dbus-send to send the eject command to HAL as other reporters have suggested.

This is still present in KDE 3.5.9 on Gentoo x86_64.  I am following the same bug as reported in comment #10.

Created attachment 53118 [details]
Updated patch for post 2010 hal

The previous patch doesn't work cleanly, because hal wants --print-reply option. Besides on my own PC eject command needs to be issued twice, otherwise HAL doesn't want to play by my rules:

The first invocation yields:

method return sender=:1.1 -> dest=:1.103 reply_serial=2
   int32 0

The second (which actually ejects the device) yields:

Error org.freedesktop.Hal.Device.UnknownError: An unknown error occured

- but this error message actually means that HAL succeeded. So, on the next line I check if the device still exists.

And the original proposed patch has never been pushed upstream, so this bug cannot be "solved".

Here's this file from KDE 3.5 branch: http://websvn.kde.org/branches/KDE/3.5/kdebase/kdeeject/kdeeject?revision=568272&view=markup