Discuss the VirtualBox 7.0.18 release here

[abcuser]

Hi,
Windows 11 as host I would like to install VirtualBox v7.0.18 in folder C:\Programs, but program does not allowed to be installed into this folder because of incorrect permissions, looks like new security feature of v7.0.18 installer.

1. I opened cmd as Administrator and execute commands suggested by https://www.virtualbox.org/manual/UserM ... alldir-req (step 1 on image bellow)
2. I have right clicked on VirtualBox installer file and selected "Run as Administrator" and installation started. In installer I changed path from program suggested "C:\Program files\Oracle\VirtualBox" to "C:\Programs\Oracle\VirtualBox" (step 2 on image). NOTE: I only have C:\Programs directory, I don't have C:\Programs\Oracle, this directory is expected to be created by installer.
3. Installation started and then failed with error of insufficient rights (step 3 on image). Strange program is complaining about C:\Programs\Oracle that is directory that should be created by installer by themself.
4. OK, maybe installer expects folder C:\Programs\Oracle. In Windows Explorer I right clicked on New | Folder to create new folder inside C:\Programs and I have got error of access denied. It looks like I can't create a new folder in C:\Programs anymore. I started cmd with administrator rights and "cd C:\Programs" and "md Oracle" and I have got error "Access is denied." Interesting I can't change any files/directories or create new one under C:\Programs with Administrator anymore.

install.png (132.06 KiB) Viewed 1978 times

Any idea how to follow?

P.S. I've checked all of the programs that are installed as subfolders of C:\Programs and all of them work without an issue, at least so far.

[okcrum]

The 7.0.18 Linux "all distributions" .run package is missing a Guest Additions .iso image.

I've reverted to 7.0.16 on Ubuntu Studio 24.04 from the all distributions package, which is complete.

Hi okcrum,

What makes you think that? Guest Additions .iso is in place /opt/VirtualBox/additions/VBoxGuestAdditions.iso.

There's no "Upgrade Guest Additions" choice highlighted or .iso mounted (or mountable) when you run VM after install from the 7.0.18 .run file. All that is there in 7.0.16. I'll try again and see if the .iso is actually there, and the VM install just isn't picking it up properly.

EDIT: It appears the upgrade choice just gets missed during install. I mounted and ran the 7.0.18 GA install manually instead of from VM.

[galitsyn]

The 7.0.18 Linux "all distributions" .run package is missing a Guest Additions .iso image.

I've reverted to 7.0.16 on Ubuntu Studio 24.04 from the all distributions package, which is complete.

Hi okcrum,

What makes you think that? Guest Additions .iso is in place /opt/VirtualBox/additions/VBoxGuestAdditions.iso.

There's no "Upgrade Guest Additions" choice highlighted or .iso mounted (or mountable) when you run VM after install from the 7.0.18 .run file. All that is there in 7.0.16. I'll try again and see if the .iso is actually there, and the VM install just isn't picking it up properly.

"Upgrade Guest Additions" is active only when current Guest Additions are running inside guest (VBoxService process should be running). But you can always use "Insert Guest Additions CD Image" option to install them manually.

[okcrum]

"Upgrade Guest Additions" is active only when current Guest Additions are running inside guest (VBoxService process should be running). But you can always use "Insert Guest Additions CD Image" option to install them manually.

I think the warning below is new in 7.0.18 (or I triggered it for the first time) - once GA is manually installed it's of no consequence.That's what led me to think the .iso was missing.


https://www.topsail.org/goodies/VMdialog.png if above fails

[multiOS]

Please avoid 'Image' links on the Forum - they don't work if the file isn't accessible and most Forum users are unlikely to 'visit' unknown links if they value their own security. Use the upload attachment Tab on the message screen instead

[TPeterson]

There is a problem with saving the state of the VM. I'm on a Linux Mint host with 7.0.18 and a Windows 10 VM. The VM is never saved. The progress indicator sticks at 0% and does nothing. You have to kill the process to get out of it....

I'm seeing a similar behavior from 7.0.18 with a Windows XP vm hosted in Windows 11.

[oberusza]

The virtual disk on which my virtual machine is running is encrypted. VirtualBox version 7.0.18 cannot unlock it, so I cannot start the virtual machine. I have downgraded the VirtualBox version back to 7.0.16, on this version disk unlock still works.
The host runs on Windows 11 Pro.

