WSL rootfs on newer OS builds is no longer "%LOCALAPPDATA%\lxss"

[BR0kEN-]

Vagrant version

Vagrant 2.0.2

Host operating system

Windows 10 (version 1709, build 16299.125).

Expected behavior

Vagrant is to detect current WSL container and compute a proper path to it.

Actual behavior

Vagrant handles only the WSL that is installed via lxrun.

References

• Location of WSL rootfs filesystem for post - Fall Creator's Update installations microsoft/WSL#2578
• Plugin is broken in WSL after Windows 10 Fall Creators Update berkshelf/vagrant-berkshelf#323
• https://github.com/BR0kEN-/cikit/tree/issues/52/docs/vagrant/wsl
• Error when installing Arch Linux rootfs on Windows 10 Fall Creators Update RoliSoft/WSL-Distribution-Switcher#69

Additional information

Before the 16215 build of Windows, there was a way to install a WSL using lxrun. After mentioned build this way has been deprecated and, since then, it's recommended to use Microsoft Store for installing a WSL. Moreover, since that version, you can have multiple instances of Linux subsystem.

When the installation is done by lxrun /install then rootfs of a WSL will be in %LOCALAPPDATA%\lxss and Vagrant will operate correctly since its codebase relies on this location (https://github.com/hashicorp/vagrant/blob/v2.0.1/lib/vagrant/util/platform.rb#L286-L289).

When the installation is done from the Microsoft Store, then rootfs of a WSL will be in %LOCALAPPDATA%\Packages\<WSL_ID>\LocalState. Pay your attention at the <WSL_ID> token in the path which is completely dynamic.

The path of the particular container can be obtained from the registry at HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss - a listing of installed subsystems.

For instance, using the following PowerShell script, the path of default subsystem can be gained.

$WSLREGKEY="HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss"
$WSLDEFID=(Get-ItemProperty "$WSLREGKEY").DefaultDistribution
$WSLFSPATH=(Get-ItemProperty "$WSLREGKEY\$WSLDEFID").BasePath
New-Item -ItemType Junction -Path "$env:LOCALAPPDATA\lxss" -Value "$WSLFSPATH\rootfs"

[BR0kEN-]

@chrisroberts, I made a PR based on microsoft/WSL#2578 (comment) and would appreciate if you could take a look (since you were the initial author of WSL integration).

[AsharLohmar]

Thanks for the patch it (kind of) worked.

I'm on:

• Microsoft Windows [Version 10.0.16299.192]
• Ubuntu installed from store
• Vagrant 2.0.1 (installed only the "*.deb" file on/in Ubuntu)

In the "/opt/vagrant/embedded/gems/gems/vagrant-2.0.1/lib/vagrant/util/powershell.rb" I had to change all the "powershell" references in "powershell.exe", otherwise vagrant would've complain that there was no powershell in the PATH.

[BR0kEN-]

@AsharLohmar, you can just create a symlink. Example: https://github.com/BR0kEN-/cikit/blob/6f1b572e3f3a779a7a776e919c39e2a6cca77643/docs/_documentation/install-on-wsl/wsl-provision.sh#L14-L27

[AsharLohmar]

That's a good advice . Thanks

[atorstling]

Can I build this release for testing somehow without tainting my local WSL env? How do you build a deb from source? Thanks

[BR0kEN-]

@atorstling, download deb from https://releases.hashicorp.com/vagrant/2.0.1/vagrant_2.0.1_x86_64.deb and patch it with https://raw.githubusercontent.com/BR0kEN-/cikit/master/docs/_documentation/install-on-wsl/patches/vagrant-2.0.1-issue-9298.patch.

cd ~
wget -q https://releases.hashicorp.com/vagrant/2.0.1/vagrant_2.0.1_x86_64.deb
sudo dpkg -i vagrant_2.0.1_x86_64.deb
rm vagrant_2.0.1_x86_64.deb
cd /opt/vagrant/embedded/gems/gems/vagrant-2.0.1
sudo wget -q https://raw.githubusercontent.com/BR0kEN-/cikit/master/docs/_documentation/install-on-wsl/patches/vagrant-2.0.1-issue-9298.patch
sudo patch -p1 < vagrant-2.0.1-issue-9298.patch

https://github.com/BR0kEN-/cikit/blob/6f1b572e3f3a779a7a776e919c39e2a6cca77643/docs/_documentation/install-on-wsl/wsl-provision.sh#L133-L161

[atorstling]

@BR0kEN- Ok, I patched 2.0.2 and symlinked powershell, but I get the Vagrant is unable to determine WSL instance you are currently in because Windows registry has no information about it at "HKCU:\Software\Microsoft\Windows\Current Version\Lxss" error. I do have a reg structure for the LSW, see attachment. I also ran vagrant with debug and got the following:

DEBUG wsl: Checking whether the "/mnt/c/Users/Alexander/rootfs" is a root VolFS mount of current WSL instance.
 WARN wsl: Windows registry has an information about WSL instance with the "/mnt/c/Users/Alexander/rootfs" base path that is no longer exist or broken.
DEBUG wsl: Checking whether the "/mnt/trstling/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs" is a root VolFS mount of current WSL instance.
 WARN wsl: Windows registry has an information about WSL instance with the "/mnt/trstling/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs" base path that is no longer exist or broken.
ERROR warden: Error occurred: Vagrant is unable to determine WSL instance you are currently in because Windows
registry has no information about it at "HKCU:\Software\Microsoft\Windows\Current
Version\Lxss".

The "/mnt/trstling" path looks iffy. I don't think it exists. Actually, looking closer into it the issue seems to be that you do split(" "), and my username has spaces in it.

lxss.reg.txt

[BR0kEN-]

Yeah, @atorstling, well noticed! I'll do an update on this today.

[atorstling]

@BR0kEN- Great, thanks!

[BR0kEN-]

@atorstling, my tests says the split("\r\n") instead of split(" ") solves the issue. Could you please try?

[atorstling]

@BR0kEN- yes, that got me further. But now I get

There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["sharedfolder", "add", "4a588575-27d1-4a38-ac72-c87756bbef4b", "--name", "vagrant", "--hostpath", "\\\\?\\\\mnt\\c\\Users\\Alexander Torstling\\AppData\\Local\\Packages\\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\\LocalState\\rootfs\\home\\alext\\projects\\<redacted>\\<redacted>\\local"]

Stderr: VBoxManage.exe: error: Shared folder path '\\?\\mnt\c\Users\Alexander Torstling\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\alext\projects\<redacted>\<redacted>\local' is not absolute
VBoxManage.exe: error: Details: code E_INVALIDARG (0x80070057), component SharedFolderWrap, interface ISharedFolder, callee IUnknown
VBoxManage.exe: error: Context: "CreateSharedFolder(Bstr(name).raw(), Bstr(hostpath).raw(), fWritable, fAutoMount)" at line 1031 of file VBoxManageMisc.cpp

[BR0kEN-]

@atorstling, well, now it's a matter of the environment configuration you have.

• Do you have VirtualBox installed on Windows, not inside of WSL?
• What is the version of VirtualBox are you using?
• What is the build number of Windows?

[AsharLohmar]

Ensure VirtualBox's folder is in the PATH
export PATH="${PATH}:/mnt/c/Program Files/Oracle/VirtualBox"

Side note: I don't think that VirtualBox can or should be ran from inside WSL

[BR0kEN-]

@AsharLohmar, @atorstling has the VBoxManage.exe executable and PATH modification isn't necessary. It's wrong advice, but you're 100% correct, saying that VirtualBox cannot operate properly when installed inside WSL.

[BR0kEN-]

@AsharLohmar, it calls interoperability. See https://docs.microsoft.com/en-us/windows/wsl/interop.

You may symlink any *.exe within WSL container and use it, i.e.

sudo ln -fs "/mnt/c/Program Files/Oracle/VirtualBox/VBoxManage.exe" /usr/bin/VBoxManage
VBoxManage --version

[atorstling]

@BR0kEN-

1. Yes, it's installed in Windows, and removed from WSL. I had it installed previously but removed all packages - apt remove virtualbox*. Do I need to reboot WSL somehow maybe?
2. The version is 2.0.2, so not 2.0.1 which you are primarily addressing. The patch applied cleanly, though.
3. Windows build version is Windows 10 Pro 16299.214

Could you give me a hint where the /mnt/ path should be translated to a win path? I could investigate then... I see the wsl_to_windows_path function you provided, but don't really see where it's called.

[BR0kEN-]

@atorstling

1. Should be enough without any restarts.
2. Yeah, the bug persists in Vagrant 2.0.2 but I've been asking for VirtualBox version (VBoxManage.exe --version).

The \\?\\mnt\c\Users\Alexander Torstling\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\alext\projects\<redacted>\<redacted>\local is a correct path (see Vagrant::Util::Platform.windows_unc_path) for mounting VirtualBox shares. I suspect the space in your username could be the reason. Do you have a spaceless account?

[atorstling]

@BR0kEN- Oh. Yes, virtualbox is at 5.2.6r120293. A question: how can the UNC path with mnt in it be valid from a VirtualBox perspective? I would expect it to only be valid from inside WSL. Unfortunately I don't have a spaceless account at hand, but I could set it up to test. I would prefer to diagnose this a bit further though, I suspect that spaceless would just work...

BTW, could you redact the UNC path a bit? I just redacted the ones I posted. Thanks.

[BR0kEN-]

@atorstling, take a look at the VagrantPlugins::ProviderVirtualBox::Driver::Version_5_0.share_folders method. There's an execution of the command that is failed for you.

Command: ["sharedfolder", "add", "4a588575-27d1-4a38-ac72-c87756bbef4b", "--name", "vagrant", "--hostpath", "\\\\?\\\\mnt\\c\\Users\\Alexander Torstling\\AppData\\Local\\Packages\\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\\LocalState\\rootfs\\home\\alext\\projects\\<redacted>\\<redacted>\\local"]

Stderr: VBoxManage.exe: error: Shared folder path '\\?\\mnt\c\Users\Alexander Torstling\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\alext\projects\<redacted>\<redacted>\local' is not absolute
VBoxManage.exe: error: Details: code E_INVALIDARG (0x80070057), component SharedFolderWrap, interface ISharedFolder, callee IUnknown
VBoxManage.exe: error: Context: "CreateSharedFolder(Bstr(name).raw(), Bstr(hostpath).raw(), fWritable, fAutoMount)" at line 1031 of file VBoxManageMisc.cpp

I'm asure that if hostpath (inside of the method I've pointed out) contains spaces it should be wrapped into quotes.

What you have:

VboxManage.exe sharedfolder add 4a588575-27d1-4a38-ac72-c87756bbef4b --name vagrant --hostpath \\\\?\\\\mnt\\c\\Users\\Alexander Torstling\\AppData\\Local\\Packages\\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\\LocalState\\rootfs\\home\\alext\\projects\\<redacted>\\<redacted>\\local

How it should look:

VboxManage.exe sharedfolder add 4a588575-27d1-4a38-ac72-c87756bbef4b --name vagrant --hostpath "\\\\?\\\\mnt\\c\\Users\\Alexander Torstling\\AppData\\Local\\Packages\\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\\LocalState\\rootfs\\home\\alext\\projects\\<redacted>\\<redacted>\\local"

[BR0kEN-]

@atorstling, try to replace the hostpath at https://github.com/hashicorp/vagrant/blob/master/plugins/providers/virtualbox/driver/version_5_0.rb#L673 by the '"' + hostpath + '"'.

[atorstling]

@BR0kEN- Thanks. I tried experimenting on the command line, and the problem seems to be that \\\\?\\\\ should be \\\\?\\ - there are extra backslashes after the question mark. After this edit, running the VBoxManage command directly works, even with the UNC path containing mnt. But I still don't understand how this is supposed to work, aren't you supposed to use a path valid from outside WSL?

