Shared folders with long path are not mounted properly

[Zycon]

Hi,

on Windows 7 host and linux quest (ubuntu 14.04) shared folders with long path such as \\?\C:\MyStuff are not mounted properly.

Mount executes properly and is listed in /etc/mtab but when doing something in mounted directory it returns error such as ls: cannot open directory .: Operation not permitted

[Max D]

Issue is still present in 5.0.8 but is not present in 4.x

There is also an issue on the vagrant project on GitHub where this issue is discussed, see ​https://github.com/mitchellh/vagrant/issues/6409

[sunlover]

Should be fixed in latest Windows build (r103713) from https://www.virtualbox.org/wiki/Testbuilds Please test.

[Max D]

Feedback from vagrant people:

Test build for version 5 - r103713 seems to be working as intended. Even df -h returns the correct output. Trying 4.3.33-103670 testbuild too.

4.3.33-103670 still has problems with returning the sizes for df -h command, otherwise fine as usual.

Perhaps a separate issue for 4.3 needs to be opened too? Considering it works now in 5.0, it should be solvable on 4.3 too.

[sunlover]

Thanks for feedback.

Could you provide output of 'df -h' and 'mount' from VBox 4.3, where 'df' does not work? Thanks.

[jfbibeau]

Output from 4.3.33 r103670:

[vagrant@latest ~]$ df -h
'df: `/workspace': Not a directory'
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
                       38G  3.1G   33G   9% /
tmpfs                 1.5G     0  1.5G   0% /dev/shm
/dev/sda1             477M   30M  422M   7% /boot

[vagrant@latest ~]$ mount
/dev/mapper/VolGroup-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
workspace on /workspace type vboxsf (uid=500,gid=500,rw)

[sunlover]

I probably doing something wrong but I could not reproduce this.

Installed VirtualBox 4.3.33r103670, Vagrant 1.7.4 on a Windows host, then did vagrant init hashicorp/precise32; vagrant up. Updated guest additions in the VM.

Here what I get:

vagrant@precise32:~$ VBoxControl -V
4.3.33r103492

vagrant@precise32:~$ df -h
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/precise32-root   79G  2.4G   73G   4% /
udev                        178M  4.0K  178M   1% /dev
tmpfs                        74M  284K   74M   1% /run
none                        5.0M     0  5.0M   0% /run/lock
none                        185M     0  185M   0% /run/shm
/dev/sda1                   228M   24M  192M  12% /boot
vagrant                     206G  103G  103G  50% /vagrant

vagrant@precise32:~$ mount
/dev/mapper/precise32-root on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda1 on /boot type ext2 (rw)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw)
vagrant on /vagrant type vboxsf (uid=1000,gid=1000,rw)
vagrant@precise32:~$

Please provide a step by step reproduction scenario.

[Max D]

From Vagrant people:

instructions how to patch Vagrant VirtualBox driver to use UNC paths.

That is, simply add

if Vagrant::Util::Platform.windows?
   hostpath = Vagrant::Util::Platform.windows_unc_path(hostpath)
end

after plugins/providers/virtualbox/driver/version_4_3.rb:499, where's

hostpath = folder[:hostpath]

It might help you shed a light on the real problem

[jfbibeau]

That's correct. The steps above will reproduce the issue in Vagrant. It's essentially converting the share path to UNC format. The purpose of which is to allow longer paths than Windows traditionally allows (this is needed for example when installing npm packages which can be several directories deep).

[jfbibeau]

Oh forgot to mention, alternatively if you don't feel like messing around in the vagrant source files, you could also install Vagrant 1.7.3, which has that feature in it, you'll see the bug. It was rolled back in vagrant 1.7.4 due to the VirtualBox issues.

[sunlover]

Thanks for the info. The long path should work with 4.3 r103933 see https://www.virtualbox.org/wiki/Testbuilds

Please test.

[Max D]

Vagrant dev reports that it's working on his machine now. Will update here if others report breakage but looking good so far. Thank you sunflower for the very fast fixing & follow up!

[Frank Mehnert]

Fixed in VBox 5.0.10.

[estani]

Regression in Version 5.1.16 r113841 (Qt5.6.2) @ Windows 7 [Version 6.1.7601]

The GUI does not even accept the prefix (i.e. "\\?\C:\test\") as a valid path. It worked before (don't recall the previous used version, if it's logged somewhere I'll be able to retrieve it if required) and broke after updating.

[Ced-le-pingouin]

Same problem here. \\?\-prefixed host paths as shared folders don't work anymore since I upgraded to VirtualBox 5.1.16.

My host OS is Windows 10(.0.14393 ; it's the 1607 update). The main guest OS I use is a Debian Jessie. When trying to mount the \\?\-prefixed shared folder inside the guest (with mount -t vboxsf ...), I get a "No such file or directory" error.

If I remove the extended-length prefix (as Microsoft calls it), the shared folder works fine (so I use C:\Users\Me instead of \\?\C:\Users\Me).

The extended-length path worked fine in VirtualBox 5.1.14. So I had to downgrade VB to keep that feature working.

Like estani said, the GUI doesn't accept such host paths for a shared folder anymore, as the OK button in the shared folder configuration panel is disabled when a path begins with \\?\.

BUT the CLI tool, VBoxManage, still accepts the creation of shared folders with extended paths. Vagrant uses VBoxManage to configure paths like that on VMs, but is then unable to mount these shared folders in the guest OS.

[Frank Mehnert]

comment:13 and comment:14 are indeed 5.1.16 regressions.

[Socratis]

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

Update: I was told that as of 2017-03-14 16:23 UTC, the testbuilds were not containing the UNC fix, but they might soon. Comment changed to reflect reality. Sorry about that...

[Frank Mehnert]

In the meantime the test builds were updated. So I want like to ask you again to test the latest 5.1.x test builds (>= 113974) regarding this shared folders regression.

[Socratis]

Update 2: Of course frank was just waiting for me to do the update/edit, to simply "correct" the situation 10 minutes later!!! Man... Frank are you doing this on purpose? :) :D

(of course that was a joke and I don't expect an answer...)

[Frank Mehnert]

:-D

[johnstradamus]

Confirmed fixed in build 113984

[Ced-le-pingouin]

Works for me too in build 5.1.17-113974.

But only if the shared folder is created with VBoxManage.

Defining a \\?\-prefixed host path for a shared folder, in the GUI, is still not allowed (the OK button is disabled).

I don't know if it worked in previous versions of VirtualBox either, since I only created shared folders with extended-length host paths with VBoxManage.

So, for my use cases, build 113974 fixes the problem.

EDIT: Same results with build 113984.

[Frank Mehnert]

Fixed in VBox 5.1.18.