Ticket #5732 (new defect)

Opened 8 years ago

Last modified 6 weeks ago

Many executables refuse to run fom Shared Folders

Reported by: Technologov Owned by:
Priority: major Component: shared folders
Version: VirtualBox 3.1.0 Keywords:
Cc: Guest type: Windows
Host type: Windows

Description (last modified by frank) (diff)

About 50% of all Windows executables refuse to run from Shared Folders (vboxsf).

The same executable work perfectly from mounted SMB shares.

Host: Windows XP, Core 2 Q6600, VBox 3.1.0

Guest: Windows 7, 64-bit.

-Technologov, 12.12.2009.


Windows 7 32bit-2009-12-12-00-39-58.log Download (53.8 KB) - added by Technologov 8 years ago.
Win7 32bit VM Log
win7_error_opening_exe.JPG Download (100.0 KB) - added by Technologov 8 years ago.
win7_error_opening_exe.JPG screenshot
ModificacionsPermisosXarxa.png Download (131.8 KB) - added by Cat_Is_Not_SP 2 years ago.
VirtualBox-Edge-UAC-Screenshot from 2017-02-13 01-22-16.png Download (59.3 KB) - added by Nickie 8 months ago.
Error message from Microsoft Edge after changing group policy to let EXEs run

Change History

comment:1 Changed 8 years ago by Technologov

Example: CPU-Z freeware

comment:2 Changed 8 years ago by Technologov

Another Example: 7-zip (v4.65)

comment:3 Changed 8 years ago by Technologov

This also happens with Windows 7 and Vista 32-bit.

Changed 8 years ago by Technologov

Win7 32bit VM Log

comment:4 Changed 8 years ago by Technologov

Correction about 7-zip: Only 32-bit version of 7-zip v4.65 fails to start on Windows 7 32 and 64-bit VMs. 64-bit version of 7-zip starts fine on Windows 7 64-bit VM. SMB works in all cases.

comment:5 Changed 8 years ago by sunlover

How exactly did you start applications? From Command Prompt window? With mouse click in Windows Explorer? etc?

Do you access the shared folder via \vboxsvr UNC path or it is mapped to a drive letter?

comment:6 Changed 8 years ago by Technologov

  1. Windows Explorer
  1. Mapped to a drive


comment:7 Changed 8 years ago by Technologov

One more detail: If I copy the problematic executables to the VM via Shared Folders, they are executed fine.

comment:8 Changed 8 years ago by sunlover

Do applications run when they are started from Command prompt? If they do not run, is there an error message?

Changed 8 years ago by Technologov

win7_error_opening_exe.JPG screenshot

comment:9 Changed 8 years ago by Technologov

7-zip is Open-Source, and you can download it.

Tried twice from command prompt, and it fails. As you see in the attached screenshot, there is answer in command prompt, and answer in GUI.


comment:10 Changed 8 years ago by crash0veride

I have also noted this exact behavior in windows guests. VirtualBox host OS being linux or windows does not change the behavior. My test case was to install the target guest OS and after adding the guest additions map a shared folder and try to run an executable from the share, one example was the Intel Storage Driver installer "IATA89ENU.exe" which failed to run with the above reported windows error.

I have observed this under the following guests

  • Windows XP Professional x64
  • Windows XP x86 SP3
  • Windows Vista Ultimate x64 SP2
  • Windows 7 Ultimate x64

Strangely I did not see this under a Windows Server 2003 R2 x64 SP2 guest, but I may have not been diligent enough to sift through enough executables to run the error.

comment:11 Changed 7 years ago by Technologov

Shared folders are still broken.

VBox 3.2.0-BETA1.


comment:12 Changed 7 years ago by sunlover

Technologov, did you run these executables from an administrator account or from a normal user account? Could you test if this makes any difference?

comment:13 Changed 7 years ago by Technologov

Problem happens only when you run normal user account. Works with Administrator account.

Try 7-zip, 32-bit, v4.65. It is Free/OSS.

Vista/7 guests only. (32/64-bit)


comment:14 Changed 7 years ago by Technologov

Any news on this one?

comment:15 Changed 7 years ago by Technologov

This problem still plagues me.


comment:16 Changed 7 years ago by sunlover

  • Priority changed from critical to major

We do not know why it does not work. Workaround is of course to use an admin account.

comment:17 Changed 7 years ago by Technologov

Can you reproduce the scenario ? (using 32-bit 7zip installer.exe)


comment:18 Changed 7 years ago by sunlover

Yes, it is reproducible.

comment:19 Changed 7 years ago by Technologov

This problem still exists in 3.2.6-BETA1.


comment:20 Changed 7 years ago by matteosistisette

Still not fixed in 3.2.8

What do you mean by Administrator account? I use the default Window configuration where you have only one user, that "is" an administrator but not quite "the" administartor, and whenever you try to do something that needs admin privileges it simply asks you for a confirmation.

Still, executing some executables from a shared folder fails.