And could you edit your posts to redact my company and project name in the folders please? Thank you.

[BR0kEN-]

@atorstling, they are extra in a case you're wrapping the path into quotes. I think the problem with paths, having spaces, is not related to this topic.

I'd be thankful if you could check, on an account with a spaceless username, whether the root issue can be fixed.

[BR0kEN-]

@atorstling, you also can escape space characters by the backslashes (instead of quotes). Should be correct either:

VboxManage.exe sharedfolder add 4a588575-27d1-4a38-ac72-c87756bbef4b --name vagrant --hostpath \\\\?\\\\mnt\\c\\Users\\Alexander\ Torstling\\AppData\\Local\\Packages\\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\\LocalState\\rootfs\\home\\alext\\projects\\<redacted>\\<redacted>\\local

My advice for wrapping into quotes was wrong, sorry. Seems instead of the '"' + hostpath + '"' there should be require "shellwords" and hostpath.shellescape.

[atorstling]

@BR0kEN- When I entered the command in the terminal, removing extra backslashes worked. I also tried again with hostpath.shellescape, and still I think there are extra backslashes, as you see here:

There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["sharedfolder", "add", "4a588575-27d1-4a38-ac72-c87756bbef4b", "--name", "vagrant", "--hostpath", "\\\\\\\\\\?\\\\\\\\mnt\\\\c\\\\Users\\\\Alexander\\ Torstling\\\\AppData\\\\Local\\\\Packages\\\\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\\\\LocalState\\\\rootfs\\\\home\\\\alext\\\\projects\\\\<redacted>\\\\<redacted>\\\\local"]

