Many executables refuse to run fom Shared Folders

[Technologov]

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.

[Technologov]

Example: CPU-Z freeware

[Technologov]

Another Example: 7-zip (v4.65)

[Technologov]

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

[Technologov]

Win7 32bit VM Log

[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.

[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?

[Technologov]

1. Windows Explorer

2. Mapped to a drive

-Technologov

[Technologov]

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

[sunlover]

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

[Technologov]

win7_error_opening_exe.JPG screenshot

[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

[Chris Brown]

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.

[Technologov]

Shared folders are still broken.

VBox 3.2.0-BETA1.

-Technologov

[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?

[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

[Technologov]

Any news on this one?

[Technologov]

This problem still plagues me.

-Technologov

[sunlover]

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

[Technologov]

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

-Technologov

[sunlover]

Yes, it is reproducible.

[Technologov]

This problem still exists in 3.2.6-BETA1.

-Technologov

[matteo sisti sette]

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.

[Frank Mehnert]

​This doesn't help, does it?

[kermit]

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

[matteo sisti sette]

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.

[Frank Mehnert]

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

[kermit]

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

[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

[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

[matteo sisti sette]

@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.

[kniwor]

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

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

[Technologov]

This bug still exists in 4.0.4

-Technologov

[Alex Bobryshev]

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

[Frank Mehnert]

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