Can't install Virtualbox 7.0.16 outside of C:\Program Files

[Kumba]

I have my Virtualbox installation on a separate drive partition, specifically in F:\Program Files\Oracle\Virtualbox. It's been this way for over 6 years across two different system builds, and there has never been a problem before. However, attempting to upgrade my current Virtualbox 7.0.14 install in that F: location to 7.0.16, I get an error that states "The chosen installation directory is invalid, as it does not meet the security requirements.", and I cannot proceed further with the installation.

I cannot find any documentation on what these so-called "security requirements" are. I suspect it may be because that F: folder was created with my admin account and isn't owned by TrustedInstaller, but I'm guessing at this point.

Oracle needs to clarify what these security requirements are so that those of us using install locations other than C:\Program Files can make adjustments, or this new install condition needs to be removed.

[Kumba]

Image of the installer error about the installation directory being invalid

[lissy]

Hello Kumba, I've encountered exactly the same problem on my Windows 11 laptop. I've been using Virtualbox for about as long as you. I haven't tried installing 7.0.16 on my other Windows PCs (still running 10 x64) yet, but I assume problem will be present there, too... Good thing is I still have my VMWare licenses and I've set up my VMs (mostly Linux) to work with both products... I'll keep track of this ticket hoping Oracle will find a quick solution to this.

[Ant]

Same problem in my 64-bit W10 Pro. as shown in my ​https://www.reddit.com/r/virtualbox/comments/1c5q3il/cant_upgradeinstall_vb_v7016_in_64bit_w10_pro_pc/ and ​https://forums.virtualbox.org/viewtopic.php?p=547552 threads. I never use the default C:\Program Files\ directory for my software installations including VirtualBox. This was a first time ever for me. I really hope I don't have to use that default location.

[pentagonik]

The change was intentional to prevent installing VirtualBox into directories where regular users have the ability to write or rename content (files / directores). This also includes parent directories.

So VirtualBox only can be installed into paths where only Administrators or system accounts have the ability to do so.

[Grendel1a]

If there is no way to install (-AllowStupidPeopleToInstallWhereTheyWant) in a directory of my choice: What is a list of acceptable directories I >>> CAN <<< install in?

Surely I won't be forced to install it ONLY on C:\Program Files, (845 MB free) when I have 32 free terabytes on my internal D: and 16 free terabytes on my external NAS F: ...

[pentagonik]

We don't provide a switch for that. Can you please try installing into a different directory where regular user are *not* able to write / modify anything? This also *must* include parent directories.

Another option would be (instead of the switch you proposed) to extract the installer and do your own, customized installation. This then is entirely unsupported and not encourged though.

[pentagonik]

I just verified installing 7.0.16 on another drive; seems to work as expected. If only one directory in the installation path doesn't meet the requirements, installation will be refused.

To manually craft a directory on another drive where to install VirtualBox into, one could do the following before executing the installer:

Example for installing into 'x:\install_test':

mkdir install_test
icacls install_test /reset /t /c
icacls install_test /inheritance:d /t /c
icacls install_test /grant *S-1-5-32-545:(OI)(CI)(RX)
icacls install_test /deny  *S-1-5-32-545:(DE,WD,AD,WEA,WA)
icacls install_test /grant *S-1-5-11:(OI)(CI)(RX)
icacls install_test /deny  *S-1-5-11:(DE,WD,AD,WEA,WA)

Looks a bit like voodoo at first, but this essentially removes default inheritance and denies writing / modifying contents by regular (authenticated) users. Only Administrators / SYSTEM can ("Built-In\Users" is S-1-5-32-545 + "NT-AUTHORITY\Authenticated Users" is S-1-5-11).

[Ant]

Shouldn't run installer as administrator work to install into non-default location? If so, then it didn't work for me.

[Kumba]

Replying to pentagonik:

The change was intentional to prevent installing VirtualBox into directories where regular users have the ability to write or rename content (files / directores). This also includes parent directories.

