Opened 17 years ago
Closed 8 years ago
#822 closed defect (obsolete)
Error handling when shared folder is missing or broken => Improved with 1.6.6
Reported by: | Ronny Standtke | Owned by: | |
---|---|---|---|
Component: | VM control | Version: | VirtualBox 1.6.4 |
Keywords: | Cc: | ||
Guest type: | other | Host type: | other |
Description (last modified by )
Here is a scenario where the error handling of VirtualBox is broken: 1) add a shared folder to a virtual machine 2) remove the "real" directory while vbox is not running 3) restart VirtualBox
The user gets the following error message: "The snapshot folder of a machine with snapshots cannot be changed (please discard all snapshots first)."
First of all, the error message has absolutely nothing to do with the real problem (non-existance of a specified shared folder) and is very misleading.
Secondly, a missing folder is no fatal situation, it should be possible for a user to recover from this situation without manually editing some obscure XML files.
Change History (10)
comment:1 by , 17 years ago
comment:2 by , 16 years ago
Component: | other → VM control |
---|
comment:3 by , 16 years ago
Version: | VirtualBox 1.5.0 → VirtualBox 1.6.2 |
---|
comment:4 by , 16 years ago
Summary: | Error handling when shared folder is missing is broken → Error handling when shared folder is missing or broken |
---|---|
Version: | VirtualBox 1.6.2 → VirtualBox 1.6.4 |
comment:5 by , 16 years ago
Just ran into this bug tonight.
When this situation occurs, not only does the virtual machine become unable to start, it becomes completely locked out from the VB Control panel.
This creates an impossibility to correct the issue. To correct the issue tonight, I had to rebuild the directory tree so that the directory once again existed, then immediately deleted the shared folder setting from the VBox Control panel. (The main GUI that starts on execution in Windows.)
In the event of a fatal error, of any kind in addition to this specific one, you should always have access to the settings of the virtual machine to remove or correct the flaw. The sole exception to this would be in the event that the VM configuration files themselves are unavailable, in which it shouldn't display in VBox in the first place.
comment:6 by , 16 years ago
Summary: | Error handling when shared folder is missing or broken → Error handling when shared folder is missing or broken => Improved with 1.6.6 |
---|
In VBox-1.6.6 we weakened this condition a bit. If a shared folder vanishes, the VM will no longer became inaccessible. Currently, no warning is displayed, the folder is just not accessible. This condition should be handled well by all guest additions. In future versions we have to fix this in a way that at least a runtime warning is displayed.
comment:7 by , 16 years ago
Does a documentation exist, how to recover from this problem (especially if some files are lost forever)?
comment:8 by , 16 years ago
Lost files in the shared folder? That does not matter, the guest will get an error message when trying to access such files. If a whole shared directory is lost then you have to create a dummy directory with the same name to satisfy current versions of VirtualBox and to be able to start the VM. Starting from 1.6.6, the guest will receive an error message in this case. This is currently not documented as we have to improve this handling further.
comment:9 by , 12 years ago
It is still broken in 4.1.8 ? I'm adding with VBoxManage a transient share, then I mount it in the guest. When I take a snapshot the shared folder didn't appears in that snapshot (after deleting the directories in the host). Then the snapshot don't start with:
Failed to open a session for the virtual machine WIN732.
Failed to load unit 'HGCM' (VERR_INVALID_PARAMETER).
Result Code: NS_ERROR_FAILURE (0x80004005) Component: Console Interface: IConsole {1968b7d3-e3bf-4ceb-99e0-cb7c913317bb}
comment:10 by , 8 years ago
Description: | modified (diff) |
---|---|
Resolution: | → obsolete |
Status: | new → closed |
Please reopen if still relevant with a recent VirtualBox release.
At least the current version 1.5.4 shows in that case 'VM not accessible' because 'the shared folder host path ... is not accessible'. This is still not what you want (the VM should start anyway perhaps after warning the user) but a little bit better than the original behavior.
We will improve the behavior in later versions.