virtualbox.org

Hi,

My main use of VirtualBox is to run several Linux boxes on a Windows 10 Enterprise host.

Before upgrading to VirtualBox 5.1.16, I was using version 5.1.14, without any problem.
On the guest box I use the most, a Debian Jessie, the version of Guest Additions installed was "old" (as in 4.x).

So, when I upgraded to 5.1.16, and my Debian guest refused to mount shared folders with the message "No such file or directory", I thought it was time to upgrade the guest additions.
I upgraded them to 5.1.16 as well, but the Linux guest still refused to mount the shared folders.

Then I noticed something odd (to me): I'm also using Vagrant to manage various VMs, and it usually automatically creates a shared folder named "vagrant" on VirtualBox VMs, *and* when it's running on a Windows host, it always turns host paths for the shared folders into UNC paths. So if it needs to share "C:\Users\Me", it creates a VB shared folder with path "\\?\C:\Users\Me".

I never noticed that. But it always worked before (Windows UNC paths are pretty standard).

So I discovered that in VB 5.1.16, this specific aspect wasn't working anymore. It is as if these UNC host paths did not exist for VirtualBox (or maybe its Linux Guest Additions ?). If I manually remove the "\\?\" prefix from the shared folder's host path, it's working again, and the Linux guest can mount it without error.

I tried to add/remove the "\\?\" prefix on other VMs, not necessarily created by Vagrant, and it confirmed that what VB 5.1.16 dit not like was the UNC paths.

When I switched back to VB 5.1.14, the shared folders with the "\\?\" prefix, as created by Vagrant, worked as before.

Is this expected behavior in VB 5.1.16 ? Am I missing something ? Should I file a bug report ?

Vagrant is a program that relies on VirtualBox but modifies its configuration files in unknown ways to us. It is not supported on these VirtualBox user forums, they have their own vagrant support channels.

If you are having this problem with a standalone version of VirtualBox, then we can continue this discussion.

For example, UNC shared folders were never supported in VirtualBox, and I'm not sure what's going on (but I'm not going to investigate it either):

Chapter 4.3. Shared folders wrote:Shared folders must physically reside on the host and are then shared with the guest, which uses a special file system driver in the Guest Addition to talk to the host.

Thank you for your answer.

I was only mentioning Vagrant to provide context as to how I (re-)discovered Windows UNC (? - see below) paths.

But I spent a good part of yesterday trying to pinpoint exactly where the problem was after my upgrade to VirtualBox 5.1.16.
It seems to be a change in how VirtualBox treats paths beginning with "\\?\" when they are entered as host paths for shared folders. Unless I'm missing something, of course.

Actually, I've been a bit loose in calling these paths "UNC", as it seems Microsoft names them "extended-length paths", which allow to use paths longer than the "old" 260-characters-max Windows paths (and some stuff related to Unicode and newer Windows API functions). They explain this in an article on MSDN, that you can find as first result when googling "msdn maximum path length limitation" (sorry for this weird way of doing things, but this forum says I'm not yet allowed to post URLs).

So, these "\\?\"-prefixed paths do not necessarily reside on the network. In my example, the paths "\\?\C:\Users\Me" and "C:\Users\Me" both point to the same location on the host filesystem, and both are valid Windows paths.

It may very well be the case that VirtualBox is not supposed to support extended-length Windows paths, that it did support them in previous versions by "accident", and that version 5.1.16 changed that. I don't know. But if it is not a desired behavior, I might as well file a bug report. That is why I asked. (and I will stay with version 5.1.14 in the meantime, as my use case needs such paths)

I just encountered the same (or a related) problem. I upgraded to 5.1.16 and Vagrant went topsy-turvy.

VirtualBox blames Vagrant, but Vagrant blames VirtualBox.

The most succinct thread on the Vagrant side seems to be https://github.com/mitchellh/vagrant/issues/8352 , but it is marked "upstream" and points here...

FATAL ERROR: circular reference

To quote chrisroberts from that thread:

There is a claim in that thread that VirtualBox does not support UNC paths for shared folders, but it seems that the claim is conflating remote share paths with local long paths.