So VirtualBox only can be installed into paths where only Administrators or system accounts have the ability to do so.

What's the motivation behind this change? Is there a ticket # I can look at to understand why you all think this was a good change? Because right now, I am firmly convinced that it is not.

It shouldn't be the purview of software developers to try and protect users from doing stupid things on their own systems. My system, my rules, and if I want to install software somewhere else other than my OS drive (C:\), then that's my choice and that needs to be respected. If I break something in the process, then that's on me to fix. Pop up a dialog box lecturing me about it if you want; that's fine. But don't dare make the incorrect assumption that you all know better than I do about my own system and try to enforce that programmatically, because I will fight back on that.

As it currently stands, I am unable to upgrade my existing installation of Virtualbox from v7.0.14 to v7.0.16, because of this change, so you all certainly didn't consider nor test for the scenario where an existing installation was already in a non-standard path. And I am not going to uninstall my existing installation just to reinstall it in a path that someone thinks is "best". If I must, I'll stay on v7.0.14 until the heat death of the Universe itself.

Though I am probably going to create an NTFS Junction in C:\Program Files\Oracle and point it at F:\Program Files\Oracle, because this isn't the first piece of software that's made incorrect assumptions about people's systems (:: side-eyes Vivaldi and Logitech ::).

In any event, I implore you all to seriously re-think this approach. There are FAR better ways of handling this, such as the aforementioned popup dialog, requiring user interaction to make such a change (e.g., an "Advanced Installation" checkbox or such), etc. At a bare minimum, the error string needs to be considerably fleshed out to explain, in detail, why the selected path is inappropriate.

[webb]

Kumba - I must say I sympathise with and support your views on this peculiar new installer.

1. I have tried the suggested workaround (shown above) by creating a fresh directory and using the icacls commands. I have tried this on other drives and also in the root of drives. It does not work. (At least, not for me.) The symptoms and error message remain exactly the same. 2. I am inclined to suspect that there are more issues with this particular build of the installer. For example, I have observed that if you run it up to the point of selecting the 'features and installation location' that you require - there is no sign at all of the customary 'License Agreement' which would normally require user consent. However, if you reverse the process by clicking the 'Back' button .......... suddenly there it is! Why ? I believe I only discovered that anomaly when finding the following additional anomaly ... i.e. that on one occasion at least, when attempting to select an installation lcation, the default 'Location' field was blank and the 'Browse' button was grayed out (??)

This is all very strange - so I am expecting (or at least hoping for) a quick revision to v7.0.17 asap !!

[Kumba]

Replying to webb:

Kumba - I must say I sympathise with and support your views on this peculiar new installer.

1. I have tried the suggested workaround (shown above) by creating a fresh directory and using the icacls commands. I have tried this on other drives and also in the root of drives. It does not work. (At least, not for me.) The symptoms and error message remain exactly the same. 2. I am inclined to suspect that there are more issues with this particular build of the installer. For example, I have observed that if you run it up to the point of selecting the 'features and installation location' that you require - there is no sign at all of the customary 'License Agreement' which would normally require user consent. However, if you reverse the process by clicking the 'Back' button .......... suddenly there it is! Why ? I believe I only discovered that anomaly when finding the following additional anomaly ... i.e. that on one occasion at least, when attempting to select an installation lcation, the default 'Location' field was blank and the 'Browse' button was grayed out (??)

lol, nice find! I checked back to 7.0.10's installer, and it's got the same bug where it doesn't show the license acceptance screen at first before letting you update (no way for me to test a new install atm). Oracle's lawyers would have a fit about this if they knew, too.

That said, it looks like the BSOD that's triggered by this release has become critical, judging by the giant warning on the homepage now, so hopefully in an amended release, this ticket gets resolved in some way as well (preferably by just restoring the original behavior). If not, well, there's always Orca and hacking the MSI launch conditions...

[interghost]

