tomjn
commented
3 weeks ago So this is an issue in vagrant itself rather than VVV, I encountered it and made a PR upstream so a new release of vagrant should fix this ( 2.4.2 most likely but it hasn't been released yet ).
As for how I resolved this, it involved removing docker networks, docker network ls will list all the networks available and their network IDs. Use docker network prune to auto-remove unused networks and try the vagrant command again. If that doesn't help, remove anything vagrant related that's listed in docker network ls using docker network rm and try again.
Note that this only impacts the Docker provider, other providers are unaffected. Also remember that vagrant will always stick to the provider of the current VM, even if you change your mind. So if you start with a docker provider, you'll need to destroy that VM before you can switch to Parallels/etc
columbian-chris
GitHub
What was The Command Used To Provision
Using only an out of the box clone from this VVV GitHub repository with no customizations and using default config.
What Kind of VVV Provision Was This
This was a fresh install
Logs/What Broke
Trying to install with Docker via
vagrant up --provision --provider="docker"resulted in this:Trying to provision with Parallels via
vagrant up --provision --provider="parallels"resulted in this:And then finally attempting to provision with VMWare via
vagrant up --provision --provider="vmware_desktop"resulted with this:I thought at least one of these would work now that I'm on an Apple Silicon machine and no longer am able to use virtualbox.
Your Environment
VVV: v3.14 Ruby: 3.1.4 git develop branch, commit 8f4eaaae Platform: darwin shell:/bin/zsh shared_db_folder_disabled Vagrant: v2.4.1 Parallels: v19.4.1 VMWare: Fusion Professional Version 13.5.2 (23775688) Docker Desktop: v4.33.0 (160616), Engine: 27.1.1 MacBook with Apple M3 Max chip MacOS Sonoma 14.6.1 (23G93)