[multiOS]

@oberusza

For clarification, when you upgraded VirtualBox to version 7.0.18, did you also upgrade the Extension Pack to 7.0.18? These two software installations must match; and, as the VirtualBox encryption feature is provided by the Extension Pack, failing to upgrade both at the same time may be a cause of failure.

[klaus]

With 7.0.18 this is especially true because it is signed with a newer cert/key. Which unfortunately means that the 7.0.16 extpack won't work it it at all. Usually it's not that strict, but this time it has to be...

[notandor]

There is a problem with saving the state of the VM. I'm on a Linux Mint host with 7.0.18 and a Windows 10 VM. The VM is never saved. The progress indicator sticks at 0% and does nothing. You have to kill the process to get out of it....

I'm seeing a similar behavior from 7.0.18 with a Windows XP vm hosted in Windows 11.

Same story with Fedora 40 kernel 6.8.9 host and Windows 7 client. A 'lighter' w7 does save state but I can't re-create that vm easily. Unfortunately I can't go back to 7.0.14 either, that version has too many issues with the network driver under this kernel.

[NAILS]

I'm still running 7.0.14 on win11, holding back the upgrade until more was known about 7.0.18. Because I'd rather not reconstruct again my vm's that were killed in the 7.0.16 upgrade. (my fault, I didn't take a backup) The guest vm's are Linux, with encrypted virtual disks.

Reading all this feedback, I am wondering if its safe to upgrade from 7.0.14 at all. Or is it ?

[systemdlete]

I'm still running 7.0.14 on win11, holding back the upgrade until more was known about 7.0.18. Because I'd rather not reconstruct again my vm's that were killed in the 7.0.16 upgrade. (my fault, I didn't take a backup) The guest vm's are Linux, with encrypted virtual disks.

Reading all this feedback, I am wondering if its safe to upgrade from 7.0.14 at all. Or is it ?

I've been wondering the same thing for 2 weeks since 7.0.18 was released. But I'm running all of my VMs on Devuan Linux (chimaera/bullseye and daedalus/bookworm) hosts, so maybe the situation is different for us. I do not run Windows here at all. Another possible difference is that while I also use encrypted disks, I am using Linux encryption in my VMs, not virtualbox's encryption.

I have hesitated on upgrading my systems to 7.0.18, except for a test box running devuan daedalus (bookworm) with a daedalus VM and another smaller linux VM, which seem to be running ok with 7.0.18. But after the 7.0.16 problems, and (granted, only a few) reported issues with this new release, I am still hesitant.

I almost hate to report my reticence about this new release because I know that the virtualbox devs are probably still getting pummeled over the 7.0.16 release, but I still think it is important to approach this with some caution.

[bmaehr]

We didn't raise the bar "just because". The directory permissions are actually exactly those used by C:\Program Files by default. The point is to protect the VirtualBox install against tampering by malware running with normal user privileges.

I prefer to stay with version 7.0.14 if that is not changed. I'm not going to change a lot of permission or directory structure just because some i... wants to have that for his software.

Don't you realize that the people are tired about all these pseudo security actions the companies are doing to deviate from their failures? How many sucessful attacs on prive computers because of these permission thing you know? I'm sure it is exactly zero. Same with this 2FA bullshit for ever SPAM_SEARCH little page. Or password restrictions because you are not able to implement a working brute force protection.

[oberusza]

@oberusza

For clarification, when you upgraded VirtualBox to version 7.0.18, did you also upgrade the Extension Pack to 7.0.18? These two software installations must match; and, as the VirtualBox encryption feature is provided by the Extension Pack, failing to upgrade both at the same time may be a cause of failure.

Damn! You were right, I completely forgot about the Extension Pack, since "PatchMyPC" updates my softwares, I still had the 7.0.14 Extension Pack installed...
I upgraded VirtualBox to 7.0.18 again, then installed the 7.0.18 Extension Pack, and it worked fine.
Sorry for my inattention. It was a user error.
Thanks for the help!

[NAILS]

Also, it's not quite clear what the windows install directory issue is. But I can tell already internal IT won't allow me to mess with access privileges. Nor are they of the understanding kind when it comes to bending the rules.

So, not quite sure either what to do with this...