Came upon this issue aswell... I really don't understand the logic behind it, if you want to do this put a big red warning in the installer "Are you sure you want to install in an insecure directory?" Yes / No, simple as that. If someone wants to install it, its his/her right to do it.

Also if there is a more detailed description somewhere what exactly constitutes a secure directory, as I have it installed in Program Files just on another drive. And I'd rather not poke with the commands blindly as there are multiple other programs installed in the same Program Files folder.

[Klaus Espenlaub]

The point is that installing VirtualBox always assumed that people use secure directory settings (the same ones as for C:\Program Files). This is now enforced to avoid people being bitten by insecure directory permission attracting malware.

[lissy]

"This is now enforced to avoid people being bitten by insecure directory permission attracting malware."

I (as an experienced software developer) have been using VirtualBox for almost a decade now and I really liked it. I never installed it in a so-called "safe folder". And I never experienced any issues resulting from this! I fully agree with interghost and others when they say, a warning message is sufficient!

But if Oracle sticks to this "enforcing" I think I'll simply switch back to VMWare for they don't force me to install their software in a folder I do not want (yet). I still have VMWare licenses and since all of my VMs are designed to run under both VMWare and VirtualBox, I surely won't be crying over Oracle's questionable VirtualBox policy.

[dbojan]

Download VirtualBox-7.0.10-158379-Win.exe from ​https://download.virtualbox.org/virtualbox/7.0.10/ which does not have this limitation.

[Klaus Espenlaub]

Improved documentation is on the way. Lowering the product security in new releases is prohibited (for reasons which should be obvious) by the Oracle security policy.

[malchior]

I, too, suffer from this Mothering approach. VB used to just work. What changed that your (devs) feeling changed to disallow us (users and consumers) from deciding on our own level of risk. If this wasn't sad, it would have been funny.

@Kumba - did you see this?

"ATTENTION: PLEASE REFRAIN FROM UPGRADING TO 7.0.16 FOR NOW. THIS RELEASE HAS AN ISSUE WHICH MIGHT CAUSE HOST OS CRASH WHEN VM IS CONFIGURED TO USE BRIDGED OR HOST-ONLY NETWORKING. WE WILL SEND AN ANNOUNCEMENT TO MAILING LISTS WHEN FIX WILL BE AVAILABLE FOR DOWNLOAD."

[Grendel1a]

Hey, I have an idea:

How about a nice little utility, written by Oracle boffins, that runs in a windows directory and looks to make sure VirtualBox is installed there. Then goes about changing the permissions, down to root, to make that an acceptable place to install VB?

Since I don't know what permissions are allowed, that leaves me out of the running to write the utility.

What say you, Oracle gurus?

As an added bonus, instead of "You can't install here." Replace with "Would you like to adjust the permissions to install here?" and fix the permissions for the end user.

If the user doesn't have permissions to change the permissions, that makes sure only administrators can install there anyway.

[Grendel1a]

Still broken in 7.0.18

[webb]

1. Some of the previous contributors here appear not to have read Kumbas original posts properly. He clearly explains that he should be permitted to install (upgrade) to his original installation location, and not be forced to install where he has very little disk space.
2. The latest release 7.0.18 still suffers the same old "invalid directory problem" even when applying all of the Oracle recommended permissions.
3. The problem with the end-user license consent requirement not appearing (unless you hit the "Back" key) is also still very much evident.

What a PITA.

[toulmouche]

My attempt to change the security on the VB directory broke the application and had to be backed out. At this time I cannot update my installation. Is there any report-able time-frame that a fix for this issue will be release?

[Kumba]

Replying to webb:

1. Some of the previous contributors here appear not to have read Kumbas original posts properly. He clearly explains that he should be permitted to install (upgrade) to his original installation location, and not be forced to install where he has very little disk space.
2. The latest release 7.0.18 still suffers the same old "invalid directory problem" even when applying all of the Oracle recommended permissions.
3. The problem with the end-user license consent requirement not appearing (unless you hit the "Back" key) is also still very much evident.

