VB permission error after installing Win10

[Ron49]

Was running Win Server 2008 VM with VB 5.0.2.10 on Win7 host. Upgraded to Win10 host and could not load this VM due to permissions error. Upgraded VB to 5.2.0.14 and got same error as follows.

Failed to open a session for the virtual machine LANTFMXAPP.

Failed to open image 'C:\LANTFMXAPP.vdi' for writing due to wrong permissions (VERR_VD_IMAGE_READ_ONLY).

Failed to attach driver below us! Image is read-only. (VERR_VD_IMAGE_READ_ONLY).

AHCI: Failed to attach drive to Port0 (VERR_VD_IMAGE_READ_ONLY).

Result Code: E_FAIL (0x80004005)
Component: ConsoleWrap
Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

When I checked attributes of the VDI it is not marked read-only. Need help.

[socratis]

You checked the attributes, but did you actually check the permissions? C:\ is not your typical location to store data. You know why? Permissions!

[Ron49]

I have been double checking everything and yes, I am logged in as administrator with full control of everything it will let me have full control of. I have two different VM systems that as far as I can tell are identical except for the size of the VDI file. While running Windows 7 I was running both individually and both at the same time with no problems. After upgrading to Windows 10, I can no longer load the larger of the two. I get the permission error indicated in my original post, which indicates it does not have write permissions for the VDI file. But as I indicated above I checked those permissions and I have full control of that VDI file as administrator. I don't understand why I get this error on just one of the VDI files. Any other ideas?

[scottgus1]

Windows 10 does not permit you, even as admin, to run files in the C root. New scheme. I'm admin, and can only make folders in my C drive root. 7 had more permissions for the root. You will have to move the vdi to a folder.

Edit- this quote:

full control of everything it will let me have full control of

highlights the problem. Win10 has changed the permissions. The vdi should not be in the C root anymore. Best place for it is in the guest folder with the guest's .vbox file and logs.

[socratis]

Which leads me again to repeat myself:

You checked the attributes, but did you actually check the permissions?

The answer was:

I am logged in as administrator

which doesn't cut it in my book. You have to check specifically for RW access from your account 1) to the file and 2) to the directory that owns the file.

[Ron49]

I am not trying to be argumentive or disrespectful of your time to respond. I do appreciate your efforts, but I have a hard time believing both of your responses. You seem to be ignoring the fact that this permission error is only coming from one of my two virtual machines. I indicated in my post one is working just fine. In fact I am using Internet Explorer to read and respond to your posts right now from inside the one VM that is working without any permission errors. This VDI file is located in exactly the same place as the other one that gets the permission error, i.e, C:\Filename.VDI.
I will try what you say and move the other VDI file that is not working inside a folder and report the results to you, but can either of you explain why one works and one does not if Win 10 is not suppose to allow anything to execute from the C root location. That is certainly not what I am observing right now.

[scottgus1]

This VDI file is located in exactly the same place as the other one that gets the permission error, i.e, C:\Filename.VDI.

This piece of information renders my suggestions moot. You mentioned earlier you had a different working guest but in your earlier post you did not say that the working vdi also existed on the C drive root. This kind of information is essential to understanding the problem and should have been included at the first mention of having one other guest that still works in your earlier post. Would have saved a lot of typing.

I would not know how to solve your problem, sorry.

[socratis]

I'd like to see the "recipe" of the VMs, the .vbox files:
- Right-click on the VM in the VirtualBox Manager.
- Select "Show in Finder/Explorer/Whatever".
- ZIP it and attach it in your response.
Do that for both VMs, the working and the not-working one.

[Ron49]

Socratis,
Thanks for pursuing this with me. If you have not already figured this out, I know zero about creating and modifying virtual machines. A co-worker provided these two VMs for me and I only use them. This co-worker is not currently available to help and probably could not because he has not yet upgraded to Windows 10. I spent the morning trying to move this problem VM into a folder on the C partition unsuccessfully. You will probably see this in the logs. The name of the problem VM is "LANTFMXAPP.vdi". The name of the other VM that is also located in the same C: root partition is "PACFMXAPP.vdi". I have added both attachments.

[scottgus1]

The only thing I see is that the working guest PACFMXAPP is set to 64 bits (log:" 00:00:02.011634 Guest OS type: 'Windows2008_64' "), while the non working guest LANTFMXAPP is apparently on 32 bits (log: "00:00:01.966427 Guest OS type: 'Windows2008' "). Everything looks fairly good until the line "AIOMgr: Endpoint for file 'C:\LANTFMXAPP.vdi' (flags 000c0781) created successfully" and "AIOMgr: Endpoint for file 'C:\PACFMXAPP.vdi' (flags 000c0723) created successfully". Then the LANTFMXAPP log goes south. As for how to fix it, I don't see anything that clears up the problem in the logs, except that Virtualbox thinks 'C:\LANTFMXAPP.vdi' is read only.

[socratis]

OK, one thing that I noticed that is different between the two VMs (and might matter in that case) is that the Lant VM is in a saved state while the Pac is not. I don't know where the .sav file is (although I have a suspicion) because there's no indication of it in the logs. (???????)

Also, can you open a Command Prompt and post the output of the command:

   icacls C:\*.vdi

[Ron49]

