VirtualBox

Opened 14 years ago

Last modified 11 years ago

#7160 closed defect

some applications cannot access shared folders in windows 7 guest — at Version 13

Reported by: matteo sisti sette Owned by:
Component: shared folders Version: VirtualBox 3.2.6
Keywords: shared folders, access Cc:
Guest type: Windows Host type: Linux

Description (last modified by Frank Mehnert)

I installed Guest Additions on the Windows Guest, created a shared folder, connected it as a network drive in Windows Guest.

The shared folder works, I can read and write to it from the guest, and browse it with Windows Explorer, however:

  • most applications show it with a red "X" on it as if it was not accessible
  • many application will be able to open, browse, read from and write to it despite showing the red X
  • SOME applications will instead refuse to open the network drive and give an "access denied" error. For example you can't open an HTML file residing on the network drive with Internet Explorer
  • .air packages (installation packages for adobe AIR) won't install if run from the shared folder (you have to copy them to the virtual disk, then they will work). The air will run from the network drive, but when it is supposed to ask for confirmation to switch to admin privileges, istead of popping the dialog, it will output an error message and abort installation

The last issue is indeed a special case of the previous one: AIR installer cannot handle properly the .air file residing on the network drive.

There seems to be a privilege issue with shared folders.

Host: Ubuntu 10.04 32bit
Guest Windows 7 64bit

Change History (17)

comment:1 by Technologov, 14 years ago

Looks related to bug #5732, possibly a duplicate.

  1. Only execute fails, right ? (you can copy files normally)
  1. If you use "Administrator" account the problem is gone in my case. Please try it.

-Technologov, 13.7.2010.

comment:2 by matteo sisti sette, 14 years ago

It is probably related, but this is definitely not the same issue described there. Indeed this probably INCLUDES that issue as a special case.

Not only executing fails, much more. As I mention, also OPENING files, or BROWSING folders from some applications fails.

For example open Internet Explorer and chose File/Open and browse for some html file in the shared folder, it will not open (it will show the same error page as if you try to access the internet without connection). Some other applications, when browsing for opening or saving a file, won't even let me open the shared folder (network drive) for browsing.

However, Windows Explorer (i.e. browsing folders from "My Computer") does work without problems, So yes, I can COPY a file, including an exe file from (or to for what matters) the shared folder.

It seems to me that some permissions are denied when trying to access the shared folder. However some of the cases where the access fails shouldn't need admin privileges at all: for example you shouldn't need to be admin to open a html file located on a network drive.

comment:3 by matteo sisti sette, 14 years ago

By the way I now realise my original post is hardly readable, I'm sorry. I wrote it properly, but this form eliminates single linebreaks without warning the user of it.

comment:4 by Frank Mehnert, 14 years ago

Component: othershared folders
Description: modified (diff)

by Alex Bobryshev, 12 years ago

Attachment: vbox7160_patch_test.zip added

by Alex Bobryshev, 12 years ago

comment:5 by Alex Bobryshev, 12 years ago

I found reason of this behavior and ways to bugfixing.

32-bits applications that not using functions from mpr.dll works normally.

But 32-bits applications that using functions from mpr.dll (WNetGetConnection and other) for works with VirtualBox shared folders cannot work properly on x64 systems. That support provided by VBoxMRXNP.dll from shared folders addition, that dll loaded in user mode for processes that using network functions.

But x32 applications cannot use x64 dlls! VBoxMRXNP.dll in x64 systems is x64 dll.

Really I think this issue provided more that once bug on x64 systems.

The problem was not in source code. We need two versions of VBoxMRXNP.dll for x64 systems: x64 and x86.

VBoxMRXNP.dll x64 version must be copied to <SystemDir>\System32 directory (now)

VBoxMRXNP.dll x86 version must be copied to <SystemDir>\SysWOW64 directory (this is solution to bugfix)

There are 3 ways to fix this problem:

  1. Patch VirtualBox build conveyor

This is preferred way, but more complex. For build x64 version of VirtualBox we need compile both versions x86 and x64.

I don't know how conveyor works at this time. But if strategy of building is not like there, it will be many problems.

  1. Patch GuestAdditions installator after builds
  1. Patch guest system - temporary solution for bugfix demonstration.

I wrote a small programs which releases third way. They sources and binaries were attached.

vboxsf64_fix.exe - program for patch. Near it there is a VBoxMRXNP.dll x86.

vboxsf64_fix.exe works only on x64 systems and requires administrator privilegies. It copies VBoxMRXNP.dll (x86) to <SystemDir>\SysWOW64 directory.

vboxsftest32.exe and vboxsftest64.exe demonstrates a bugfix. It calls WNetGetConnection function.

  1. Connect virtualbox resource as disk (for example X:)
  1. Run tests:
    vboxsftest32 X:
    vboxsftest64 X:

Success result:

Try to open network connection x:
WNetGetConnection returned 0.
Buffer: \vboxsrv\VMTEMP

Error result:

Try to open network connection x:
WNetGetConnection returned 1203.

vboxsftest64.exe must have success result always.

vboxsftest32.exe have error result before patch and success result after patch. Also you may try to open file run Internet Explorer to try bugfix. It will be successfully open files from VBox shared folder by any method:

X:\ttt.htm

\VBOXSVR\VMTEMP\ttt.htm

comment:6 by Technologov, 12 years ago

Can u come to #vbox channel plz ?

32-bit Windows guest OSes also affected.

-Technologov

comment:7 by Frank Mehnert, 12 years ago

helloworld, just to give you some feedback: Thanks for this information. We will check this.

comment:8 by Alex Bobryshev, 12 years ago

It seems that my last updates will be fix this problem. But I'm not sure that it will be work properly on all x86 systems (XP, Vista, 7). Please check solution.

There is 'VBoxSF.sys' in attachment in archive. Please copy it to %WindowsDir%\System32\drivers (with replacing old version) on x86 systems.

by Alex Bobryshev, 12 years ago

Attachment: VBoxSF_19_12_2011.zip added

comment:9 by Alex Bobryshev, 12 years ago

Updated issue solution. There are some changes to file 'netroot.c' (it fix some artifacts from issue 7160 now). It placing at src\VBox\Additions\WINNT\SharedFolders\redirector\sys\netroot.c in VBox sources. Same file attached to issue #9753

by Alex Bobryshev, 12 years ago

Attachment: netroot.c added

comment:10 by matteo sisti sette, 12 years ago

Hi helloworld,

I've downloaded your zip and tried the tests (I haven't tried the patch yet), but BOTH 32 and 64 test fail, while you said that the 64 test should succeed even before the fix!!

Is the attached zip the latest version of the fix? Should I try it anyway?

I have Windows 7 64bit guest on a Ubuntu 11.10 32bit host.

comment:11 by matteo sisti sette, 12 years ago

WHOPS sorry, forget about it, I was running the exe's without the parameter (X:)

64 test succeeds before the fix as expected, will try the patch now!

comment:12 by array, 12 years ago

I have a 4.1.8 64bit linux host and a 32 bit windows 7 guest and i tested to run a php application from a host share. Php fails in detail: the 'is_readable' function of php reports perfectly readable files as not readable. Don't know where the Problem is based. Windows, PHP or VirtualBox?

comment:13 by Frank Mehnert, 12 years ago

Description: modified (diff)

Could you try if this test build fixes your problems with shared folders in Windows guests?

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use