What a PITA.

Seems e-mail notifications don't work on this bug-tracker?

Okay, while I appreciate that the devs have added some instructions for using icacls to set permissions to an acceptable value, the problem still remains that I am not trying to do a fresh install; I am trying to do an upgrade and now I technically can't. For the past several years, I have always installed non-OS programs into clones of "Program Files" and "Program Files (x86)" on a different disk partition than C:\.

While I understand that not having specific permission constraints set on those folders could be a security problem, that ship sailed and promptly sunk to the bottom of the ocean a long time ago. Suddenly deciding to enforce some arbitrary security best practice that breaks the upgrade path for existing installs during a minor version release is somewhat of a cardinal sin in software design. Furthermore, it's not the Vbox devs' responsibility to police how I set my systems up. You all can make recommendations, but I can equally choose to ignore those recommendations. Flash a warning message, fine, maybe even tell me why what I am doing is bad and link me to some resources for further education.

In any event, I've worked around the problem myself by extracting the MSI file from the installer and removing the offending checks using Orca, an MSI editor available in the ​Windows SDK. If anyone else wants to emulate, you need to edit the MSI with Orca and find all three references to "VBox_Target_Dir_Is_Valid" in the MSI database and "drop" (delete) those records, then save the MSI and run it. Two should be under "ControlEvents" and one under "LaunchCondition" (these are the categories in the left-hand pane). Just use the Ctrl+F Find dialog to locate them. Don't touch anything else! It's annoying to have to do this from now on for every future Vbox release, but this isn't my first rodeo with silly limitations in MSI installers.

Another workaround (that I haven't tried yet) is to create an NTFS Junction inside "C:\Program Files" and point it to your actual install path, then point the Vbox installer at that Junction path. I have to use this trick for installers that use hardcoded install paths. I don't know if the security-check logic in Vbox's installer will conflict with a Junction, though.

[Grendel1a]

Replying to Kumba:

Thank you Kumba!

I had a heck of a time, so I hope my additions to your guidance help someone:

After you have the SDK installed (I didn't), search the directory for Orca and install that too.

Now open a cmd window (windows-r cmd<return>). Change directory to the directory that has VirtualBox installation exe.

mkdir holder

VirtualBox-7.0.18-162988-Win.exe --extract -path ./holder

Run Orca and put in the .msi from the /holder directory

Edit according to Kumba. Save. Run .msi

Smile happily as the dang thing is able to install and run.

[vichman]

I've tried modifying my install folder and parent folders with cacls command run as administrator but VBox installer keeps on complaining. So I've used the other approach by Kumba:

Another workaround (that I haven't tried yet) is to create an NTFS Junction inside "C:\Program Files" and point it to your actual install path, then point the Vbox installer at that Junction path. I have to use this trick for installers that use hardcoded install paths. I don't know if the security-check logic in Vbox's installer will conflict with a Junction, though.

NTFS junctions are the so-called soft links on *NIX systems...

C:
cd "Program Files"
mklink /J linkName target

linkName being the one chosen by you (e.g. VBoxLink) and target your previous VBox install folder (e.g. F:\Utils\Optim\VBox).

Pointing VBox installer to your new junction (C:\Program Files\VBoxLink) makes it run until the end, and after that you have an apparently fully functional updated VirtualBox.

Thanks!

[vtap]

Replying to vichman:

Thanks vichman ! mklink /J works like a charmL

I've tried modifying my install folder and parent folders with cacls command run as administrator but VBox installer keeps on complaining. So I've used the other approach by Kumba:

Another workaround (that I haven't tried yet) is to create an NTFS Junction inside "C:\Program Files" and point it to your actual install path, then point the Vbox installer at that Junction path. I have to use this trick for installers that use hardcoded install paths. I don't know if the security-check logic in Vbox's installer will conflict with a Junction, though.

NTFS junctions are the so-called soft links on *NIX systems...

C:
cd "Program Files"
mklink /J linkName target

linkName being the one chosen by you (e.g. VBoxLink) and target your previous VBox install folder (e.g. F:\Utils\Optim\VBox).

Pointing VBox installer to your new junction (C:\Program Files\VBoxLink) makes it run until the end, and after that you have an apparently fully functional updated VirtualBox.

Thanks!

[disappointment]

So, I >>> TRIED <<< to install it in C:\Program Files\IsThisSafeEnoughForOracleVirtualBox and later got error that path is too long for "C:\Program Files\IsThisSafeEnoughForOracleVirtualBox\UnattendedTemplates"

I give up, I'm done with VirtualBox, the only reason I loved it was quick setup with next-next-next and everything work out of box.

Was nice while it worked.

[Grendel1a]

Sorry about your issue, '@disappointment.' I guess you weren't forced to program in pascal in the late 80's or early 90's. Variables were maxed out at 31 chars. That was a pain when learning to program.

Windows has a path length which cannot be exceeded. I suspect it is windows, and not the install program causing you issues. Perhaps with shorter path names like Oracle\VBbox, you would get further?

I just installed 7.0.20 with the edit the msi from @Kumba with my additions. Worked like a charm.

Good LUCK!

[justiceeight]

Got the same issue with 7.0.20-163906-Win update, what a shame, never have issue with VB before, nice and friendly emulator, easy to use, it has become some crazy paranoid stupid software, thanks to moron-approved policies no one never asked about.

@Kumba: maybe you forgot one step in your explanation because the extracted stuff of the install program doesn't contains any "msi" windows installer , but dozens of files. So which one contains the three keys you give ?

Or by any bad luck does Oracle guys made it even worth for us by removing it from installer ?

Anyway, this issue is 4 months old already, time to deal with it guys, it's not acceptable to have such a user killer issue, think of people who don't know much about windows insight and who just want to emulate some guest for professional needs.

Even removing users permissions to install folders AND install as an admin doesn't change the stubborn response from the installer ! Very annoying and disappointing.

[Grendel1a]

Replying to justiceeight:

@justiceeight

@Kumba: maybe you forgot one step in your explanation because the extracted stuff of the install program doesn't contains any "msi" windows installer , but dozens of files. So which one contains the three keys you give ?

Look at the post just after Kumba's to learn how to extract the .msi via --extract (instead of using 7-zip or some other direct way).

Happy installs (=

[Kumba]

Replying to justiceeight:

Got the same issue with 7.0.20-163906-Win update, what a shame, never have issue with VB before, nice and friendly emulator, easy to use, it has become some crazy paranoid stupid software, thanks to moron-approved policies no one never asked about.

@Kumba: maybe you forgot one step in your explanation because the extracted stuff of the install program doesn't contains any "msi" windows installer , but dozens of files. So which one contains the three keys you give ?

I think I did forget a step, TBH. Usually, whenever you run any Windows installer *.exe, it unpacks some files into a randomly-named folder in your %APPDATA%\Local\Temp directory. This random name varies from installer family to installer family.

For Vbox-7.0.20 that I just updated to, while the installer dialog is open, I navigated to the above Temp folder, and in there, I had a recently-created folder with the name "3oqh2qssl2lo97s1jcd9ufp1". Inside that folder was a single MSI file named "8u26fi46vpzdkpqn857h50ss.msi". Copy that MSI off to some other location; in my case, I keep an archive of all my software installers for recovery purposes, so I copied this MSI there. Then, you exit out of the installer dialog, and it'll clean up the folder in Temp.

From there, use Orca to find all three references to "VBox_Target_Dir_Is_Valid" and "drop" them (MSI's have a database in them, so you have to "drop" a row to delete it), save the MSI, and close Orca. Then you should be able to run the MSI itself and it'll install w/o complaint.

That said, Grendel1a's advice in comment:22 to use the '--extract' flag to dump the MSI out is probably a more direct way. But, that flag isn't always available, again depending on the installer family, so sometimes, my way of hunting in Temp for the extracted installer contents services as a workaround. Sometimes, you have to open the installer exe up in 7-zip to find the MSI. They're always all a little different. One fun one I get to do every now and then is extract just the "Data1.cab" out of AMD's Chipset Driver installer, because there's something in their MSI logic that doesn't like my system, so it's just easier to dump the driver CAB directly, then use Device Manager to update the 4-5 components in my system that have drivers in that package.

[agrajagco]

The instructions that have been added to do this from the documentation are wrong.

​https://forum.virtualbox.org/manual/UserManual.html#install-win-installdir-req

I used a administrative powershell for the grant/deny portion as well (but might not be required)

I found the only way to get these commands to work, you MUST use single quotes to wrap the grant/deny assertions like so (replacing your target <Directory> value.) For example E:\vbox7, so cd E: and then just use .\vbox7\ or vbox7 like the example below the command corrections...

          icacls <Directory> /grant '*S-1-5-32-545:(OI)(CI)(RX)'
          icacls <Directory> /deny  '*S-1-5-32-545:(DE,WD,AD,WEA,WA)'
          icacls <Directory> /grant '*S-1-5-11:(OI)(CI)(RX)'
          icacls <Directory> /deny  '*S-1-5-11:(DE,WD,AD,WEA,WA)'

So for example:

PS E:\> icacls vbox7 /grant '*S-1-5-32-545:(OI)(CI)(RX)'
processed file: vbox7
Successfully processed 1 files; Failed processing 0 files

PS E:\> icacls .\vbox7\ /deny  '*S-1-5-32-545:(DE,WD,AD,WEA,WA)'
processed file: .\vbox7\
Successfully processed 1 files; Failed processing 0 files

... (the rest of the commands)

[agrajagco]

Continuing on the recovery effort; None of your existing VM's will load because they are not on a hypervisor filesystem (per the error message on attempt to load).

I'm working on moving the VMS out of their default locations, and a powershell script to automate cycling through the paths setting these required commands including the grant/deny, but it seems insane to target C:\Users\[username]\Virtualbox VMs\ default pathing with this documented change.

I'm moving the filesystems to a volume that can be isolated and is out of the users home directory in any way.

All of this has pretty much made VirtualBox on windows no longer usable by people just learning or getting started with VM technology. This is unfortunate, as I've used it in the past in training situations. Obviously this is some kind of critical security related change that is a must-do on windows.

I have been trying to pay for individual use of virtualbox for years now, but Oracle is not set up to deal with consumers in any way. Honestly the dev's need to clue us in if this is the advent of virtualbox exiting the consumer usage space, or just a very difficult release that is going to be worked through to restore windows functionality...

Regardless thanks for the great tool over the years to the dev's...

[computeruser]

Version 7.14 allows for installation at the root directory of any drive, apparently. Had success with both:

E:\Oracle\VirtualBox and G:\Oracle\VirtualBox

although the above problem persists for non-root directories such as E:\Utility\Oracle\VirtualBox

[vb user]

Replying to computeruser:

Version 7.14 allows for installation at the root directory of any drive, apparently. Had success with both:

E:\Oracle\VirtualBox and G:\Oracle\VirtualBox

although the above problem persists for non-root directories such as E:\Utility\Oracle\VirtualBox

That's strange - I got the same error message about invalid directory. What OS are you running?

Fortunately, using Orca to drop those 3 lines of "VBox_Target_Dir_Is_Valid" worked fine. Of course, I got a fatal installation error at the end (even when I ran the regular .exe to "repair" the install, but didn't seem to affect the application - as my existing Ubuntu VM booted without any issues.

However - now that ​VMWare/Broadcom's Workstation Pro is free - might just be worth the trouble to see if the export function will work and not worry about having to edit .msi files.