Socratis,
Your conclusions are all correct. My host Win 10 machine is 64 bit, the LANT VM Server 2008 is running 32 bit, and the PAC VM Server 2008 is running 64-bit. But I don't know what you mean by the LANT system is in a saved state. If I somehow did that it was by accident because I don't know how to do that or how to get out of that state. I have attached the information you asked for in a Word doc file, but unfortunately it has no meaning to me.

icacls Window.zip

(22.35 KiB) Downloaded 32 times

[BillG]

You may not be experienced with virtual machines, but surely you can work out which virtual machine socratis would refer to as LANT. What are the two called again?

As a first step, I would remove the saved state (by selecting the vm which is in a saved state in the VirtualBox Manager window and clicking on the orange Discard button). Now try to start it.

A saved state results when you elect to save a virtual machine rather than shut it down. This means it restarts faster (because it does not have to boot up), but there are also things which cannot be changed while a machine is in a saved state. You certainly should not change the host OS or do a major VirtualBox upgrade (such as from 4.x to 5.x) while any guest is in a saved state.

You did back up all your files (including the vms) before you upgraded the host machine OS?

[Ron49]

Hi BillG. You probably noticed that socratis and I are not making much progress, so thanks for chiming in to help. I was about to give up and go back to Win 7 but I will stick it out a little longer to see if two helpers is better than one. And yes, I did create a full system image of my Win 7 system before starting this endeavor.
It appears you may have missed or skimmed over a couple of posts too fast, so I will repeat a few details you don't appear clear on. What I refer to as the LANT system is the problem VM with a full name of LANTFMXAPP.vdi located at C:\ root. The VM that I refer to as PAC is the good VM running without problems with a full name of PACFMXAPP.vdi and also located at C:\ root.
Based on your comments about the "saved state" I now know how that can happen. I do occasionally ALMOST do that by mistake by clicking on the VM window exit button in the top right corner of the VM window. When that happens VB asks me if I want to save or send a normal shutdown signal. I have never responded to that other than to CANCEL the exit and then do a normal shutdown. So now there are two unanswered questions; 1) why do I get the write permission error on one and not the other? and 2) how did this same problem VM get into the Saved state when I have never done a save? Even if I had gotten into a hurry and did not cancel that request, the default option is to send a shutdown command instead. I would not have clicked on the save option instead.
Your suggestion to "Discard" the problem VM and restart it has already been done early on in this discussion. Although I still have a problem believing Win 10 does not allow you to write or execute from the C:\ root (boot) partition, I explained in an earlier post that I did try to move that VM into a folder on the C: partition, the only partition I have. I did a quick search in the User Manual to see if I could find instructions on how to do this properly, but did not fine anything, so I tried anyway just by making educated guesses that did not work.
Part of what I tried was to Remove that VM from VB, or as you would say Discard it. I did this by right clicking on the VM name and selecting Remove from the context menu. I then used Windows Explorer to move the file from C:\ to a folder called C:\VirtualBox_DataRoot that the original creator of this VM had created but for some reason never used. When I tried to add that VM back into VB by selecting the Machine > New menu item, it would not let me select that LANT file in the new location. This is because it said that file was still in use located at the old C:\ location. This is because under my login user id there is a folder called ....\VirtualBox VMs\LANTFMXAPP that has a set of configuration files in it (LANTFMXAPP.vbox, LANTFMXAPP.vbox-prev, and LANTFMXAPP-1.12-windows.vbox). This is the same set of folders/files that socratis asked me to send him a couple of posts back and it appears you have looked at those files also.
At the time I tried to move the LANT VM to a new folder I did not know how to get around that problem.
So now I am asking how to complete that move process. After I Remove LANTFMXAPP from the VB Manager window should I first delete, or at least move to a safe location, this LANTFMXAPP folder that is under my user id folder so that a new one can be created when I move the VDI file to its new location? I am reluctant to try this without confirmation form one of you for fear of messing up something else.

[socratis]

You probably noticed that socratis and I are not making much progress

Well, maybe because you kind of ignored me when I was asking for a check on the permissions (my 1st reply). Now that you did, it is clear that the files are not sharing the same permissions. I'll translate the picture embedded in the Word document, because it's not that helpful...

Code: Select all

C:\LANTFMXAPP.vdi NT AUTHORITY\Authenticated Users:(F)
                  BUILTIN\Users:(F)
                  BUILTIN\Administrators:(I)(F)
                  NT AUTHORITY\SYSTEM:(I)(F)
                  BUILTIN\Users:(I)(RX)
                  NT AUTHORITY\Authenticated Users:(I)(M)
                  Mandatory Label\High Mandatory Label:(I)(NW)

C:\PACFMXAPP.vdi  BUILTIN\Administrators:(I)(F)
                  NT AUTHORITY\SYSTEM:(I)(F)
                  BUILTIN\Users:(I)(RX)
                  NT AUTHORITY\Authenticated Users:(I)(M)

You can tell, just by looking at the picture that the two files are NOT sharing the same permissions. The one that is "troubling" me is the "Mandatory Label\High Mandatory Label:(I)(NW)". I don't have the slightest clue to what this is, but, the NW might stand for NotWritable. The bottom line is that you have a permissions error that you have to manage on your host. Then VirtualBox will be happy...