Vagrant removes any and all shared folders I use for VirtualBox based machines whenever I destroy a vagrant VM

[Sérgio Lopes]

Hi,

I use, without vagrant, several virtual machines (Windows, Ubuntu, etc.) on VirtualBox, on all of them I have setup a shared folder that in some cases is automatically mounted in the guest. I've now started to use vagrant for some of the development machines and whenever I destroy a VM (still working/learning how to setup some of env.) the shared folder I setup manually is also deleted.

It doesn't matter if I created it again (just the folder, the setting in VBox never changes), as soon as I destroy a VM in vagrant the shared folder is removed along with the vagrant's VM files.

Is there any way to prevent this? I usually don't have any files in the shared folder, but it is annoying to have to remember to create the folder again after using vagrant and before starting any VBox machine.

Regards,

Sérgio Lopes

[Alvaro Miranda Aguilera]

hello

it shouldnt delete anything on the host

whats your host os and guest?

can you share a sample vagrantfile to see how do you create the shared folder?

--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sérgio Lopes]

Hi,

On Saturday, January 24, 2015 at 2:36:13 AM UTC, Alvaro Miranda Aguilera wrote:

it shouldnt delete anything on the host

It deletes only the folder I had setup as a shared folder between guests and the host. And initially I thought it did it when I destroyed the vagrant based VM but in fact it does it as soon as the machine has booted and just (I think) just before running the provisioner script I created. 

whats your host os and guest?

Sorry, should have written those details in the first message, I'm using OSX Yosemite (10.10.1) on a Macbook Pro (2013/Retina/2.3 Core i7), latest Virtual Box (4.3.20 r96996) with the extension pack for that version. At the moment I have two Windows 7 and one Ubuntu (latest) virtual machines. Vagrant installed from the provided DMG for version 1.7.2.

can you share a sample vagrantfile to see how do you create the shared folder?

I don't  change the default shared folder settings from vagrant, so I have nothing on the Vagrantfile regarding them, but I've posted the contents below.

I setup all my VMs in VirtualBox with a shared folder name "Shared", this folder is placed in VirtualBox's VMs folder (where all VMs are created and where vagrant adds its files while a VM is up). For the "standard" VMs I used the VirtualBox settings panel and added a shared folder, and the Windows VMs even have it mapped to as a network drive. What I noticed was that while booting a machine in VirtualBox it started complaining about the missing "Shared" folder and that VMs could fail to run ( the usual error message when some resource is missing). I created the folder again in Finder (file explorer) and used the VM as I usually. Sometime later I went back to testing my vagrantfile and some changes to the provisioner script and noticed that the "Shared" folder was gone after shutting down the vagrant VM.

I run the process a few times and sure enough, as soon as the vagrant based VM is up the "Shared" folder is deleted, if I leave Finder's window open I see it being removed just when vagrant maps my host folder to /vagrant.

Vagrantfile:

-----

# -*- mode: ruby -*-

# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure

# configures the configuration version (we support older styles for

# backwards compatibility). Please don't change it unless you know what

# you're doing.

Vagrant.configure(2) do |config|

  # For a complete reference check https://docs.vagrantup.com, or just create a

  # dummy Vagrantfile to get the basic examples.

  # Currenlty loading boxes from the default Atlas/HashiCorp repository. Speed

  # is good enough for initial loading/caching process.

  # More boxes can be found at https://atlas.hashicorp.com/search.

  config.vm.box = "chef/debian-7.7"

  # Map local port to guest HTTP port, 9595 seems as "random" as expected but 

  # this could be made smarter

  config.vm.network "forwarded_port", guest: 80, host: 9595

  # VirtualBox-specific settings.

  config.vm.provider "virtualbox" do |vb|

  #   vb.gui = true

    vb.memory = "1024"

  end

  # "Simple" shell script to bootstrap development environment.

  config.vm.provision "shell", path: "vagrant-bootstrap.sh"

end

----

Regards,

Sérgio Lopes

[Sérgio Lopes]

Just to clarify, the only guest I'm running with vagrant is a Debian 7.7 base box, available from the standard repo as chef/debian-7.7.

The other VMs I run using VirtualBox manager/interface and existed before I installed vagrant.

Regards,

Sérgio Lopes

[Alvaro Miranda Aguilera]

Hello,

If you want that shared folder in the machine being managed by Vagrant, you should put that into the Vagrantfile, since when vagrant  start the machine, will clear the configuration for network, and shared folders.

https://docs.vagrantup.com/v2/synced-folders/basic_usage.html

Please test, and give it a try

--

[Sérgio Lopes]

Hi,

 

Hello,

If you want that shared folder in the machine being managed by Vagrant, you should put that into the Vagrantfile, since when vagrant  start the machine, will clear the configuration for network, and shared folders.

I don't want vagrant to touch that one particular folder, it is used by me to do work that doesn't envolve vagrant and I don't see why vagrant should be concerned about that folder. I also don't want that folder to exist in the Vagrantfile as the file in part of the git repository shared with other coworkers.

If vagrant touches other VM settings or changes VirtualBox settings in a way that destroys them, should that be considered a bug? I mean, I had a shared folder setup before installing vagrant, I never told vagrant to remove it or change it in any way and vagrant is changing stuff outside its working area... or does this only happen with VirtualBox?

I'll test the changes you suggested but this wasn't an expected behaviour and it should probably be written in the docs.

Regards,

Sérgio Lopes