Stderr: VBoxManage.exe: error: Shared folder path '\\\\\?\\\\mnt\\c\\Users\\Alexander\ Torstling\\AppData\\Local\\Packages\\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\\LocalState\\rootfs\\home\\alext\\projects\\<redacted>\\<redacted>\\local' is not absolute
VBoxManage.exe: error: Details: code E_INVALIDARG (0x80070057), component SharedFolderWrap, interface ISharedFolder, callee IUnknown
VBoxManage.exe: error: Context: "CreateSharedFolder(Bstr(name).raw(), Bstr(hostpath).raw(), fWritable, fAutoMount)" at line 1031 of file VBoxManageMisc.cpp

Shall we continue in another channel perhaps? How can I reach you?

[briancain]

Closing via #9525

[bitmendicant]

I tried out Vagrant for the first time today, ran into this problem, and re-did all the work to figure it out before discovering this issue and recognizing that it addresses my exact situation. /sigh

So, for the sake of posterity and searches,

vboxsf mount failure with Vagrant in WSL

If you are a WSL user and you get this error while trying to vagrant up in some subdirectory of your Bash on Windows home directory:

Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attempted was:

mount -t vboxsf -o uid=1000,gid=1000 vagrant /vagrant

The error output from the command was:

/sbin/mount.vboxsf: mounting failed with the error: Protocol error

...it's because Vagrant is trying to mount the wrong Windows path to your WSL directory as a shared folder in your VM. You can see that in the VirtualBox GUI by looking at the VM's Settings > Shared Folders > Machine Folders entry. If it has lxss in there and you installed Ubuntu through the Microsoft Store because you have at least the Fall Creators Update, that's the source of your mount problem. It sounds like #9525 should fix this after it is cut into a new Vagrant release.

Should Vagrant mount WSL rootfs directories as shared folders at all?

To the subscribers/contributors on this thread: are there any concerns with having Vagrant just mount the new rootfs location as a shared folder into a VM? I'm wondering because the WSL devs strongly advise, "Do not change Linux files using Windows apps and tools." In other words, what's the risk that mounting a WSL rootfs subdirectory into a VirtualBox VM will lead to file corruption? I am totally new to Vagrant and don't really know what it's doing under the hood here. I have had luck just making a project directory in a non-hidden location elsewhere under /mnt/c, though, which seems to be what the WSL devs recommend.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.