To provide some context about why this is being reintroduced despite so many expressed reservations, 'boot2docker' currently is essentially the 'Docker daemon for Mac OS / Windows'. Mutt 1.8 .muttrc file for /var/mail mac os x email. On Mac OS at least, where we have a native Docker client, the experience of talking to your 'Docker daemon' currently lacks the ability to bind mount files, which causes a lot of problems including fig not working as it should. This is being pushed as a simple stopgap solution to that specific problem while other more sustainable solutions are developed in Docker itself (such as is proposed in ). This builds upon the work in.

The supplied VBOX Guest Additions ISO has guest installation utilites for Windows, Linux, Solaris, and OS2, but lacks guest additions for OSX. Does VirtualBox provide any guest additions for El Capitan guests (running on Mac hardware)? VirtualBox is a general-purpose full virtualizer for x86 hardware, targeted at server, desktop and embedded use.For a thorough introduction to virtualization and VirtualBox.

Also, this includes a hacky init script that gets to take all the credit for that tries to mount /Users and/or /c/Users, since we can't run VBoxService proper (thanks to hairy issues with 32bit userspace of TCL; good times). The init script will bail quickly and quietly on non-VirtualBox machines or on VirtualBox machines that don't have one of those two shares.

This has been tested on Linux, Mac OS X, and Windows. If you'd like to test it out without any changes to boot2docker-cli, use: • Mac OS X: VBoxManage sharedfolder add boot2docker-vm --name /Users --hostpath /Users --automount • Windows: VBoxManage.exe sharedfolder add boot2docker-vm --name /c/Users --hostpath C:/Users --automount (note that this will NOT WORK from inside the msys bash shell because of - you must either run it from cmd directly, or create the share of C: Users named as /c/Users manually) This will make it so that things like docker run -v '$(pwd)':/some/container/path. Work as you'd expect from Mac OS, and also so that the /Users or /c/Users directory is available for easy access when you boot2docker ssh into your VM. As a side note, if anyone has ideas for how to disable or prevent that msys path conversion from happening without linking against msys.dll, please please please let me know (I can't find anything useful). I've run into the msys auto-conversion thing myself and the only thing I've found is that if you add an extra / to the path it should prevent the conversion (though you end up with both slashes, so sometimes that doesn't really help). Not sure if trick will work here, but it might be worth a shot (I'll try it out myself at some point, but that won't be for a bit due to other work priorities).

Oh -- and thanks for resurrecting this. I know it is controversial, but it really does make life for those of us working on Windows a lot nicer (the lack of a native Docker client there gives us a few more issues than our Mac brethren). For boot2docker on linux, VBoxService would really be ideal so that we only share $HOME by default and let it automount properly (especially so we don't have the share mount breaking /home/docker in the guest, or have /home/docker bleeding outwards into the host), but since the VBox binaries won't work properly in our 32bit userspace with our 64bit kernel, we can't even enumerate the current shares and just have to poke around in the dark. I do want to fix that as a future enhancement, though, which is why I mentioned VBoxService in the comment here. I've definitely been testing this all in Linux. Specifically because it requires post-processing in 'boot2docker up', but if we could get 'VBoxService' working (or even just 'VBoxControl', but in my testing they both fail in the same way because of the same issues) we could have that without any extra work by either side, which I'd definitely be +1 on (and is actually exactly why I wanted to hard lock the share-name to the inside-the-guest path like I have here, since it makes it easier for people to set up scenarios like that if they want to). Ok, I've updated with a paragraph about the nonexistent Linux support: (copied here for easier review) In case it isn't already clear, the Linux host support here is currently hazy.