VirtualBox NS_ERROR_FAILURE (0x80004005) macOS

Using a readonly filesystem, blocking VBox files wrtiting access causes this error. Move VBox virtual machines files to a new location with writing permissions must resolves this problem. In my case, i use a Linux server, with VBOx software but my machine was moved to a Windows partition with BitLocker active and the windows Disk was mounted in ReadOnly, causing this problem.

That file is obviously corrupted. If you go to that location [1], you'll see a 0-bytes file. In that same folder, chances are you're going to find a file named "VirtualBox.xml-prev". Delete the "VirtualBox.xml" file (the 0-bytes one) and rename the "VirtualBox.xml-prev" to "VirtualBox.xml".

If there is no "VirtualBox.xml-prev", or if it's also a 0-bytes file, then don't worry, it's still fixable. Just delete both of these files, they will be re-created when VirtualBox runs again. You simply would have lost any VirtualBox preferences and registered VMs that you might have had. Not the VMs themselves, the list of the VMs. You need to re-register your VMs, by either double-clicking on the .vbox file of every VM that you have, or go to the menu "Machine" » "Add" and navigate to the .vbox file of each of your existing VMs. Your VMs are located (by default) in "/Users//VirtualBox VMs".

I got this when I was trying to restore a suspended session. The fix was to click the "Discard" button (down arrow icon) and just discard the saved machine state. It's at least faster that uninstall/reinstall, I'd try it first.

I had the issue when I upgraded and I used the Extensions feature.

Check that your extensions have been updated as well. Download the latest from VirtualBox Website. Select File / Preferences and then the Extensions. Click the add symbol and select the new updated extension file.

Try and restart your virtual machine again.

Let's look at this from a troubleshooting perspective. The number one thing to do instead of guessing is diagnose and the best way to do that when you don't know what the problem is. I'll take you through the steps for my particular use case but it should give you a general idea on how to look at the problem in order to find the correct solution.

a.-Have a look at the actual logs of the VM:

Click on the Menu Item, you should see three choices:

1. Details
2. Snapshots
3. Logs

Look for this error code: VMSetError and look for the matching RETURN CODE (rc) rc=VERR_VD_IMAGE_READ_ONLY

In the example below the file under /build/virtualbox....is in read only mode.

 VMSetError: /build/virtualbox-8vePuu/virtualbox-6.1.16-dfsg/src/VBox/Devices/Storage/DrvVD.cpp(5228) int drvvdConstruct(PPDMDRVINS, PCFGMNODE, uint32_t); rc=VERR_VD_IMAGE_READ_ONLY

b.-Interpret what that means: But the problem is the /build directory does not exist at all. So what the rc above really means is that it cannot FIND that file, because /build doesn't even exist (nor it seems to be supposed to).

cd: /build/virtualbox-8vePuu/virtualbox-6.1.16-dfsg/src/VBox/Devices/Storage/: No such file or directory
root@pop-os:~# cd /build/virtualbox-8vePuu/virtualbox-6.1.16-dfsg/
-bash: cd: /build/virtualbox-8vePuu/virtualbox-6.1.16-dfsg/: No such file or directory
root@pop-os:~# cd /build
-bash: cd: /build: No such file or directory
root@pop-os:~# ls /
bin   dev  home  lib32  libx32      media  opt   root  sbin  sys  usr
boot  etc  lib   lib64  lost+found  mnt    proc  run   srv   tmp  var

Another thing to notice is that for my case other VMs with VDIs in the same location don't have the problem. That completely discards two possibilities:

• There's a problem with the install of Virtual Box
• There's an actual file permissions issue

The possibility is that the VM got corrupted at some point during shut down and that created the config corruption, not a VDI corruption at the VM level, not VirtualBox level.

Unless you power off your VM the "Close" function on your Vm window will ALWAYS save the state of the machine, so "Discarding" the state is only possible when you have two or more states because in that case at a minimum there is always the LAST state.

The conclusion is then that the corruption is at the VM state level and we need to get rid of that.

c.-Solution:

Go to VM-> Menu->Snapshots -> Clone

Create a linked Clone. That will simply copy the config files to the right place and link with the same VDI.

Start that one. If it starts you know you have a problem with the original VM. You can either re-create the VM and point to the existing VDI or create a full clone (it will take longer) and the delete the original.

To prevent this (at least for my case), avoid sending the Power Off Message to your VM when closing, better use the ACPI Shutdown method as Power off can leave (as we saw) your machine on an unwanted state.