It seems to fail with ALL executable that would normally ask you for the confirmation, i.e. exes that need (and try) to run as admin. Normally they should ask for confirmation. Instead, they fail.

But it seems also SOME exes that don't need admin privileges fail as well.

comment:21 Changed 7 years ago by frank

 This doesn't help, does it?

comment:22 Changed 7 years ago by kermit

Disable UAC (User Access Control) and it works. How to:

comment:23 Changed 7 years ago by matteosistisette

Yes of course, just like it works if you use the administrator account.

Anyway it's a major inconvenience to be obliged to disable UAC, not an acceptable solution in most cases. Still needs to be fixed.

However I still have to try the new version that was released a few days ago and see whether it's fixed.

comment:24 Changed 7 years ago by frank

No it's not fixed as we still have no idea _how_ to fix it.

comment:25 Changed 7 years ago by kermit

Agree, this is not a fix, however at least a workaround for all those not knowing how to logon as an Administrator.

comment:26 Changed 7 years ago by Technologov

Yes, disabling UAC solved the problem for me (Win 7 x64 guest).

This is not clear to me why this problem happens with some executables, but not others.

Maybe upping the priority of this service could help ? -- I mean running the service as a different system user. VBox Shared Folders is consolidated under "VBoxService" ?


comment:27 Changed 7 years ago by Technologov

For VBox Shared Folders, it seems, that there is no service at all, just a driver; VBoxGuest.sys

According to chapter "4.3. Shared folders", it is a pseudo-network redirector driver.

Since MS SMB works perfectly, the next question is: What's the difference between Microsoft SMB network redirector driver and VBox SF ?


comment:28 Changed 7 years ago by matteosistisette


This is not clear to me why this problem happens with some executables, but not others.

I think it happens when the executable needs administrator privileges. If everything was working properly, a popup would appear asking for the administrator password. Instead, it just fails to run.

Not 100% sure however.

comment:29 Changed 7 years ago by kniwor

I'm sure someone has pointed this out before, this has clearly to do with this

comment:30 Changed 7 years ago by Technologov

This bug still exists in 4.0.4


comment:31 Changed 6 years ago by helloworld

I think this issue is effect from bug #7160. I found ways to fix it. Please retest this bug after applying patch

comment:32 Changed 6 years ago by frank

  • Description modified (diff)

Could you try if  this test Additions test build fixes your problems?

comment:33 Changed 6 years ago by Technologov

Tested 4.1.9. FAIL.


comment:34 Changed 6 years ago by sunlover

And what fails exactly?

Note that if an application will cause an UAC dialog, then it will not run from a shared folders mapped to a drive letter. Such applications must be started using an UNC path: \\vboxsvr\folder\app.exe

This is a known issue. For example described in

comment:35 Changed 6 years ago by Technologov

Yes, the UAC is broken.

But my problem is not the same error above... I have error on execute, not on file copy. I can copy any file however I wish.

I get error: "The specified path does not exist", when I try to execute "7-zip" program (32-bit) on default Vista or Win7 installs (32 or 64bit). See attached screenshot.


comment:36 Changed 6 years ago by sunlover

Does it work is you start the executable using an UNC path \\vboxsvr\...?

comment:37 Changed 6 years ago by Technologov

Yes, it works with unmapped driver.


comment:38 Changed 6 years ago by Technologov

One possible fix would be: to use VBoxSF Auto-Mount with "elevated privileges".

comment:39 Changed 6 years ago by sunlover

Then this is the same issue as described in the MS KB article: a drive letter is accessible only by a particular user account. UNC is a system wide path, so it works.

We do not know how to work around this Windows feature. Even if the drive letter is mapped in an admin command line window, the system does not start such applications from a "normal" window.

The current resolution to this ticket is "wontfix", because we do not have enough time to investigate, there are other things to do. An UNC path or an admin cmd window should be used to run such applications from VBox shared folders.

comment:40 Changed 6 years ago by pwabrahams

The problem doesn't just affect executables. I have the same problem in the "file open" dialog of an application. The attached network drives don't show up, and I haven't found any way to access them.

comment:41 Changed 5 years ago by oogrff


Control Panel - Network and Internet - Internet Options - Security - Trusted Sites - Sites - Add "VBOXSVR" as a website


gpedit.msc - Computer Configuration - Administrative Templates - Windows Components - Internet Explorer - Internet Control Panel - Security Page - Size to Zone Assignment List - Add "VBOXSVR" to "2" and reboot.

Fixed it for me.

comment:42 Changed 4 years ago by VMTom

Hi all, I was hit by the same problem and found a solution (at least for me):

Copying the files showing this behavior to a FAT32 formatted drive, then copying back to the 'share'/'mapped drive'/'UNC' solved the problem for me.

Now I am able to open those files from the VBOX mapped location.

Possible background:

(post edited:) better info than I gave below, can be found at:

IIRC MS will add some info to the file (on the filesystem) if the exe-file was downloaded from anywhere else than from intranet- or trusted-zone. Then preventing run under some security considerations which may differ in a Workgroup/Domain and/or your personal setup.

