VirtualBox

Ticket #7160 (closed defect: fixed)

Opened 4 years ago

Last modified 11 months ago

some applications cannot access shared folders in windows 7 guest

Reported by: matteosistisette Owned by:
Priority: critical Component: shared folders
Version: VirtualBox 3.2.6 Keywords: shared folders, access
Cc: Guest type: Windows
Host type: Linux

Description (last modified by frank) (diff)

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

Attachments

vbox7160_patch_test.zip Download (340.8 KB) - added by helloworld 2 years ago.
vbox7160_patch_test_source.zip Download (82.2 KB) - added by helloworld 2 years ago.
VBoxSF_19_12_2011.zip Download (117.8 KB) - added by helloworld 2 years ago.
netroot.c Download (13.9 KB) - added by helloworld 2 years ago.

Change History

comment:1 Changed 4 years ago by Technologov

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 Changed 4 years ago by matteosistisette

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 Changed 4 years ago by matteosistisette

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

  • Component changed from other to shared folders
  • Description modified (diff)

Changed 2 years ago by helloworld

Changed 2 years ago by helloworld

comment:5 Changed 2 years ago by helloworld

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 Changed 2 years ago by Technologov

Can u come to #vbox channel plz ?

32-bit Windows guest OSes also affected.

-Technologov

comment:7 Changed 2 years ago by frank

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

comment:8 Changed 2 years ago by helloworld

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.

Changed 2 years ago by helloworld

comment:9 Changed 2 years ago by helloworld

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

Changed 2 years ago by helloworld

comment:10 Changed 2 years ago by matteosistisette

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 Changed 2 years ago by matteosistisette

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 Changed 2 years ago by array

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

  • Description modified (diff)

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

comment:14 Changed 2 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

No response, closing.

comment:15 Changed 11 months ago by henryju

Could you please reopen this bug. I faced the same issue and I am ready to help you by testing.

Host: Linux Fedora x86_64 + Virtual Box 4.2.12 Guest: Windows XP x86 + Virtual Box Guest additions 4.2.12

PHP is_readable function returns false on any file accessed throw a VBox shared folder. File is readable and I can copy it to C: using Windows Explorer.

comment:16 Changed 11 months ago by sunlover

henryju, please open a new ticket because this is a different issue.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use