docker-machine created Virtualbox VM does not mount a shared volume from Centos 7 host

[dpneumo]

Context:
Host OS: CentOS 7
Virtualbox version: 5.0.16
docker -v: Docker version 1.10.3, build 20f81dd
docker-machine -v: docker-machine version 0.6.0, build e27fb87

VM creation (to act as docker container host for local development):

  On the CentOS 7 physical host:
  $ whoami
  loco

  $ docker-machine create --driver virtualbox research
    Running pre-create checks...
  Creating machine...
  (research) Copying /home/loco/.docker/machine/cache/boot2docker.iso to /home/loco/.docker/machine/machines/research/boot2docker.iso...
  (research) Creating VirtualBox VM...
  (research) Creating SSH key...
  (research) Starting the VM...
  (research) Check network to re-create if needed...
  (research) Waiting for an IP...
  Waiting for machine to be running, this may take a few minutes...
  Detecting operating system of created instance...
  Waiting for SSH to be available...
  Detecting the provisioner...
  Provisioning with boot2docker...
  Copying certs to the local machine directory...
  Copying certs to the remote machine...
  Setting Docker configuration on the remote daemon...
  Checking connection to Docker...
  Docker is up and running!
  To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env research

  $ docker-machine env research
  export DOCKER_TLS_VERIFY="1"
  export DOCKER_HOST="tcp://192.168.99.102:2376"
  export DOCKER_CERT_PATH="/home/loco/.docker/machine/machines/research"
  export DOCKER_MACHINE_NAME="research"
  # Run this command to configure your shell:
  # eval $(docker-machine env research)

  $ eval $(docker-machine env research)

  $ docker-machine ssh research
  ...
  Boot2Docker version 1.10.3, build master : 625117e - Thu Mar 10 22:09:02 UTC 2016
  Docker version 1.10.3, build 20f81dd

  docker@research:~$ ls
  log.log
  docker@research:~$ cd ..
  docker@research:/home$ ls
  docker/

A search of the research VM's folder tree does not show any mount of the loco user's home folder within the research VM.

Contents of /etc/fstab and /etc/mtab in the created VM, research:

  docker@research:~$ cat /etc/fstab
  # /etc/fstab
  proc            /proc        proc    defaults          0       0
  sysfs           /sys         sysfs   defaults          0       0
  devpts          /dev/pts     devpts  defaults          0       0
  tmpfs           /dev/shm     tmpfs   defaults          0       0
  /dev/zram0      swap         swap    defaults,noauto   0       0
  /dev/sda1       /mnt/sda1       ext4     noauto,users,exec    0 0 # Added by TC
  /dev/sda2       none            swap     defaults             0 0 # Added by TC
  /dev/sr0        /mnt/sr0        auto     noauto,users,exec    0 0 # Added by TC

  docker@research:~$ cat /etc/mtab
  tmpfs / tmpfs rw,relatime,size=917988k 0 0
  proc /proc proc rw,relatime 0 0
  sysfs /sys sysfs rw,relatime 0 0
  devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
  tmpfs /dev/shm tmpfs rw,relatime 0 0
  fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
  /dev/sda1 /mnt/sda1 ext4 rw,relatime,data=ordered 0 0
  cgroup /sys/fs/cgroup tmpfs rw,relatime,mode=755 0 0
  cgroup /sys/fs/cgroup/cpuset cgroup rw,relatime,cpuset 0 0
  cgroup /sys/fs/cgroup/cpu cgroup rw,relatime,cpu 0 0
  cgroup /sys/fs/cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0
  cgroup /sys/fs/cgroup/blkio cgroup rw,relatime,blkio 0 0
  cgroup /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0
  cgroup /sys/fs/cgroup/devices cgroup rw,relatime,devices 0 0
  cgroup /sys/fs/cgroup/freezer cgroup rw,relatime,freezer 0 0
  cgroup /sys/fs/cgroup/net_cls cgroup rw,relatime,net_cls 0 0
  cgroup /sys/fs/cgroup/perf_event cgroup rw,relatime,perf_event 0 0
  cgroup /sys/fs/cgroup/net_prio cgroup rw,relatime,net_prio 0 0
  cgroup /sys/fs/cgroup/hugetlb cgroup rw,relatime,hugetlb 0 0
  /dev/sda1 /mnt/sda1/var/lib/docker/aufs ext4 rw,relatime,data=ordered 0 0

An Ubuntu VM created with the Virtualbox GUI Manager does in fact contain the expected shared home folder for the user.

Am I missing something that I should be doing or is this in fact a functional lack in the docker-machine app?

[dpneumo]

Have created a gist containing the VBox.log and the --debug output generated during the creation of the VM with docker-machine --debug create --driver virtualbox research

https://gist.github.com/dpneumo/e8567149ae9863e0c82b

Looks like docker-machine create tries to mount the host's /home at a folder named "hostname" in the created VM. I would think that given the documentation concerning this that it would be attempting to mount the host folder /home/ at /home/ in the created VM. That does not appear to happen.

I would also think that the failure to create the shared folder would generate an error message of some kind... Perhaps even one that helps the user solve the problem.

[dpneumo]

Have looked at the underlying code. Though I am not a Go programmer, I think these changes would fix things for Linux hosts:

In virtualbox.go:

func (d *Driver) CreateVM() error {

  // ...

  // let VBoxService do nice magic automounting (when it's used)

// Replace this around line 411:
  //  if err := d.vbm("guestproperty", "set", d.MachineName, "/VirtualBox/GuestAdd/SharedFolders/MountPrefix", "/"); err != nil {
  //    return err
  //  }
  //
  //  if err := d.vbm("guestproperty", "set", d.MachineName, "/VirtualBox/GuestAdd/SharedFolders/MountDir", "/"); err != nil {
  //    return err
  //  }
  //  ...

// With this (including some rearranging of the original code for clarity, etc):
  shareName, shareDir := getShareDriveAndName()

  if shareDir != "" && !d.NoShare {
    log.Debugf("setting up shareDir")
    if _, err := os.Stat(shareDir); err != nil && !os.IsNotExist(err) {
      return err
    } else if !os.IsNotExist(err) {
      // woo, shareDir exists!  let's carry on!

      // IMHO the shared folders mount prefix should be an empty string
      if err := d.vbm("guestproperty", "set", d.MachineName, "/VirtualBox/GuestAdd/SharedFolders/MountPrefix", ""); err != nil {
        return err
      }

      shareName = cleanShareName(shareName)

      // Set the mount dir in docker home directory
      mountDir := "/home/docker"
      if err := d.vbm("guestproperty", "set", d.MachineName, "/VirtualBox/GuestAdd/SharedFolders/MountDir", mountDir); err != nil {
        return err
      }

      if err := d.vbm("sharedfolder", "add", d.MachineName, "--name", shareName, "--hostpath", shareDir, "--automount"); err != nil {
        return err
      }

      // enable symlinks
      if err := d.vbm("setextradata", d.MachineName, "VBoxInternal2/SharedFoldersEnableSymlinksCreate/"+shareName, "1"); err != nil {
        return err
      }
    }
  }

  return d.Start()
}


func cleanShareName(shareName string) string {
  if shareName == "" { sharename = shareDir }

  // parts of the VBox internal code are buggy with share names that start with "/"
  shareName = strings.TrimLeft(shareName, "/")

  // TODO do some basic Windows -> MSYS path conversion
  // ie, s!^([a-z]+):[/\\]+!\1/!; s!\\!/!g

  return shareName
}

And in virtualbox_linux.go:

// Replace this around line 39:
//  func getShareDriveAndName() (string, string) {
//    return "hosthome", "/home"
//  }

// With this:
func getShareDriveAndName() (string, string) {
  userName, _ := os.LookupEnv("$USER")
  return "hosthome", "/home/"+userName
}

Since I have no experience with Go (I work predominantly with ruby and python), I have not put this into a pull request. Some thought should be given to potential effects of these changes on Mac, Windows, and other users before committing the changes. Tests would be appropriate and I am really uncertain how those should be set up. BTW. There does not appear to be any tests of the shared drive code at present.

Go looks interesting and fun. Will plan to explore further. Perhaps then could add something further to this.

[nathanleclaire]

Shared folders are not supported on Linux hosts today. Unless I'm mistaken, I think this is already documented on other issues.

The code on Machine's end should be functional already I think, but a change needs to be merged into upstream boot2docker/boot2docker to make it possible. You could always bake your own boot2docker.iso in the meanwhile: boot2docker/boot2docker#1086 (Tianon's comment in that thread also sums up accurately why this isn't implemented directly today)