VirtualBox

Opened 8 years ago

Closed 7 years ago

#14651 closed defect (fixed)

Shared folders with long path are not mounted properly

Reported by: Zycon Owned by:
Component: shared folders Version: VirtualBox 5.0.4
Keywords: Cc:
Guest type: Linux Host type: Windows

Description

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

Attachments (1)

VBox.log (89.6 KB ) - added by Zycon 8 years ago.

Download all attachments as: .zip

Change History (23)

by Zycon, 8 years ago

Attachment: VBox.log added

comment:1 by Max D, 8 years ago

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

Last edited 8 years ago by Max D (previous) (diff)

comment:2 by sunlover, 8 years ago

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

comment:3 by Max D, 8 years ago

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.

comment:4 by sunlover, 8 years ago

Thanks for feedback.

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

comment:5 by jfbibeau, 8 years ago

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)

comment:6 by sunlover, 8 years ago

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.

comment:7 by Max D, 8 years ago

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

Last edited 8 years ago by Max D (previous) (diff)

comment:8 by jfbibeau, 8 years ago

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).

comment:9 by jfbibeau, 8 years ago

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.

comment:10 by sunlover, 8 years ago

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

Please test.

comment:11 by Max D, 8 years ago

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!

comment:12 by Frank Mehnert, 8 years ago

Resolution: fixed
Status: newclosed

Fixed in VBox 5.0.10.

comment:13 by estani, 7 years ago

Resolution: fixed
Status: closedreopened

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.

Last edited 7 years ago by estani (previous) (diff)

comment:14 by Ced-le-pingouin, 7 years ago

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.

Last edited 7 years ago by Ced-le-pingouin (previous) (diff)

comment:15 by Frank Mehnert, 7 years ago

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

comment:16 by Socratis, 7 years ago

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...

Last edited 7 years ago by Socratis (previous) (diff)

comment:17 by Frank Mehnert, 7 years ago

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.

comment:18 by Socratis, 7 years ago

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...)

comment:19 by Frank Mehnert, 7 years ago

:-D

comment:20 by johnstradamus, 7 years ago

Confirmed fixed in build 113984

Last edited 7 years ago by johnstradamus (previous) (diff)

comment:21 by Ced-le-pingouin, 7 years ago

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.

Last edited 7 years ago by Ced-le-pingouin (previous) (diff)

comment:22 by Frank Mehnert, 7 years ago

Resolution: fixed
Status: reopenedclosed

Fixed in VBox 5.1.18.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use