virtualbox.org

The shared folders in VirtualBox act strangely, at least in Windows guests (on Windows hosts). I can't install software from them, like I can from any normal Windows mapped drive or UNC path. Normally, you can just double-click the setup.exe from a share and it runs and installs. But in VB it errors out, so I have to copy the setup files to the guest then execute. Why doesn't this work?

This in particular boggles my mind. Running a silent install from an admin CMD window (required) fails. Even opening a file with Notepad fails in an admin prompt, but running Notepad from a normal user CMD window does work. How can that be? (see pic, where e:\ is the VBox shared folder) The pic doesn't show the failure, but does show I tried the same thing both ways.

A GA shared folder is intended to provide a simple gateway to get files in an out of the VM. It is not a network mapped drive or UNC path. If you want the features of a full network share then go ahead and create one.

And please search for previous answers before posting: this exact discussion already happened just a few days ago.

Hi, mpack. I guess you are referring to viewtopic.php?f=2&t=92911. Thanks; sorry. Sometimes the VMs aren't allowed to have net access, and copying in large installations is time consuming and eats needed space. (And, yes, the installer does normally work in a real network, so I know it is not the installer.)

The GA share looks and smells like a mapped net drive (look at the Windows Properties for the drive letter), and I can access it via UNC (\\vboxsrv). Your answer seems to be simplistic compared to the user experience. It is reasonable to think a Windows user would expect it to work like any other UNC path or net drive. I'll have to accept that these shares have limitations, since there seems to be no way to make it work (as is implied).

Sure I can work around this, but if I could get it to work it would be very helpful since I have to do this routine a lot. (Maybe use a host-only net share?)

And I'd still like to know why an admin cmd window doesn't work, but a user window does work, for simply opening a text file. Now I see it is more basic. In an admin window I can't even change to the share drive letter, e.g., e: ('The system cannot find the drive specified.'), but I can change to the share drive letter in a user window. (This is so anti-intuitive, having less access with admin rights.) Anyone know a way to make this work for an admin window?

JustinH wrote:The GA share looks and smells like a mapped net drive

... but it's not in reality. It's using a different namespace altogether. You want to prove it to yourself? Disable all the network cards in your VM. You're still going to be seeing the VirtualBox Shared Folders. Because they don't depend on the network, it's a different principal.

VirtualBox's Shared Folders present a very simplified file system implementation, just enough to read/write files from/to the guest. Many applications can error when using Shared Folders, because they expect advanced features, for example file locking, access controls, etc., which don't exist as a concept for Shared Folders.

As to not being able to run an executable from a shared folder, you got to thank Microsoft about this. Here's a part of my HowTo on WSUSoffline, the Windows Update service:

Note 1: If you run "UpdateInstaller.exe" from a VirtualBox share that is not mapped (does not a drive letter assigned), you get the following error:

• Unable to assign a drive letter
  to the script path \\VBoxSvr\WSUS\client

Note 2: If you run "UpdateInstaller.exe" from a VirtualBox share that is mapped (has a drive letter assigned), you get the following error:

• W:\Client\UpdateInstaller.exe
  The specified path does not exist.
  Check the path and then try again.

Solution 1: Disable UAC control temporarily. Then run "UpdateInstaller.exe" from a mapped share. You can turn off the network if you don't feel protected enough.
Solution 2: Copy the whole "WSUS\Client" sub-directory in the VM. It's several GB.

Explanation
When a user connects to a network share, Windows tries to connect with two sets of credentials. This fails due to the UAC control. It is so by design. For references and further reading on previous reports and the reasoning behind it (read especially the Microsoft links):

• https://www.google.com/search?q=the+spe ... ualbox.org
• viewtopic.php?f=7&t=48570
• viewtopic.php?f=7&t=40036
• https://www.virtualbox.org/ticket/5732
• https://support.microsoft.com/en-us/kb/303308 <--
• https://support.microsoft.com/en-us/kb/2019185 <--

Thank you, socratis. Good info.