virtualbox.org

Hi,

Linux Host O/S is Ubuntu 16.04 LTS.
Windows Guest is Windows 10 Pro 64-bit.

I installed the latest VirtualBox Version 5.1.18 r114002 (Qt5.5.1) today, including Guest Additions.

I have been using VirtualBox for more than 5 years, with many combinations of host and guest operating systems. However this combination is new for me, where I am trying to get one of my primary Windows drives to equal a SharedFolder (rather than a .vmdk or .vdi file), and to use that drive to hold files for custom Windows services and generally to be available for all users including as-Administrator.

As far as I can see, a major problem exists in Guest Additions, in that the local drive mapping letter for SharedFolders are NOT available as-admin nor to system services.

Example.

Drive D: is \\vboxsrv\D (happens to be zfs on Ubuntu)
Drive E: is \\vboxsrv\E (happens to be ext4 on Ubuntu)

These drive letters show up in Windows File explorer. They show up under "Network Locations" not as "Devices and Drives" on Windows 10.

If a CMD prompt is opened as a regular user, these commands all work as expected: However if a CMD prompt is opened as-administrator (run as administrator of a shortcut to CMD) then it is not possible to do anything with drive D: or E:.

Furthermore services installed on D: do not start.

This is a disaster. This is fatal. This makes a VirtualBox guest operating system unusable for production.

I tried the suggestion from https://www.virtualbox.org/manual/ch12.html#idm10217 of putting in entries for LMHOSTS and that did not help. What am I missing? Are local drive letters working for starting services for anyone with Linux Host and Windows Guest with the latest 5.1.x release, or did they ever work? Now I am wondering whether I ever had to test this exact feature in the past. Perhaps never. So, if this is an as-designed limitation of Guest Additions, I would really appreciate a comment.

THANK YOU.