Is this a factual analysis?

The OP was trying to link to the following article; I can't link to it either, because this forum software butchers the URL (due to the parenthetical notation, near the end):
Others are reporting that the same thing happened two years ago: https://github.com/mitchellh/vagrant/issues/5933

Given that upgrading VirtualBox fixed the issue, it seems plausible that the problem is actually with VirtualBox, not with Vagrant.

Finally, for whatever it's worth, unlike the OP, removing the \\?\ from the "Shared Folder" definitions does not fix the problem in my case; doing so simply changes the mount error message from

# mount -t vboxsf -o uid=1000,gid=1000 vagrant /vagrant
": No such file or directory

to

Protocol error

I don't know if either of you has the nickname "estani" in the bugtracker, but there was recently an update to an old ticket: 14651: Shared folders with long path are not mounted properly. The original ticket was opened with 5.0.4 (2015-10-01), but it was closed with 5.0.10 (2015-11-10).

Apparently it is a regression with 5.1.16, since you were both had working results with 5.1.14 (and "estani"). Please read the ticket as it may contain workarounds. Also, post a "me too" with your configuration so that you'll get a notification when things change.

Finally, just to make sure, I'll post a link to this discussion in the "Discuss the 5.1.16 release".

Thank you for your answer, socratis.

I'll post a message on the reopened ticket, too.

This is an important issue, and I think many people will experience that bug in the coming days.

Same problem, shared folders stop working , vbox 5.1.16 and vagrant 1.9.2 .
And this is a fress install including windows 10.

The 5.1.17 test build from https://www.virtualbox.org/wiki/Testbuilds should contain a fix. Can you give it a try and verify that it's working?

Sorry, the UNC path problem is not yet fixed in the test builds. I will come back as soon as such a build is available.

Oops, my bad! I thought it was. Thanks for the clarification...

Now it is (5.1.x >= 113974). Feedback welcome!

Confirmed as fixed in build 113984

Thank you for the quick fix.

I downloaded and installed test build 5.1.17-113974.

Tested with Docker Toolbox, since it also uses VBoxManage to create a VM with "\\?\C:\Users" as a shared folder (auto-mounted in the VM under "/c/Users").
It didn't work in 5.1.16, but it works in 5.1.17 (test). I can access the shared folder in the VM.

BUT it is still impossible to enter a "\\?\"-prefixed host path for a shared folder in the GUI. The OK button is disabled (I guess it thinks the path does not exist, or is a network share).

So it only works with VBoxManage.

I must admit I never used the GUI before to create shared folders with extended-length host paths, so I don't even know if it worked in previous versions of VirtualBox.
In my use cases, these paths were always created with VBoxManage in CLI scripts, or by Vagrant, Docker Toolbox, and other tools that also use VBoxManage and the CLI.

EDIT: Same results with build 113984.

Ced-le-pingouin wrote:so I don't even know if it worked in previous versions of VirtualBox.

That should take you no more than 5 minutes to test...

Well, as I said in my message, it is not part of my usual workflow, so it seems only normal that I wouldn't know whether that specific part worked in older versions.

Moreover, testing whether this GUI stuff worked in older versions of VirtualBox means I have to re-install an old version of VirtualBox.
With other kinds of software, I'm all for testing stuff over and over, with different versions, since it's easy and quick to do... in VMs or containers. But I can't really test older versions of VB that way.
I have to do it on my workstation, in my real OS, where my real projects are using VB, so I can't uninstall/re-install/cleanup/reboot all the time.
And I'm not a VB official tester, I also have work to do

But, since I'm such a nice guy, I re-installed VB 5.1.14, in which the extended-length host paths were working. With VBoxManage, at least.
And entering a "\\?\"-prefixed host path in the GUI for shared folders creation... didn't work either. So I guess the 5.1.17-xxxx test builds are fixed, and the situation is back to pre-5.1.16.

(except if that GUI stuff did work in pre-5.1.14, 5.0.x, 4.3, ... but I won't go back and test all these older versions - I'm not *that* nice )