Copying the file to a FAT32 partition will remove/detach this information from the file, as FAT32 is not able to store/associate this information with this file. As the FAT32 will be probably local to your acting PC, copying it back to the share will not reapply this information to the file, as it is considered to be copied from a 'trusted'(local intranet) location...

Hope, this will help others to solve this nasty annoyance

Last edited 4 years ago by VMTom (previous) (diff)

comment:43 Changed 4 years ago by VMTom

Ok - seems, my solution in my last post just worked for 'some' of the problematic setup.exe.

Those who still refuse are NSIS type installers with either: a) not signed b) signed with an outdated (therefore invalid) certificate. You may test with e.g.: 'DIA' setup-program found at (outdated signed, and an unsigned version) donwnloadable at:

So we still need som hacking to mitigate this... (anybody with a known 'elegant' solution out there?

comment:44 Changed 4 years ago by TrentonF

Hi all,

I ran into this same problem. I tried to run an executable and received a "path not found" error. I was attempting to run the executable from a shared drive. When I moved the .exe file to the C: Drive of my Virtual Machine and dropped it in my user/downloads folder it ran as expected.

I ran it under an admin account. I hope this helps some of you :)

comment:45 Changed 4 years ago by klaus

Note that for Windows the shared folders are network filesystems, and this means that some additional safety checks are activated in recent Windows versions. Maybe it'd help to disable those.

comment:46 Changed 3 years ago by avd

This is a windows permission problem. To get it to run, I had to remove UAC, by going into Control Panel, typing in UAC in the search and selecting "change user account control settings". Next, slide the slider all the way down so it says "never notify me". Reboot your PC and now you can run the EXE file from the network drive. Unfortunately this step pokes additional holes in windows security, but it's a temporary workaround until someone more knowledgeable with windows can figure out how to only enable this feature without disabling everything else.

Changed 2 years ago by Cat_Is_Not_SP

comment:47 Changed 2 years ago by Cat_Is_Not_SP

Goggling it after reading previous posts I found a solution that worked for me without changing all the security permissions under UAC as commented on previous post, just network settings.

1- On Windows start menu search, type "gpedit.msc" and execute it
2- Browse for "Local Computer > Windows settings > Security settings > Security options"
3- Change following policies. (by the end of list)

A- User account control: Behaviour of the elevation prompt for admin.." >> Elevate without prompting
B- User account control: Run all administrators in admin approval" >> Disabled
C- User account control: Switch to secure desktop when prompt.." >> Disabled

This worked for me, keeping UAC to default value.

Last edited 2 years ago by Cat_Is_Not_SP (previous) (diff)

comment:48 Changed 8 months ago by Nickie

I have this problem with Ubuntu 16.04 host and Windows 10 Pro guest. The workaround above is useful but insufficient. It is impossible to use Microsoft Edge as the default browser. Edge refuses to run with the policy tweaked as shown in the gpedit.msc screenshot in the prior post.

I think this issue needs investigation and a real solution.

In case it is relevant, I have two other symptoms. 1. There is no Security Tab on any of the Windows File Property dialogs. Therefore it is impossible to set file permissions on the VBoxSharedFolderFS. 2. Microsoft IIS claims it cannot read web.config in any folder, which would normally be cured by resetting the file permissions. This happens on the shared folder and it ALSO happens when I place the files on C which is NTFS (.vdi file).

My shared folder is 'ext4' on the Linux host.

Changed 8 months ago by Nickie

Error message from Microsoft Edge after changing group policy to let EXEs run

comment:49 Changed 4 months ago by Ashark

Changing "User Account Control: Run all administrators in Admin Approval Mode" in Local Group Policy Editor actually changes EnableLUA registry key, so it is the same solution as editing registry. Also, afaik, windows home editions lack possibility to edit group policies.

In win8 and win10 it is  insufficient to just move slider to never notify, as it was in win7. UAC actually remains working and prevent launching exe from network folders.

To easily change EnableLUA key, you can create a reg file and apply it. Just create a new text file, paste contents there and replace txt extension to reg. Before you merge this reg file, you are not able to merge reg files from network folder.


Windows Registry Editor Version 5.00



Windows Registry Editor Version 5.00


Or you can download both files in one archive from  this site.

After merging, reboot windows and enjoy launching exe from network folders!

comment:50 Changed 6 weeks ago by joho68

There are issues with doing directory listings as well. I have a DOS program, running in a CMD window in a Windows XP Guest. The Host is Windows 10 running VB 5.x. I have a Host folder mounted as a persistent share for XP.

I have a directory with 63 .MSG files. Listing them in the Windows Explorer shows them all fine. Listing them via DIR from the CMD command-line works fine. When a DOS program attempts to issue findfirst() / findnext() calls to retrieve a list of .MSG files, it does not work. The error message received from "DOS" is ENOENT (File not found, 2).

This is repeatable, 100 out of a 100 times.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use