The workaround in ticket 5732 ( https://www.virtualbox.org/ticket/5732 ) makes the mapped drive letter available to Administrator and services.

See especially:
https://www.virtualbox.org/attachment/t ... sXarxa.png

AnnVirtual wrote:This is a disaster. This is fatal. This makes a VirtualBox guest operating system unusable for production.

Not really. Just because of a misunderstanding on how things work, I wouldn't go as far as calling it a disaster. Those are kind of extreme words, don't you think? Plus I would add "for my specific use scenario" at the end there. Bold and underlined...

AnnVirtual wrote:The workaround in ticket 5732

That's not a workaround, that's how things work in the Windows world. I have a small passage which is almost ideal for the occasion:

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.gr/search?q=the+spec ... 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

Okay. Perhaps "shockingly inconvenient" is better wording than "fatal disaster." Definitely, I am talking "for my use case" of web site development and admittedly many other use cases do work fine. VirtualBox is incredibly useful, otherwise I would not have spent so many hours over so many years with it already.

To clarify, by design, in a Windows guest, any Windows service that needs to reference files on a vboxsrv shared folder, must use unc to name the files, and cannot use the local drive letter which "appears" in Windows File Manager for the regular user. Correct?

i.e. \\vboxsrv\.... etc

The "By Design" could be expanded to "By Microsoft Design" and is a security level which applies to all currently supported Microsoft Windows OSs - see https://support.microsoft.com/en-gb/hel ... ped-drives

AnnVirtual wrote:To clarify, by design, in a Windows guest, any Windows service that needs to reference files on a vboxsrv shared folder, must use unc to name the files, and cannot use the local drive letter which "appears" in Windows File Manager for the regular user. Correct?
i.e. \\vboxsrv\.... etc

You'd think... But this is Windows we're talking about. There are some executables where if you try to run "\\VBoxSrv\Share\MyApp.exe" from a Windows share that is not mapped (doesn't have a drive letter assigned), you'll get a nice dialog with an error:

• The script was started from a UNC path.
  Please map a drive letter to the network share.

Just for reference, one such executable is the infamous "UpdateGenerator" from WSUSOffline. The only solution is to use a mapped drive, the exact opposite of what you'd expect. Oh, the intricacies of sharing...

ευχαριστώ

Ok, so "mileage may vary" depending on which EXE is run as-service, and exactly what its abilities and requirements are. Fair enough.

Re IIS:
I experimented with the idea posted here, http://blog.practicaltech.ca/2016/01/vi ... s-and.html, of making a symlink and then sharing that and then using \\localhost\code ( where 'code' is the code name of the shared symlink folder as described in that post ) as the path that IIS works with. That worked well for the IIS site root, for serving static files. I did not get \\localhost\code to work as the path to an allowed custom isapi extension. IIS reported Status 500 (500.19) relentlessly. I gave up and just put the extension in C:\ directly within the .vdi drive.
One note: when using that symlink solution, IIS reported 403.1 for *missing* files instead of reporting status 404. Example: http://localhost/robots.txt came back 403.1 until the file robots.txt existed. Strange, 100% repeatable. (This was IIS on Win 10 Pro, for the record.)
I can live with all that.

Re custom programs using "global" shared memory

Do you happen to know whether installing the service from \\vboxsrv\share... has any impact on that service's ability to read or write to a global shared memory area?

Re simple drive letters like D:
Is there any way to "map a drive" for services to the SAME letter that File Explorer shows to end-users? I know about putting drive letters into the DOS Devices section of the Windows registry, for regular mappings. Could I force the vboxsrv shared folder to [auto] mount as M and then map a lower letter D: to M: for all circumstances??? Or do you use NET USE in a certain way so that it works out to the same letter for all circumstances/users ? I have tried a few variations on these ideas but have not yet found something that feels and works right.

*

Completely aside, in the middle of this, Murphy's Law kicked in and convinced VirtualBox that my Windows-guest machine should be displayed in a tiny, usuable one inch square area of my 4k monitor. I tried to log in to the miniature Windows guest, but the username and password prompt area were outside of that inch that VirtualBox was willing to display.

Eventually I found this very accurate diagnosis about the so-called guest size-hint by using right-click > Show Log from my virtual machine (i.e. within Virtual Box Manager itself):
In my case, 426x268 worked out to roughly a 1 inch square.

A related symptom was that the menu choice for View > Auto-resize Guest Display was greyed out. Toggling scaling, full-screen, stretching the size -- all made no difference.

Eventually I found https://blog.jamesbayley.com/2016/02/10 ... box-guest/ I toggled the Preferences as advised, and was able to log in to Windows by typing the username [tab] password [enter] (without ever seeing the prompts) and then was able to get to right-click into the Display Properties of the Windows desktop to increase it to a more reasonable size. I did set the vram to 256 which seemed logical but did not solve anything by itself.

*

There are many reports of problems running websites from shared folders.
The shared folders are just not designed for application usage, they are just there for a simple way to transfer files to and from guests.
Many advanced features of a normal filesystem like file locking and access controls are not there .

^^^^^
What Martin said.
Why don't you save yourself a lot of headaches, hacks and workarounds by using SMB shares instead of VirtualBox shared folders?

Thank you very much for the comments. I had had so much success using Shared Folders for file transfer in the past that I did not imagine there would be limitations in terms of Windows services and as-admin usage.

I will definitely change my plan for sharing the Ubuntu host file storage.

Muchos, muchos gracias for resetting my mind map.

What worked for me to install software that needs both correct drive letter and admin rights:
- disconnect the drive letter
- open an admin command shell and mount the drive manually:
net use x: \\vboxsrv\whatever
- run setup of the software from the same command prompt
- disconnect drive from the same command prompt:
net use /d x:
- leave shell and reconnect the drive letter for normal user

Let's say the software you installed ran as a service. Wouldn't the service remember X: and be unable to function once that had been disconnected? I guess it would depend on the application but I think most would only save the drive letter, not the network location.

Did you happen to try mapping the drive to the SAME drive letter, twice, using CMD regular and then CMD as-admin?

I had a few different jobs I was trying to use shared folders for. One job was to hold JPG files for use on a virtual path within Microsoft IIS, say http://localhost/images/file.jpg where /images/ was on the Ubuntu host, shared in to the Windows 10 guest. In that situation, IIS needs to be able to "see" the source location.

Just for reference of who, like me, comes to this old thread in hope of an answer, I add my solution.

Note however that there are so many factors influencing the behaviour of Windows' security features, that you can not expect this to work for everyone.

My situation is a straightforward install (i.e. no options that I am aware of) of a plain Windows 7 SP1 Professional in a virtual machine of VirtualBox 5.18, running on an Ubuntu 18.04 host. The VM has a single user, me, that also has administration rights. User Account Control (UAC) settings are not tampered with: I did try the different suggestions in this thread regarding UAC, but without success, so I restored the 'as installed' snapshot.

I noted that in a cmd prompt ran 'as administrator', i.e. with elevated rights, the output of the command net use is exactly the same as in a normal cmd prompt, even though the elevated prompt cannot access the shared folders under their assigned drive letter. In both prompts the output is (in Dutch) : With this knowledge you can format the output of net use in an elevated prompt to mount the shared folders under the same drive letters for my user with elevated rights. And it requires no messing up the default UAC settings.

In a batch file (to be executed with administrative rights) that would be : I added a task to the Task Scheduler, that runs this batch file 30 seconds after logon, 'with highest privileges', which turn out to be elevated rights for my user with administration rights.

When executed directly on a command line of an elevated command prompt it becomes : The option /persistent:no is very important: when mounting the shared folders persistently, on a next boot Windows mounts them again on the same drive letters, before the Guest Additions act. The Guest Additions would then detect that these drive letters are in use, and mount the shared folders for the non-elevated user to the next available drive letters.

After executing the above commands, the elevated prompt has access to the shared folders under the same drive letter as a non-elevated prompt.

Accessing them from an Explorer window is a different matter. When you try to run, for instance, an installer that is in a shared folder via it's drive letter, by right clicking on it in Explorer and choosing "run as administrator", you still get the message that the path is not found. For this you need to run Explorer as administrator as well, which is not straightforward.

In a plain Windows installation, all Explorer windows are spawned by the primary Explorer instance that holds the Desktop. Even when you try to start explorer.exe as administrator, that request is passed on to the Desktop instance of Explorer, and ran as not-an-administrator.

Though it works, I do not particularly like this solution, executed from an elevated command prompt, that kills all Explorer instances, even the Desktop one, and starts Explorer anew with elevated rights: In most cases I prefer the Explorer look-alike that you can start by entering C:\ or whatever local path in the adress bar of an Internet Explorer instance that you run as administrator. You can run Internet Explorer as administrator by right clicking on a link to it in your start menu, not on e.g. the Internet Explorer icon that miraculously appears on your desktop, without being a .lnk file in your %userprofile%\Desktop folder.