virtualbox.org

Ron, here's what you need to do to move a vdi file for a guest:

1. Open the guest's Storage settings in the Virtualbox Window.
2. Take good note of which controller and port the vdi is attached to.
3. Right-click the vdi in the list and choose "Remove Attachment".
4. Close the guest Setttings box.
5. Open File Menu -> Virtual Media Manager
6. Right-click the vdi in the media list and choose "Release". Click the Release button in the pop-up.
7. Right-click the vdi in the media list again, and choose "Remove". Click the Remove button in the pop-up. Another pop-up will appear - this is the very dangerous one. Click "Keep". DO NOT click "Delete". If you click Delete your vdi will immediately be deleted, no Recycle Bin, no recovery at all. You will need a backup copy of the vdi if you click Delete.
8. Close the Virtual Media Manager.
9. Move the vdi to the desired folder.
10. Open the guest's Storage settings in the Virtualbox Window
11. Click the "Add Hard Disk" icon on the correct controller, then "Choose Existing Disk" in the pop-up.
12. Browse to the folder you moved the vdi to and select the vdi file.
13. Close the guest Setttings box.

Your guest will now be ready to run with the vdi in the new location, provided that the permissions problem did not follow the vdi. FWIW, the "(I)" in the "Mandatory Label\High Mandatory Label:(I)(NW)" line in the icacls output means Inherited, so hopefully if this permission setting is the problem it may stay on the C drive root.

A search on "Mandatory Label\High Mandatory Label" brought up this: https://msdn.microsoft.com/en-us/librar ... 2147217396
might be helpful, though it's rather over my head...

scottgus1 wrote:provided that the permissions problem did not follow the vdi.

Isn't that the case although when a file is moved versus when it is copied? Wouldn't a copy make more sense in that case?

scottgus1 wrote:A search on "Mandatory Label\High Mandatory Label" brought up this:

Yeah, I know, I saw that too and I had the same feeling as you. Over my head...

Isn't that the case although when a file is moved versus when it is copied? Wouldn't a copy make more sense in that case?

Honestly, I don't know. I haven't dug too deep into permissions, except to grant authorized co-workers access to shared folders on the office server. If the move doesn't work a copy might.

If there's enough hard disk space, Ron, and moving the vdi fails with the same read-only error, move it back and copy it, and attach the copy to the guest. If you have any trouble attaching the copy, post back.

Short story is the problems are solved. The two problems being the original permissions error on one VDI file but not the other and then later it was pointed out that same VDI file was in the saved state when I have never done a save. It was suggested I believe by BillG that I remove the VM from VirtualBox and then re-establish it. I had already tried that once and it did not work. At the same time I had also tried to move it to a folder and that did not work either because I had never done that before and did not know the proper procedure. The VB files tucked away under my administrator user id folder had configuration items that would not let me move the VDI file to a new location. Other people were telling me all newer Windows operating systems no longer allow anything to be modified or executed from the root partition. All I can say about that is Microsoft has a lot of work to do to fix bugs in this "security" logic because I have not yet been kept from doing that except in this case of this one VM. Anyhow, I tried the move again but this time I moved all those configuration files out of the way to force new ones to be created and moved the LANT VDI file inside a folder and reactivated it in VB. It is now working. Even though the PAC vdi was running without a problem, I also moved it inside a folder and reactivated it. I then ran that icacls command again. Now both VDI files display exactly the same results as what you saw above for the PAC file and both are working.
Thanks to all for pointing me in the right direction but why these problems occurred in one case but not the other is still an unknown we will probably never have a definitive answer for, other than maybe sloppy Microsoft design or programming. This is why I stopped using Windows on my personal computer several years ago and switched to a Mac. I never have these kinds of problems on my Mac. I use Windows only because I have to until I finally retire from my job.