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.