Ejecting guest additions CD image doesn't persist

[David Charlap]

I am reporting this for the current version of VirtualBox, but I have seeing it for several years.

I run a variety of Linux guest operating systems on my Linux host. They guest additions always install OK for me.

I have found, however, that depending on how I eject the guest additions CD, VirtualBox may or may not remember the fact that it was ejected after quitting and restarting.

If I do it the old fashioned way (from a non-GUI session):

• type "umount /dev/cdrom"
• Right-click on the CD icon from the VM's toolbar
• select "Remove disk from virtual drive"

then there is no problem. VirtualBox removes the disk from the drive and it stays removed.

If, however, I type "eject /dev/cdrom", or if (from a GUI session) I right-click on the CD icon and select the "Eject" menu item, it doesn't stick. The disk does eject, and the CD icon goes gray, and when I look at the properties in the VirtualBox Manager app, I see that the drive is empty, but if I shutdown and restart VirtualBox, I will frequently find that the guest additions image is back in the drive. I will need to manually remove it using the Virtual Media Manager or by launching the VM and right-clicking the CD icon before the guest OS loads (which would end up mounting and locking the drive.)

Sometimes, it will seem to be properly ejected, in a way that persists across restarts, but when I log out from the host OS and log back in the next morning, I'll find it back in the drive.

This is truly weird.

I'm creating the bug with its component set to "other" because I'm not sure what component this bug may actually belong to. I can imagine it being part of the virtual media manager, guest extensions, or other areas.

My host operating system is Debian Stable (wheezy, fully up to date as of March 28, 2014). x86_64. Kernel 3.2.0-4-amd64 (Debian 3.2.54-2). I have, in the past, also observed this problem running RedHat Enterprise Linux version 5 (many different releases) as the host OS.

I have seen this with many different Linux guests, using a variety of update levels:

• RedHat Enterprise Linux 5 32-bit x86
• RedHat Enterprise Linux 5 64-bit x86
• RedHat Enterprise Linux 6 32-bit x86
• RedHat Enterprise Linux 6 64-bit x86
• Debian Stable (both squeeze and wheezy) 64-bit x86
• Fedora (19 and 20) 64-bit x86

If you have a hard time reproducing this, please let me know and I'll help you out as much as I can.

[David Charlap]

Just noting that this bug is still present in VirtualBox 4.3.14 (r95030). Confirmed using a Linux (Debian 7 "wheezy", latest updates) host and many different Linux guests (RHEL 5 - 32- and 64-bit, RHEL 6 (32- and 64-bit), RHEL 7, Debian 7 and Fedora 20 - all updated to the latest versions.)

Has anyone had a chance to look at the bug?

[Mihai Hanor]

Windows is also affected, as both host and guest. VirtualBox should update the VM settings, after an eject command has been processed, if it was received from the guest OS.

[David Charlap]

Still taking place using VirtualBox 4.3.20 r96996.

Since the bug is still listed as new, I assume nobody has tried to determine the cause yet. Which is very disappointing, given the fact that it is 8 months old, and the problem existed long before that.

[Frank Mehnert]

I think we finally fixed this problem and the fix will be part of the next maintenance release. Relevant changeset in trunk is r54716. This fix will be part of the next 4.3.x maintenance release.

[Frank Mehnert]

I've the Linux, Windows and Mac OS X builds on the test builds page which new builds containing the fix.

[Mihai Hanor]

I have tested the Windows test build, the problem is fixed.

[Frank Mehnert]

Thanks! Fix is part of VBox 4.3.26.

[David Charlap]

4.3.26 appears to have fixed this bug for me too. Thanks much.