Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vagrant 2.24 issues with suspend/up losing VirtualBox shared folders #10735

Open
dswitzer opened this issue Mar 14, 2019 · 4 comments
Open

Vagrant 2.24 issues with suspend/up losing VirtualBox shared folders #10735

dswitzer opened this issue Mar 14, 2019 · 4 comments

Comments

@dswitzer
Copy link

Please note that the Vagrant issue tracker is in priority reserved for bug reports and enhancements. For general usage questions, please use the Vagrant mailing list:
https://groups.google.com/forum/#!forum/vagrant-up. Thank you!

Tip: Before submitting your issue, don't hesitate to remove the above introductory text, possible empty sections (e.g. References), and this tip.

Vagrant version

Vagrant 2.2.4

Host operating system

Windows 10.0.17763 (Build 17763)

Guest operating system

CentOS release 6.10 (Final)
Linux version 2.6.32-754.10.1.el6.x86_64 (mockbuild@x86-01.bsys.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC) ) #1 SMP Tue Jan 15 17:07:28 UTC 2019

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|
  # Every Vagrant development environment requires a box. You can search for
  # boxes at https:/atlas.hashicorp.com/search.
  config.vm.box     = "/centos-6.6-x86_64"
  config.vm.box_url = "http:/internal.storage/private_box"


  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  config.vm.network "private_network", ip: "192.168.100.2"#, name: "VirtualBox Host-Only Ethernet Adapter #5"
  config.vm.network "private_network", ip: "192.168.100.3"#, name: "VirtualBox Host-Only Ethernet Adapter #6"
  config.vm.network "private_network", ip: "192.168.100.4"#, name: "VirtualBox Host-Only Ethernet Adapter #7"
  config.vm.network "private_network", ip: "192.168.100.5"#, name: "VirtualBox Host-Only Ethernet Adapter #8"

  # Provider-specific configuration so you can fine-tune various
  # backing providers for Vagrant. These expose provider-specific options.
  # Example for VirtualBox:
  #
  config.vm.provider "virtualbox" do |vb|
    # Display the VirtualBox GUI when booting the machine
    vb.gui = false

    # Customize the amount of CPU & memory on the VM:
    vb.cpus = 2
    vb.memory = 4096
  end


  # Share an additional folder to the guest VM. The first argument is
  # the path on the host to the actual folder. The second argument is
  # the path on the guest to mount the folder. And the optional third
  # argument is a set of non-required options.
  config.vm.synced_folder "sites/app/trunk/", "/var/www/app/", create: true , owner: 501, group: 501, mount_options: ["dmode=750,fmode=750"  # set up personal space

  # install apache
  config.vm.provision "os-sync-folder-fix", type: "shell", inline: <<-SHELL
    echo "Fix services that need restarting after synced folders..."
    # install Apache and required mods (gcc & httpd-devel are needed for compiling code)
    sudo cp --force /vagrant/.vagrant-files/files/os/etc/init/vagrant-mount.conf /etc/init/vagrant-mount.conf
 SHELL

end

Debug output

Expected behavior

When restoring from a suspended state, the VirtualBox should be restored with fully working shared folders.

Actual behavior

Every since upgrading to Vagrant 2.2.4, I've been having an issue where my provisioned folders are being lost after I resume from a suspended vagrant state. This does not happen every time, but it's happening probably happening about 33% of the time.

It's possible this is related to VirtualBox v6.0.4 r128413 (Qt5.6.2), but I had Vagrant 2.2.3 and this version of Vagrant running for a couple of weeks and never saw the issue until I recently upgraded to Vagrant 2.2.4.

After I resume, I'll notice that my web application is returning 403 - Forbidden headers from Apache. When I log in via SSH I'll notice the /vagrant/ folder still appears to be mounted, but it's broken. Most of the permissions have ? marks and I cannot access the mounted folder.

Steps to reproduce

  1. Use vagrant suspend to put the VM into a suspended state.
  2. Use vagrant up to resume.
@dswitzer
Copy link
Author

I'm actually thinking this may be related to this VirtualBox issue:

https://www.virtualbox.org/ticket/18220

It sounds like the exact same issue. I'm not sure why I didn't hit it with earlier versions of Vagrant, so maybe there's a combination of things going on.

Is there a way for Vagrant to re-mount the shares w/out reloading the VM?

@mwhitelaw
Copy link

I believe I have the same or a very closely related issue,
Host: Windows 10.0.17763
Guest: Centos 6.3

Vagrantfile

Vagrant.configure("2") do |config|
  config.ssh.sudo_command = "sudo %c"
  config.vm.define "build32" do |build32|
    build32.vm.box = "markwhitelaw/Centos6-i686"
    #build32.vm.box = "rafacas/centos63-i386-plain"

    #forward ssh port from localhost 2232 to geust port 22
    build32.vm.network "forwarded_port", guest: 22, host: 2232

  # Share an additional folder to the guest VM. 
  # config.vm.synced_folder "../data", "/vagrant_data"

    build32.vm.provider "virtualbox" do |vb|
      vb.memory = "1024"
      vb.name="build32"
    end

    #provision the script provision.h which will configure repos and
    #install devtoolset-6 for building c/c++ applications
    build32.vm.provision "shell", path: "provision32.sh"
    build32.vm.provision "file", source: "../Source/ExternalLibs", destination: "$HOME/projects/externallibs"
  end
end

When I created this box using vagrant 2.2.3 - it would take approximately 2 minutes, after upgrading to vagrant 2.2.4 it now takes 20 minutes to bring the box up.

All the additional time is taken in the file provisioning:
I set the env variable VAGRANT_LOG=info and brought the box up again and a large number of repeated attempts to make target directories appear to be attempted (with sleep delays between each attempt) :

SET VAGRANT_LOG=info
vagrant up build32 >v.log 2>&1

v.log content:

 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)
 INFO ssh: Execute: mkdir -p "/home/vagrant/projects/externallibs/ASN/skeletons" (sudo=false)

These folders do already exist in the template, not sure if this is now causing the problem as it didn't with previous vagrant version.

@dswitzer
Copy link
Author

dswitzer commented Jun 7, 2019

I think this problem was actually being cause by VirtualBox. Since upgrading to VirtualBox v6.0.6 r130049 (Qt5.6.2), I don't think I've seen the issue again. Prior to install the VB update, I was seeing the issue a couple of times a week, but I've been on VB 6.0.6 r130049 (Qt5.6.2) for a few weeks now and don't recall seeing the issue once.

@marcelrend
Copy link

Upgrading from V6.0.2 to the V6.0.10 fixed the issue for me as well. Thanks @dswitzer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants