First to double-check: Have you followed these instructions? https://roots.io/getting-started/docs/windows-development-environment-trellis/
Second, I can spot at least two problems:
- The log for Vagrant’s output shows it’s trying to install a box called “base.” I’m pretty this this is wrong, and it should be trying to install a box called “bento/ubuntu-18.04” (see Trellis repo: https://github.com/roots/trellis/blob/master/vagrant.default.yml). This makes me think that for some reason Vagrant is unable to find your
vagrant.default.yml file which contains all the details it needs to actually set up the correct VM.
- The actual error mentions
Couldn't open the file /C:/WINDOWS/system32/base which is a strange error message for several reasons, but the most obvious is that the file path there will never resolve to anything: iirc Windows drives in WSL are all found under
/mnt/, so if there were a file in that location the path would be
/mnt/c/windows/system32/base. I really don’t think Vagrant should be putting anything in your Windows folder, though—that seems very strange.
This is 100% a guess, but given your screenshot it looks like you’re setting up your project in a directory beneath your WSL user directory (
~/Sites/example). Usually when I’m setting up projects in WSL I put them in locations that are “in” Windows’ file structure but have been mounted to WSL as mentioned above. For instance, I keep my project files in
/c/users/ben/Clients (or, in Windows
C:\users\ben\Clients). iirc WSL has its own virtual file system, which is where the user directory, Linux system directories, etc, are located, and Windows doesn’t have access to the stuff on this virtual filesystem (because Windows can’t understand most Linux filesystems). When you’re running Vagrant in WSL, what you’re actually doing is running Vagrant in Windows because WSL can’t create virtual machines. My guess is that Vagrant in Windows is unable to see your files because they’re in that virtual WSL filesystem—specifically your
vagrant.default.yml file—which is why it tries to install a nonexistent box called
base and then tries to download into
windows/system32/ (probably the default working directory for certain running executables). My guess is that it fails because it can’t write to that directory w/o admin permissions, but it shouldn’t be writing to that directory anyway.
My suggestion would be to try your setup process again, but instead of installing to
~/Sites/example in WSL, you install to something like
/mnt/c/users/your-user/Sites/example. If that works and you don’t like typing out
/mnt/etc... then you can always symlink your Windows-located sites directory to something like