VirtualBox

Ticket #5732 (new defect)

Opened 4 years ago

Last modified 7 months 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.

Attachments

Windows 7 32bit-2009-12-12-00-39-58.log Download (53.8 KB) - added by Technologov 4 years ago.
Win7 32bit VM Log
win7_error_opening_exe.JPG Download (100.0 KB) - added by Technologov 4 years ago.
win7_error_opening_exe.JPG screenshot

Change History

comment:1 Changed 4 years ago by Technologov

Example: CPU-Z freeware

comment:2 Changed 4 years ago by Technologov

Another Example: 7-zip (v4.65)

comment:3 Changed 4 years ago by Technologov

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

Changed 4 years ago by Technologov

Win7 32bit VM Log

comment:4 Changed 4 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 4 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 4 years ago by Technologov

  1. Windows Explorer
  1. Mapped to a drive

-Technologov

comment:7 Changed 4 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 4 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 4 years ago by Technologov

win7_error_opening_exe.JPG screenshot

comment:9 Changed 4 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.

-Technologov

comment:10 Changed 4 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 4 years ago by Technologov

Shared folders are still broken.

VBox 3.2.0-BETA1.

-Technologov

comment:12 Changed 4 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 4 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)

-Technologov

comment:14 Changed 4 years ago by Technologov

Any news on this one?

comment:15 Changed 4 years ago by Technologov

This problem still plagues me.

-Technologov

comment:16 Changed 4 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 4 years ago by Technologov

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

-Technologov

comment:18 Changed 4 years ago by sunlover

Yes, it is reproducible.

comment:19 Changed 4 years ago by Technologov

This problem still exists in 3.2.6-BETA1.

-Technologov

comment:20 Changed 4 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 4 years ago by frank

 This doesn't help, does it?

comment:22 Changed 4 years ago by kermit

Disable UAC (User Access Control) and it works. How to:  http://www.petri.co.il/disable-uac-in-windows-7.htm

comment:23 Changed 4 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 4 years ago by frank

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

comment:25 Changed 4 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 3 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" ?

-Technologov

comment:27 Changed 3 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 ?

-Technologov

comment:28 Changed 3 years ago by matteosistisette

@Technologov:

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 3 years ago by kniwor

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

 http://support.microsoft.com/kb/303308

comment:30 Changed 3 years ago by Technologov

This bug still exists in 4.0.4

-Technologov

comment:31 Changed 2 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 2 years ago by frank

  • Description modified (diff)

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

comment:33 Changed 2 years ago by Technologov

Tested 4.1.9. FAIL.

-Technologov

comment:34 Changed 2 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  http://support.microsoft.com/kb/2019185

comment:35 Changed 2 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.

-Technologov

comment:36 Changed 2 years ago by sunlover

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

comment:37 Changed 2 years ago by Technologov

Yes, it works with unmapped driver.

-Technologov

comment:38 Changed 2 years ago by Technologov

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

comment:39 Changed 2 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 2 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 20 months ago by oogrff

Do

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

or

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 9 months 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:  http://www.howtogeek.com/70012/what-causes-the-file-downloaded-from-the-internet-warning-and-how-can-i-easily-remove-it/

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 9 months ago by VMTom (previous) (diff)

comment:43 Changed 9 months 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:  http://sourceforge.net/projects/dia-installer/files/dia-win32-installer/0.97.2/

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

comment:44 Changed 7 months 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 7 months 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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use