VBox guest additions #284

Closed
wants to merge 1 commit into
from

Projects

None yet
@steeve
Contributor
steeve commented Mar 14, 2014

This is a PR in response to #282.
It adds ~400kb to the unpacked system.
Please discuss wether vboxsf are a good option of not in #282, not here.

Add a shared folder to the VM:

$ boot2docker stop
$ VBoxManage sharedfolder add boot2docker-vm -name home -hostpath $HOME

Now mount the folder inside the VM:

$ boot2docker up
$ boot2docker ssh "sudo modprobe vboxsf && mkdir -p $HOME && sudo mount -t vboxsf home $HOME"

You can now run docker -v transparently as long as the volume is inside $HOME.

A test ISO based on 0.7 is at https://dl.dropboxusercontent.com/u/12014139/boot2docker.iso

@shlomifruchter

Is there a workaround for now? How can I manually install the vbox guest additions on the boot2docker image?

@steeve
Contributor
steeve commented Mar 17, 2014

The best and easiest way is to build the image yourself from the Dockerfile

This was referenced Mar 17, 2014
@aheissenberger
Contributor

👍 @steeve you are a hero!

now it will be very easy to access e.g. IP of VM and other stuff thru the GuestProperty API

On the Host the properties are accessed through VBoxManage command with the following qualifiers:
guestproperty get <vmname>|<uuid> <property> [-verbose]
guestproperty set <vmname>|<uuid> <property> [<value> [-flags <flags>]] 
guestproperty enumerate <vmname>|<uuid> [-patterns <patterns>]

and on the Guest with the corresponding VBoxControl commands

guestproperty get <property> [-verbose]
guestproperty set <property> [<value> [-flags <flags>]] 
guestproperty enumerate [-patterns <patterns>]
@cameronmaske cameronmaske added a commit to cameronmaske/docker-osx that referenced this pull request Mar 26, 2014
@cameronmaske cameronmaske Replace Ubuntu VM with boot2docker.
Setup HOME directory mounting using this [workaround](boot2docker/boot2docker#284).
Uses an forked boot2docker shell script (based on boot2docker/boot2docker#93) but fast forward to the latest master to allow a fixed ip address for guest and host (aka localdocker).
Removed Vagrant, VM is managed by VirtualBox alone.
a8db1e9
@lightsofapollo

For me this is the only thing that makes me keep around my custom docker environment (vagrant basically) -v is required for happy docker usage :)

@steeve
Contributor
steeve commented Mar 28, 2014

Can we merge this already guys ?

@nsfmc
nsfmc commented Mar 29, 2014

sorry if this is super reductive, but i was playing around with this and noticed that the hardcoded guest-additions are likely to be incompatible with most folks' virtualbox installs. does it make sense to

but they both add a time-overhead over just downloading a 'working' boot2docker image, but it seems like there would almost certainly be compatibility issues between guest-addition versions (which seem to change every week or so).

also i could be totally missing something. let me know if i'm approaching this in a naive way, i'm mostly trying to simplify an install of docker among a group of computers in a super heterogenous environment and this point jumped out at me. thanks for any feedback.

@steeve
Contributor
steeve commented Mar 30, 2014

Well, boot2docker has an amazing feature, which makes most of your concerns go away imho: the OS is read only.
That means that when you need to update, your restart the OS with a new version of it.

Obviously the guest additions evolve rapidly, but VBox versions don't get released that often. And when they do we take a good look at them.
Thankfully VBox guest additions are backward compatible, so we don't screw existing installs.

The thing is, boot2docker strives to Just WorkTM, and to provide the best experience for folks without doing anything (it's a goal 😃). Plus the added weight/complexity to the image is negligible, as we already have some VM (QEMU/VMware/VBox) detection mechanism going on to force dockerd to listen on 0.0.0.0 (which is a no-no on baremetal).

That said, I should probably update the PR with the newly released VBox.

@tianon
Contributor
tianon commented Mar 30, 2014

I'm still -1 on this change in general, as it further reduces the agnosticism of boot2docker and encourages what is a fairly destructive and confusing pattern. The problem of bind mounts not working from a remote Docker client is one that's general to all instances of a Docker daemon that listens non-locally, so I firmly believe the "proper" solution to this needs to (and indeed will, given time) come from the Docker side.

Just my 2¢.

@aidanhs
aidanhs commented Apr 2, 2014

@tianon has this been raised as a Docker issue then?

@tianon
Contributor
tianon commented Apr 2, 2014

Absolutely, this is being discussed in docker/docker#4023.

@hunterloftis

+1

@iwootten

Sorry to step in, but I've run these commands using the 0.7 boot2docker image linked to along with the 0.7 boot2docker script and I just get (on the final step):

"modprobe: module vboxsf not found in modules.dep"

I understand this has something to do with having the VBAdditions available, but I'm unable to figure out how to install this or enable it.

NB. I've also built using the Dockerfile in the commit (which seems successful), but leads to the same problem. I'm building on a Mac and some poking around seems to suggest VBAdditions isn't available for OSX. Can anyone suggest a solution until this is merged?

@steeve
Contributor
steeve commented Apr 15, 2014

I think you may not be booting from the right ISO file—
Steeve Morin

On Mon, Apr 14, 2014 at 9:44 AM, Ian Wootten notifications@github.com
wrote:

Sorry to step in, but I've run these commands using the 0.7 boot2docker image linked to along with the 0.7 boot2docker script and I just get (on the final step):
"modprobe: module vboxsf not found in modules.dep"
I understand this has something to do with having the VBAdditions available, but I'm unable to figure out how to install this or enable it.

NB. I've also built using the Dockerfile in the commit (which seems successful), but leads to the same problem. I'm building on a Mac and some poking around seems to suggest VBAdditions isn't available for the mac. Can anyone suggest a solution?

Reply to this email directly or view it on GitHub:
#284 (comment)

@bjaglin
Contributor
bjaglin commented Apr 15, 2014

For those willing to automate to the maximum this workaround and are fine with maintaining a custom image, I recommend adding $VBM sharedfolder add $VM_NAME -name home -hostpath /Users at the end of the init function in the boot2docker script, and registering modprobe vboxsf && mkdir -p /Users && mount -t vboxsf home /Users in some init.d script within the rootfs. This way, mounting volumes under /Users will work transparently, without any need for manual steps.

(Note that this is simply a slight variation of what's suggested in the issue description, removing the need to resolve $HOME on the VBox host)

@TheBigBear

What are the steps required to build a 'custom' iso like the one posted above under 'steeve's first comment:
[quote]
steeve said:
A test ISO based on 0.7 is at https://dl.dropboxusercontent.com/u/12014139/boot2docker.iso
[/quote]

Can this somehow be done 'scripted', or automated to the maximum, as bjaglin called it above, by using a Dockerfile somehow?

@bjaglin
Contributor
bjaglin commented Apr 15, 2014

@TheBigBear producing a custom iso is a fairly documented and simple process: https://github.com/boot2docker/boot2docker/blob/master/doc/BUILD.md

$ sudo docker build -t boot2docker/boot2docker:base base/
$ sudo docker build -t boot2docker/boot2docker-rootfs rootfs/
$ sudo docker rm build-boot2docker
# you will need more than 2GB memory for the next step
$ sudo docker run --privileged --name build-boot2docker boot2docker/boot2docker-rootfs
$ sudo docker cp build-boot2docker:/boot2docker.iso .
@TheBigBear

Thanks bjaglin that is great and very helpful.
So seeing that there is a lot more documentation out there than I was aware off and just to make sure I don't try to re-invent the wheel. ;-)
What I was hoping to do was to build a tcz extension pkg that contains the virtual box guest additions kernel modules to allow folder sharing (maybe I should plan to also include the others?) And then include this optional tcz kernel module extension pkg in the 'optional' pkgs dir on the iso and then have a Dockerfile that loads these guest extensions from the tcz extension pkg at boot time when I use my boot2docker client on my mac to boot off the boot2docker+optional_vbox_fs_extension.iso
This way the additional vbox flles only get into ram IF I chose to install this optional kernel modules tcz pkg.
Would any of this make sense? If not why not?

@SvenDowideit
Member

fundamentally, we are working towards not doing sharing this using vbox specific extensions. instead, the solution will come from either docker itself, or using a network shared volume container - see https://github.com/SvenDowideit/dockerfiles/blob/master/samba/Dockerfile for what I use to share my boot2docker tools with my Windows desktop.

bind-mounting a directory that is actually located remotely to the docker daemon is both risky and slow, whereas using network shared volume containers matches much more closely what you would do in deployment.

@tunix
tunix commented Apr 16, 2014

I'm a Mac user and really hoping an easy way of using docker with it. My development heavily relies on Virtualbox VM's and I want to convert it to docker containers. I can't make use of docker just because of this sharing folders issue. Is there a plan to solve this in near releases?

@mattes
Contributor
mattes commented Apr 16, 2014

Same here. @tunix Using https://github.com/noplay/docker-osx in the meanwhile works out for me.

@TheBigBear

OK, I am too new to docker to really know or understand how this all works together , just yet. But I have seen enough (mainly Mac) people's posts, and I am also one of them, that would like (even if it's temporary) a virtual box shared file integration.
How would I, basically combine the basic isos rebuild script from the instructions at
https://github.com/boot2docker/boot2docker/blob/master/doc/BUILD.md
with the vbox additons Dockerfile from:
https://gist.github.com/nsfmc/9862241#file-dockerfile-tmpl
and of course also the finale customisations that bjaglin mentions here
#284 (comment)
or can it even be done in one single Dockerfile?

The main question I have on this I think is how do I work a single Dockerfile so I can have the combination of these two manual lines:

$ sudo docker build -t boot2docker/boot2docker:base base/
$ sudo docker build -t boot2docker/boot2docker-rootfs rootfs/

I believe that once I understand how to do that, I think I can then "merge" all those pieces and instructions together into one final Dockerfile. (hopefully)

Thanks for a quick sample Dockerfile that achives the above two manual steps with a single Dockerfile?

@TheBigBear

I am quite stuck. Trying to folow the instructions bjaglin pointed me to at:

https://github.com/boot2docker/boot2docker/blob/master/doc/BUILD.md

but on the very first line I already get an error "no Dockerfile found in base/" when running
sudo docker build -t boot2docker/boot2docker:base base/

@1mentat
1mentat commented Apr 16, 2014

This does keep boot2docker from "just working" for all the people using it as the official OS X solution. We really need a resolution on this sooner rather than later.

@1mentat
1mentat commented Apr 16, 2014

@TheBigBear Here's what worked for me:

git clone https://gist.github.com/9862241.git
cd 9862241
sh build_docker.sh
docker build -t 1mentat/boot2docker-rootfs .
docker rm build-boot2docker
docker run --privileged --name build-boot2docker 1mentat/boot2docker-rootfs
docker cp build-boot2docker:/boot2docker.iso .
cp boot2docker.iso ~/.boot2docker/boot2docker.iso
boot2docker stop
VBoxManage sharedfolder add boot2docker-vm -name home -hostpath $HOME
VBoxManage sharedfolder add boot2docker-vm -name var_folders -hostpath /var/folders
boot2docker up
boot2docker ssh "sudo modprobe vboxsf && mkdir -p $HOME && sudo mount -t vboxsf home $HOME"
boot2docker ssh "sudo modprobe vboxsf && mkdir -p /var/folders && sudo mount -t vboxsf var_folders /var/folders"

Edited: Was missing VBoxManage command.
Edited: Added mapping for packer script provisioner.

@SvenDowideit
Member

Guys - does that mean you've tried the samba sharing container solution and its not sharing for you, or ?

@1mentat
1mentat commented Apr 17, 2014

@SvenDowideit I'm unclear on how I'd actually use that on OS X to get transparent -v mounting.

@SvenDowideit
Member

ok, I'll have to write up something.

the key takeaway is: using host mount -v /localdir:/container_dir should not be done, especially over a network fs. - using the samba server volume container means you're using --volumes-from.

and then you mount the samba share on your OSX, and point your IDE/editors to that.

@1mentat
1mentat commented Apr 17, 2014

I'm running into this purely from using packer.io, I don't have an commitment to it beyond being able to use that tool. I'll have to look at --volumes-from to see how to best file the feature request with that project.

@lazywei
lazywei commented Apr 17, 2014

@SvenDowideit I took a look at samba solution, but I don't know what to do after running make run?
I'm not familiar with samba. Could you give some instruction/example about how to use samba in this case?

@TheBigBear

@1mentat yes, you got it! It works!
If I prepare a shared folder in virtualbox called 'Downloads' and then do
boot2docker ssh
sudo -s
mkdir -p /home/docker/Downloads
chown docker:staff /home/docker/Downloads
modprobe vboxsf
mount -t vboxsf home /home/docker/Downloads
exit
df -h
and it shows me my hosts 'Downloads' directory mounted in my container. ;-)

so I think 1st part of solution is to create a shared folder share in virtualbox, if that's not there you can't mount it from the container.

not sure why the sudo modprobe line fails , but the sudo -s followed by modprobe works, my guess is it's something to do with the env that docker user has vs what root user has

PS: If I try to mount the home to /home/docker - that fails, but I guess there is possibly an open file handles or something that keeps me from mounting a shared folder to my own home dir that I am logged in to?

@TheBigBear

@1mentat I take that back. I now manually removed the Shared folders I had defined in virtualbox, and then started anew following the instructions on top of this page:

$ boot2docker stop
$ VBoxManage sharedfolder add boot2docker-vm -name home -hostpath $HOME

and after this the mounting worked flawlessly for me.

$ boot2docker up
$ boot2docker ssh "sudo modprobe vboxsf && mkdir -p $HOME && sudo mount -t vboxsf home $HOME"
@SvenDowideit
Member

@lazywei I finally have an OSX box, and am working through the things I need to write up a how to (well, ok, I'm making changes to the boot2docker manage tooling to make it even easier)

@steeve
Contributor
steeve commented Apr 23, 2014

I really think we should merge this PR, but leave the module loading optional, so that people know what are the consequences of using this.

Because the truth is, right now people are stuck on this. Even if it is for the wrong reasons relieving the pain until we have a better (or more idiomatic) solution should be our goal.

@steeve steeve referenced this pull request Apr 23, 2014
Closed

Can't mount a shared volume #62

@bfirsh
Member
bfirsh commented Apr 25, 2014

👍

Hopefully this means we can use boot2docker for Fig. (See docker/compose#26)

@crosbymichael
Contributor

LGTM ;)

@homerjam

+1

@sfitts
sfitts commented Apr 30, 2014

+1 (details below)

Let me start with the fact that I'm a Windows user (at least for my primary dev laptop). I've tweaked on the boot2docker script a bit and have it working nicely under Git Bash. Now I've got the issue that it seems many here do -- I need some way for the docker server running inside of VBox to have access to a directory structure on my dev box (specifically the root of my GitHub repo). A quick test of the iso shows that it does what I want.

@SvenDowideit At this point I'm not sure I understand how the samba/nfs alternative works. It may be much better, but I feel like I'm missing something. It seems to work in "reverse" of what I want (that is it would seem to set up a samba server which shares the volume of a docker container). I can see how I could then use a samba client on Windows to mount that, but to populate it I'd have to copy files to it. That's not quite what I want, I want to leave the files in place and have them be visible to the VM running docker. But like I said, I'm sure I'm missing something.

@1mentat Thanks much for the build instructions. Works like a charm.

@SvenDowideit
Member

@sfitts that is exactly right. The data locality is on the server side. There are a number of reasons for this - the biggest of which is that docker is focussed on portability - so linking your container to remote data (in this case your windows fs) makes your container less portable (as does the use of -v /host:/container on any platform).

The Docker project is working towards a fuller solution - but that will take time. For now, adding the vbox extenstions to allow vbox shares sounds like a short term gain, but it hurts in the medium and long term - I wanted Hyper-V support to have happened already, but I havn't found time.

BTW - rather than using the about to be removed boot2docker script - use https://github.com/boot2docker/boot2docker-cli - it has a windows, osx and linux binary. :)

@sfitts
sfitts commented Apr 30, 2014

Does it provide a docker client? Because that's where my issue lies. I have no desire to link the fs of my container(s) to my windows fs (and don't plan to do so), but I do need to link the fs of the VBox VM hosting the docker server to my windows fs. Otherwise when I run something like docker build -t <myImage> path/to/Dockerfile it won't find any files. Of course I could copy everything over or do a git pull on the VBox side to get my code, but that makes the development experience much different (which is problematic since we're a mixed OS shop). This makes it a somewhat different issue than on OSX where there is a first class docker client which handles such things.

I completely understand if this makes it a Docker issue and not a Boot2Docker issue, but from the perspective of the Windows user they are all part of the same eco-system (so they really can't be separated).

BTW -- I looked at boot2docker-cli, but at the time I started this (a month or so ago) it seemed to have issues on Windows. Great to see that first class support will be there, but for now I have the script working so I'm not in a hurry to switch (unless I get a spare cycle).

@SvenDowideit
Member

boot2docker-cli is a drop in replacement (except that the config file has changed) and there are a number of new features already - it adds a host-only network so you don't need to do the port forwarding thing, and I'm auto-adding ssh keys to the docker user.

mostly, if there are problems, its because i'm the only windows user/developer - I need help.

same pain for the Windows docker client - I don't know enough go yet to make it happen.

ok workflow wise - what I do atm, is I use volume containers for everything. that way my workflow is the same on all 3 platforms I use (win/osx/linux) - and then I use the samba share of my data volume to give my windows based tools to get access to the data.

This also means my workflow is the same when I use a remote boot2docker (as opposed to a vm based one).

@sfitts
sfitts commented May 1, 2014

So to install the files for a custom application into a container you would copy those files to the target container's volume instead of using ADD <src> <dest> in the Dockerfile?

I'm in the same boat wrt creating a native Windows docker client. I looked into a couple of options, but none of them panned out. My day job precludes too large a side project right now.

@SvenDowideit
Member

yup - what I do:

  • docker run -v /home --name home-vol busybox true
  • docker run ....... (lots of params) svendowideit/samba home-vol
  • connect to that share from windows, checkout my code to the share, and then edit away using the idea
  • docker run --volumes-from home-vol my-app-container
    OR
  • docker build (with ADD statements) from another container that has home-vol mounted, and has access to the docker daemon.

fundamentally, my windows box has no data in its filesystem - and half the time I'm not using a vbox based boot2docker, but doing exactly the same workflow to the rather larger docker-host I have in the data-center.

The assumption is that the container is doing lots of io and work, whereas the IDE is doing little - so it breaks down if you're doing video editing (where really, you'd run the gui app in a container, and just transmit the gui over the network)

@sfitts
sfitts commented May 1, 2014

Interesting. I can see how that would work well, though I'm not sure I'm ready to go that route (but I'm still wrapping my head around the "docker as a way to bootstrap your build" model). I do think it is nice to have a way to work with Dockerfiles that use ADD directly so having shared folders as an option is useful. So I stand by my +1, for now ;).

I'll take another look at the cli project tonight and report any issues I find (I've bumped my head on all the issues you mentioned, so having them addressed cleanly would be good).

@sambanks
sambanks commented May 8, 2014

+1 for this.

Using Ubuntu at the moment solely due to a lack of a hdd installable boot2docker image.

Tried to do dd of this to a partition, but wouldn't boot. Guessing that ability came after 0.7?

Cheers
Sam

@sfitts
sfitts commented May 8, 2014

@sambanks FWIW I have successfully built the current version of boot2docker with this pull applied using the instructions provided by @1mentat above. This gives me the most recent version with the ability to mount a directory from my local windows FS in the VBox VM (thus giving the docker server direct access to my disk, just as it would have if it were running directly on Windows). At this point it is all working well for me. Not sure if that will help you or not.

@sambanks
sambanks commented May 9, 2014

Ah, how did I miss that?! Thanks @sfitts and @1mentat that worked a treat!

Have now converted it to a vdi and have exactly what I wanted.

@dduportal
Contributor

Hi, I got another use case with my Windows configuration : i need to build my containers on this windows, for testing purposes (of my app).

Concrete example :

  • Checkout a repo with a basic project inside from windows (yeah, we got cool GUI for editing and "gitting")
  • Build the "container-app" (e.g. docker build with build commands (nom for node, mvm for java, etc.) from the source code
  • Run the freshly built container.

=> How to proceed with data container ?

@hnakamur hnakamur referenced this pull request in YungSang/boot2docker-vagrant-box May 18, 2014
Merged

Upgrade boot2docker to version 0.9.1 #3

@tgross
tgross commented May 20, 2014

Just for anyone else who runs into problems with the gist provided above and the current version of boot2docker, I've modified that gist here https://gist.github.com/tgross/ad9892dcc86bee922772. This seems to be working for me. I'm then adding to the boot2docker script the following:

to init():

$VBM sharedfolder add $VM_NAME \
        --name source --hostpath $HOST_PATH_FOR_SOURCE_CODE

to start():

boot2docker ssh "sudo mkdir /src; sudo modprobe vboxsf && sudo mount -t vboxsf source /src"
@bfirsh
Member
bfirsh commented May 21, 2014

@steeve @SvenDowideit What is the status of this? What is missing to get it merged that I could work on?

I can imagine there also being something added to boot2docker-cli to mount directories (ideally automatically?).

@SvenDowideit
Member

https://github.com/bradfitz/docker/issues/ is the preferred solution to the use case.

@bfirsh
Member
bfirsh commented May 26, 2014

It'll be great to get that included, but don't we need something in the meantime? What practical solutions are there right now to get development environments working?

@SvenDowideit
Member

The best solution is to use Volume containers and then share that volume using something like samba. that way you don't get the performance and reliability issues that come with vbox shares, and you solve the problem for all b2d systems - not just vbox based ones, and have a solution that is consistent with any remote Docker Engine.

@bfirsh
Member
bfirsh commented May 27, 2014

Though it isn't possible to share a directory on the host filesystem with a container using that method, is it? That is what you want to do in development without it being impractical.

@1mentat
1mentat commented May 27, 2014

@bfirsh see @SvenDowideit 's comment #284 (comment) for an example workflow. I haven't made it work yet but it seems valid as well as the reasoning.

@jayd3e
jayd3e commented May 29, 2014

@tgross I tried implementing your fix, and I received this error modprobe: module vboxsf not found in modules.dep. I'm obviously not installing the guest additions correctly to the boot2docker vm, but I'm not sure where I'm going wrong.

@jayd3e
jayd3e commented May 29, 2014

@tgross nvm, just got it working!

@tunix
tunix commented May 29, 2014

@SvenDowideit i've been using VBox (+ vagrant) shares for a long time for development purposes and haven't noticed any performance issues. IMHO creating/configuring a Samba share isn't practical and introduces an overhead to the process. I do start & stop my VM's often and cannot afford to go over this process again and again.

@jayd3e
jayd3e commented May 29, 2014

@tunix yeah that's the same conclusion I came to. Creating a new iso is a far easier process imo as well.

@bfirsh
Member
bfirsh commented May 29, 2014

@1mentat as @tunix points out, that method is impractical for development.

docker/docker#4023 is still a way off, so we need to find a solution in the interim or people are going to be stuck using docker-osx.

@sfitts
sfitts commented May 29, 2014

Personally I've just been using the ISO made from this pull. It's a pain to mange remaking it when updates come out, so I'd much prefer if this got merged. However it seems to be stuck in a philosophical debate about the "best" workflow. Which is too bad, since there is no such thing (IMO) and I'd prefer to have options about which I can make my own decisions.

@aidanhs
aidanhs commented May 29, 2014

I'm ok with this not being merged, but it'd be nice for up-to-date iso's being posted on this issue so they can be used...

@sfitts
sfitts commented May 29, 2014

@aidanhs that does seem like a reasonable middle ground.

@jayd3e
jayd3e commented May 29, 2014

So I might not have all of the necessary context needed to argue either way, but my take on this, is that if docker supports a feature, it should be made available to all platforms, including OSX. Docker supports shared volumes, so why wouldn't it be possible on OSX?

@steeve
Contributor
steeve commented May 29, 2014

hey folks, i was away for a long time.
anyway, as said before, I will first rebase the PR to master, and then merge it.

HOWEVER, the modules won't be loaded automatically. At least for now, and I'll make sure the doc reflects this properly.

@jayd3e
jayd3e commented May 29, 2014

@steeve so to load the modules, it would just require a VBoxManage command correct?

@tgross
tgross commented May 29, 2014

@aidanhs said:

I'm ok with this not being merged, but it'd be nice for up-to-date iso's being posted on this issue so they can be used

@jayd3e said:

Docker supports shared volumes, so why wouldn't it be possible on OSX?

The primary trouble with this, and the reason the developers are avoiding using VirtualBox guest additions as a solution (hopefully I'm not putting words in their mouths here) is that different versions of VirtualBox require different versions of the guest additions. So to be safe you'd need an iso for every version folks are likely to have of VirtualBox. Or you end up tracking the releases of VirtualBox, which probably isn't a solution the developers would care for either.

If it were up to me I'd post up-to-date instructions for baking the ISO in the "workarounds" section and then look for docker/docker#4023 to land. But I do agree it's a bit frustrating that the "anointed" way of using Docker on OS X doesn't support an important piece of the functionality out of the box.

@steeve
Contributor
steeve commented May 29, 2014

@jayd3e just as in the first message in the PR, yes

@steeve
Contributor
steeve commented May 29, 2014

Well, the real issue at hand is that volumes are not the "docker way" of doing things. Rather, people should use data containers. That's the prefered solution.

However, we feel that not having them is a big pain for the users, hence this solution. The reason it's not "on" by default is that we don't want to imply this is the only way to do it. It's more about solving the pain, really.

@sfitts
sfitts commented May 29, 2014

I think that part of the problem is that this feature is being used by different parts of the community for different reasons.

On OSX the only reason I know of to use VBox shared folders is to support volume mapping of a Docker container "directly" to the OSX file system. This is necessary because the Docker daemon runs inside VBox and only has access to the VBox file system.

On Windows there is the added issue that there is no native Docker client. This means that if you try to process a Dockerfile which contains ADD statements, it only has access to the VBox file system. So shared folders can be used to work around this issue and allow the docker client (which has to run inside VBox) to work essentially the same as it does on Linux and OSX (where the native client has direct FS access).

It turns out that volume mapping a container directly to the native FS has some downsides and so it has fallen out of favor. The currently preferred approach is to use "volume containers". My concern is that in discarding the volume mapping bath water we are also tossing the fix for a lack of a native Windows client (which I view as a Docker deficiancy). I understand how volume container can be used to solve this problem as well, but doing so requires changes to the overall development workflow which are non-trivial (at least in our environment).

So for those of us on Windows this is more than just a desire to use a "non docker way" feature. It is allowing us to actually use Docker productively on our platform (without requiring changes to the way everyone here builds software).

@jayd3e
jayd3e commented May 29, 2014

@steeve Data containers totally makes sense for a few use-cases that shared volumes are used for. However when it comes to using docker for development, volumes are completely necessary. For example, if I want to develop in and run my app inside of a docker environment(similar to the way you would use vagrant), then volumes seems like the only feasible way to do that.

@sfitts beat me to it, it seems.

@tunix
tunix commented May 29, 2014

Since this is a blocker for me to use docker, I gave a chance to CoreOS today. Mounting works fine if you attach a volume which is on the box. As it works with Vagrant and actually shares the Vagrantfile dir with the container I'm good to go. Just wanted to share so that others may try as well.

@steeve
Contributor
steeve commented May 29, 2014

@jayd3e it's really a debate to have with the Docker team, but indeed it is an open question. We've discussed this subject with the Docker team, and they have some nice ideas up their sleeves, which won't require shared volumes, and make everybody happy, I hope.

In the mean time, vboxsf it is :)

@sfitts
sfitts commented May 29, 2014

@steeve beat me to the punch as I was writing my somewhat longwinded reply. However, it emphasizes my point fairly directly. For us the shared folders are the only solution that gives us a reasonable development workflow. Moving to a system where all of our source code lives in volume containers just isn't feasible.

@steeve do these solutions include a native client for Windows? Because that's the only thing preventing me from ditching vboxsf.

@sfitts
sfitts commented May 29, 2014

Sounds like this is getting merged, so that's great. I have no issue with having to enable the feature when we switch to a new ISO (though boot2docker-cli "init" option to do so automatically wouldn't be frowned on either ;) ).

@jayd3e
jayd3e commented May 29, 2014

@sfitts ha! +1

@crosbymichael
Contributor

The boot2docker iso is really easy to build yourself with this patch........

@sfitts
sfitts commented May 29, 2014

@crosbymichael no argument here -- as I mentioned above, that's what I'm doing now. Just be easier if I didn't have to (what can I say, I'm a lazy developer, so I'm always looking for easier). So I'm glad it will be merged.

@1mentat
1mentat commented May 29, 2014

I'm not sure exactly what development flow people are objecting to volumes for. You mount the volume on your development machine using samba, use that as a working directory to check out files, do your work or testing facilitated by the application and support containers then check in changes.

I'd also appreciate people giving others contributing to this discussion a "generous reading". If you have objections to it being "impractical for development", specify them succinctly and leave off the personal bits. I'm happy to (again) put together the step by step directions that actually work, but I need to know what the problems are.

@steeve
Contributor
steeve commented May 29, 2014

Rebased and updated the PR.

@sfitts
sfitts commented May 29, 2014

@1mentat for starters, apologies if anything I've said came off as a personal attack, it certainly wasn't meant that way. I sincerely believe that when it comes to development workflow/style/approach we are talking about highly subjective things and what might work fine for one organization may fail miserably in another.

I think I understand the steps involved in using volume containers for development and I will freely admit that my "objections" are not based on any of the mechanics not working. They work fine. Where they fail is when I try to apply them to my organization's development team. So it's hard for me to state succinct, objective reasons why it doesn't work for us. All of our reasons are subjective and boil down to the fact that I need to add Docker to our tool chain transparently and without this solution I can't do that on Windows (for reasons that I outlined above).

@steeve thanks much!

@1mentat
1mentat commented May 29, 2014

@sfitts My only interest is trying to get something that works in whichever situation is necessary and ideally secondarily something that's supported. I'm trying to help and bring to light the merits of different approaches and "it just doesn't work for me except this specific way" doesn't help me bridge any gaps of understanding.

I ended up here trying to get packer.io working with docker builds on OS X. The proposed change of workflow for that is a significant code change to packer which I think will not have much traction with the dev.

There are, more broadly, a bunch of things that don't work cleanly with VBox being managed through the script including port sharing (at least when I last looked.) I tend to agree that if this the official way to do docker without being on native linux it's got a long way to go for standard workflows people are using on linux (regardless of whether they "should be"). Still, I see the elegance of the volume approach as being able to work local and non-local which was why I was bringing it to people's attention even though my initial reaction was "I can't work like that" too.

@jayd3e
jayd3e commented May 30, 2014

So I'm a bit confused. Let's say I want to use this branch right meow, and use boot2docker as though it includes the guest additions out of the box, how would I go about doing that? Atm I'm using @tgross's method as shown above, but it's annoying b/c it needs to download the entire boot2docker image. From what I can tell, there should be a way that I can create a boot2docker iso, and distribute that to my team. Then using a few commands, somehow tell boot2docker to boot up its VM using the iso. Then I should be able to share folders by issuing VBoxManage commands, no? I guess I'm looking for a little instruction on the shortest path to install boot2docker using this new branch. Thanks in advance.

@tgross
tgross commented May 30, 2014

The output of the build_docker.sh script in the gist I posted should be an iso file you can share between anyone using the same version of VirtualBox. You then drop that iso in ~/.boot2docker and boot2docker will use it. You can modify the boot2docker script with the items in my comment #284 (comment) if you want to turn on the shared folders automatically at boot.

@jayd3e
jayd3e commented May 30, 2014

@tgross ok awesome, so the boot2docker repo does two things. It provides a cli to install/interact with the VM running docker, AND it also able to generate the boot2docker.iso correct? Your Dockerfile and build_docker.sh file just streamline the process of creating an iso with guest additions, no? This pull request is adding guest additions permanently. So iso builds from now on, will include guest additions, correct?

@tgross
tgross commented May 30, 2014

Yes, but it doesn't turn anything on. You'll still need to add the folders you want to share with the TinyCore guest, do the modprobe vboxsf, etc.

@jayd3e
jayd3e commented May 30, 2014

Cool, makes sense.

@jayd3e
jayd3e commented May 30, 2014

@tgross so using your gist as you mentioned verbatim, I'm now seeing this really odd stalling issue. For example, calling docker version will output:

jayd3e ~ $ docker version
Client version: 0.11.1
Client API version: 1.11
Go version (client): go1.2.1
Git commit (client): fb99f99

Then stall. About a minute later, 2014/05/30 09:15:18 Get http://localhost:4243/v1.11/version: EOF is outputted. My full process was:

git clone https://gist.github.com/ad9892dcc86bee922772.git
cd ad9892dcc86bee922772
sh build_docker.sh
cp boot2docker.iso ~/.boot2docker/boot2docker.iso
boot2docker stop
# optionally called the necessary shared folders commands here
boot2docker start
@tgross
tgross commented May 30, 2014

I think at one point I may have run into something similar and ended up doing a docker cp of the iso file out of the final container instead. I'll see if I can verify that (probably not till later tonight or tomorrow morning) and then update the instructions if that's the case.

@steeve
Contributor
steeve commented Jun 4, 2014

note that when using the latest version, running the container cats the iso on stdout, see BUILD.md

@SvenDowideit
Member

wow, thankyou for the stat - proportionally - vs 120k downloads in May, thats a tiny number - I'm also very -1 on adding vbox specifc tooling - vbox is only one of the many different virtualisation (and not) systems that boot2docker runs on.

Now that the installation and setup works most of the time, I'm spending time working on Docker based solutions - the samba container I made is one very effective way to work today.

@c4milo
c4milo commented Jun 27, 2014

@SvenDowideit @tianon the fact here is that boot2docker does not fully work out of the box in OSX. Including guest additions is a pretty fairly workaround.

@mattes
Contributor
mattes commented Jun 27, 2014

@SvenDowideit are you a linux or mac user?

Anyway, I will keep updating the .iso file as long as there is no solution (from docker itself) that fits into my workflow.

@sfitts
sfitts commented Jun 27, 2014

@SvenDowideit while VBox may be one of the many virtualization systems that is supported, for those of us on WIndows it is positioned as the primary solution. The only problem is that since Docker currently doesn't provide a native Docker client for Windows there are many Dockerfiles that won't build correctly without some form of host file system access.

It's great that you've got the samba approach and it works well for you. I'd just like an alternative that works well for us (samba doesn't). Support for guest additions provides us with an overall Docker workflow on Windows that is identical to what we have on Linux, which is why I would love to see this merged. I guess I'm a bit perplexed as to the force behind the pushback. As it stands use of this feature is entirely optional and it really helps some of us out of a jam (tiny in number though we may be).

@sfitts
sfitts commented Jun 27, 2014

@mattes Thanks -- it is very much appreciated

@mattes mattes referenced this pull request in boot2docker/boot2docker-cli Jun 27, 2014
Open

boot2docker download <url> #171

@christianrondeau

I had a very hard time getting started with Docker on Windows because of that (http://stackoverflow.com/questions/24196956/how-to-deploy-dockerfile-and-application-files-to-boot2docker)

Putting aside performance concerns (which I didn't experience myself), being able to 1) checkout and work on Windows, and when needed spawn a Docker container without having to first copy my project files and 2) Reduce the amount of steps needed to get someone else to use and learn Docker on an existing solution makes it worth potential penalties.

In any case, one can still use Samba and not mount any file share.

I believe it would make a big difference in the learning curve.

Side note: thank you @mattes for filling that gap in the meantime.

@sfitts
sfitts commented Jun 27, 2014

@christianrondeau -- your experience mirrors our own.

Since we only use shared folders so the docker client (running in VBox) can have access to host files during the building of an image any overhead is negligible. Once the images are built and the containers are running we are using volume containers only for storage.

@harrykao

FWIW, I'm with guest additions camp. I've been using @mattes ISO (thanks for that!) because I don't think the samba approach is suitable for us for the reasons I mentioned above.

@luebken
luebken commented Jun 27, 2014

+1 for an immediate solution like @mattes suggested:
boot2docker download vbox-guest-additions

For my development @mattes ISO works great. And making it more accessible would help people getting started. You could insert a disclaimer with the drawbacks.

@jayd3e
jayd3e commented Jun 27, 2014

@mattes your solution worked great for me as well. I have one question, how would I go about getting shared volumes to work with NFS? I'm running into some speed issues on a larger project, and I need something faster like NFS. I feel like I've read everything about this topic, and have still come out confused.

@wavded
wavded commented Jun 30, 2014

I am +1 for an "opt-in" vbox guest additions (w/ warnings: its slow, don't use in production.. yada yada). It's convenient enough as this thread shows and could be replaced with something better when that arises. It honestly one of the first things I looked for after getting setup on my Mac. Incredibly helpful for development.

@xbeta
xbeta commented Jul 2, 2014

👍 This thread is tl;dr for me, but I think we really should opt-in for vbox guest additions for mounting volume from mac box to the containers

@alex-zige

I'm having problem with v1.1.0 with the previous iso.
client and server don't have same version (client : 1.13, server: 1.12)
do you have iso that works with 1.1.0 by any chance?

@mattes
Contributor
mattes commented Jul 7, 2014

The latest boot2docker v1.1.0 is now available:
http://static.dockerfiles.io/boot2docker-v1.1.0-virtualbox-guest-additions-v4.3.12.iso

$ docker version
Client version: 1.1.0
Client API version: 1.13
Go version (client): go1.2.1
Git commit (client): 79812e3
Server version: 1.1.0
Server API version: 1.13
Go version (server): go1.2.1
Git commit (server): 79812000

$ boot2docker version
Client version: v1.1.0
Git commit: 7e20d36
@alex-zige

awesome! thanks @mattes

@larrycai
larrycai commented Jul 8, 2014

I guess the 1.1.0 link shall be
http://static.dockerfiles.io/boot2docker-v1.1.0-virtualbox-guest-additions-v4.3.12.iso

On Tue, Jul 8, 2014 at 7:28 AM, Alex Z. Li notifications@github.com wrote:

awesome! thanks @mattes https://github.com/mattes


Reply to this email directly or view it on GitHub
#284 (comment)
.

True software development embraces consistent inconsistency.
blog: http://larrycaiyu.com/blog (en), http://larrycaiyu.com (chinese)

@mattes
Contributor
mattes commented Jul 8, 2014

@larrycai oh, where did you find the old link?

@larrycai
larrycai commented Jul 8, 2014

@mattes , weird, I saw the link was incorrect in gmail (auto notification)
(see attachment), while it looks correct in github

On Tue, Jul 8, 2014 at 10:31 AM, Matthias Kadenbach <
notifications@github.com> wrote:

@larrycai https://github.com/larrycai oh, where did you find the old
link?


Reply to this email directly or view it on GitHub
#284 (comment)
.

True software development embraces consistent inconsistency.
blog: http://larrycaiyu.com/blog (en), http://larrycaiyu.com (chinese)

@mattes
Contributor
mattes commented Jul 8, 2014

Ah it probably makes sense. At first I typed the wrong URL here and corrected it immediately afterwards. But Email notifications were quicker I guess. ;-)

@mitar
mitar commented Jul 11, 2014

+1

@mitar
mitar commented Jul 13, 2014

I am using @mattes VirtualBox Guest Additions image. It seems I have an issue with speaks against using it (but maybe the same would happen with NFS):

I discovered an issue with using VirtualBox Guest Additions and nginx. I am using volumes to map my Wordpress blog into the container so that I can develop easily. And I use nginx to server PHP and static files. I discovered that for static files if I change them outside the container, nginx still servers the old file. File inside the container changes, only nginx servers the old version. After some debugging I discovered that sendfile option was the reason. It was turned on and it seems it does not work well together with all this VirtualBox sharing and volume mapping combination. After I disabled sendfile nginx servers the latest version of the file.

@mattes
Contributor
mattes commented Jul 13, 2014

@mitar

I discovered that for static files if I change them outside the container
File inside the container changes

nginx still servers the old file

I found this: http://www.reddit.com/r/linux/comments/12ssxq/i_ran_into_a_really_strange_issue_with_nginx_and/c6xvzv3. What does sendfile do? It's turned off per default.

@mitar
mitar commented Jul 13, 2014

I is a system call to send files to HTTP sockets efficiently. On Debian (which I use as a base for my images) it is on by default.

@mitar
mitar commented Jul 24, 2014

It seems symlinks are not supported as well? If my Mac OS X directory has symlinks and I map that into the container and try to access it I get "Too many levels of symbolic links". This happens even if I try to access the symlink through /Users shared directory directly inside boot2docker VM (using boot2dockere ssh).

@p3k
p3k commented Jul 26, 2014

👍

@keymon
keymon commented Jul 27, 2014

👍 it is an obvious win to ease development workflows.

As @mattes suggests, boot2docker can provide a easy and scriptable way to install the vbox additions.

@shykes
shykes commented Jul 28, 2014

Hi all, this has become one of the top issues for people using Docker on Mac and Windows, period. So I'm going to escalate it to a Docker-wide issue, and make a call taking in consideration the pros and cons for the whole platform. @SvenDowideit @steeve @tianon I hope you won't mind.

Here's what everyone seems to agree on:

  • A lot of people install Docker on their Mac and Windows machines. Most of them install boot2docker as part of this, because that's the official installation method for those platforms.
  • Many people expect docker run -v /host:/container to work on their Docker installation, even if that's a Mac or Windows machine backed by boot2docker. Currently, it does not work as expected.
  • The ideal solution is to solve this in Docker itself, with built-in filesystem sync between client and server. This is ideal because it works exactly the same way on 100% of Docker installations, and is not subject to variations and quirks in hypervisor and host system configuration.
  • This ideal solution is work in progress [1]. While it's being developed, if there's a stopgap solution which can be implemented faster, which 1) Makes life easier for a large number of Docker users, 2) doesn't make it harder or longer to implement the ideal solution, and 3) can be easily deprecated later in favor of the ideal solution - then we should implement it.
  • One possible stopgap is to install vbox guest additions, and configure the VM so that the current user's home directory on the host is shared at the same path in the VM. This will allow docker run -v /host:/container to work as expected, as long as /host is a path inside the current user's home directory. That is typically the case for the most common use case, which is "interactive development" with the project source code mounted into the container.
  • The advantages of this stopgap are 1) they are relatively easy to add. If we agree we could probably release them with 1.2 next week. 2) they are forward-compatible. In a future version of Docker, -v /host:/container from a remote client will almost certainly change to always share the contents of the client-side host. When this happens, the stopgap can be safely retired, and the behavior will not break people's expectations.
  • Possible disadvantages of this stopgap: 1) vbox guest additions have a reputation of being buggy and slow. It might create new problems for boot2docker users. 2) it might make the boot2docker install and upgrade process more difficult. If that is the case, we should not merge.

Here are my questions to all of you:

1: do you disagree with anything I stated here, or do you feel I forgot something?

2: how do you feel about the disadvantages? Can they be solved or mitigated? Do you feel the the advantages are worth the tradeoff?

@thaJeztah

@shyke 👍 for a nice summary. Regarding the downside of Guest additions; maybe some way to inform users that performance may be suboptimal and point to some documentation to explain on the work that is in progress?

@mitar
mitar commented Jul 28, 2014

So I was testing using vbox guest additions for development on Mac OS X and the biggest issue is that symlinks do not work at all. You cannot create symlinks inside vbox mounted guest additions. You cannot read symlinks made outside on host.

In additiona, mmap does not work. If you have a program using mmap to read files (nginx), if file is modified, mmap does not show this and program still shows old data.

@tianon
Contributor
tianon commented Jul 28, 2014

I don't think the disadvantages can be mitigated, since they're fundamental problems in the virtualbox driver (ie, how notoriously unreliable and slow the driver is), but I think it'd be an acceptable stopgap for now given the rest of the issues you've described, despite how much I'm -1 on the idea.

@sfitts
sfitts commented Jul 28, 2014

@shykes for starters, thanks for escalating this.

  1. I don't disagree with anything you said. There are some additional concerns for Windows users beyond the bind mounting use case, but I understand that Windows users are a minority.

  2. For me the alternative is that Docker is essentially unusable. So personally I'll take the risk of slow and buggy (neither of which I've personally observed) for a usable development tool (one that is rapidly becoming a cornerstone of our development process).

I'm sure there are other risks/downsides, but IMO this is a classic case of not letting the perfect become the enemy of the good enough.

@bfirsh bfirsh referenced this pull request in boot2docker/boot2docker-cli Jul 28, 2014
Open

Automatically mount home directory #202

@mattes
Contributor
mattes commented Jul 28, 2014

I am still +1 for offering an official boot2docker.iso with virtualbox guest additions enabled. I maintain an unoffcial .iso here.

If an official .iso isn't something everybody can agree on, why not implement this:
boot2docker download url ?

@bfirsh
Member
bfirsh commented Jul 28, 2014

To address the disadvantages:

  1. I have not experienced any significant problems with vbox shares after using them for several years. This will make Docker dramatically better for 99% of users. For the 1% who do have issues, they can work out a custom solution or we could suggest a better performing/more fiddly solution (e.g. samba shares).

  2. I can't think of anything that will make the boot2docker install process more complex from a user's point of view. We'll need to think about how to mount directories (boot2docker/boot2docker-cli#202) but that's a separate problem.

@larrycai

I use windows vbox iso, thx to @mattes though there is one problem for me, as @mitar said, the changes in shared folder will not be noticed in docker container, it is quite tricky for starters, please add this notice for vbox edition.

I hope we can add one environment below like into boot2docker

BOOT2DOCKER_SHARED_FOLDER=vbox|standard|...

This can make vbox is optional, and user can switch to different version when he wants.

  1. During installation phase, it can be optional in GUI, the selection is put into this variable.
  2. in upgrade, this environment can be used to choose the real target source by boot2docker download command
@SvenDowideit
Member

I have always had a few other concerns.

VirtualBox is not the only existing user of boot2docker

We have users that use all the virtualisation solutions that exist, and also run directly on bare hardware. Adding the VBox extensions not only doesn't help them, it adds complexities, and a demand to add the other drivers.

mitigation

yeah, none. its not a good problem.

(I wrote this before i noticed the possibility I expand on below...)

security - what are you choosing to share with the vm&random docker containers

Even if you restrict to any subdirs /Users/sven, you're auto-handing out the user's .ssh, and any secret documents.

the risk is that we give a container the ability to do things that then lead to eventually giving a sneaky container root / admin on the OS X / Windows box. (imagine a rails image that helpfully auto-starts the db and other containers by getting you to pass it a docker socket, and then at some stage puts some extra sauce into your .bashrc, that later makes its way into your sudo env.

mitigation possibility

Instead of using anything under the User's dir, we add a /Users/sven/docker_share dir. This can be implemented either by mounting the Samba volume container using something like svendowideit/samba to that location,

or perhaps mounting that dir inside the vm using cifs? (I only tried the containerised version - anyone want to confirm the obvious solution we've forgotten??) - I was able to mount -t cifs //osx/Docker, but not as guest, so some extra magic will be needed.

So what I just tried, is:

make a new OS X Share /Users/sven/Docker, then boot2docker ssh and run

sudo mkdir /mnt/Docker
sudo mount -v -t cifs //10.10.10.14/Docker /mnt/Docker -o 'username=sven,password=yeah-no,nounix,sec=ntlmssp,noperm,uid=1000,gid=100'

I did some investigation into scripting the share creation a few months ago, and it worked ok, but I don't recal if i needed to deal with the user&password issue.

the Making and attaching to the share would be handled by the boot2docker tool, and then the icing would be to amend the docker client to make it clear to the user when they are using the Docker hosts's FS, and when they are using the Docker client's FS.

making it obvious to the Docker client user which FS is being used

How to we make sure they know when they are using the Docker client's FS, and when they are using the Docker Host's FS. This is not just an issue for boot2docker, its an issue for all remote docker daemons - tho we sidestep this atm, but not explicitly dealing with it at all.

@SvenDowideit
Member

@sfitts Windows users are not in the minority. They are slightly quieter though.

please, speak up with your concerns and issues, otherwise its hard to try to account for them :)

@sfitts
sfitts commented Jul 29, 2014

@SvenDowideit sorry, I didn't want to get into rehashing old stuff (I've posted about this a couple of times). Our primary issue is the lack of a native Windows client for Docker. If one existed then we wouldn't be using this workaround (we don't use bind mounting of volumes in any of our containers).

What we do today is use a docker shell script (we use Git-Bash on Windows) which launches the Linux docker client via boot2docker ssh. The only thing that stops this from being seamless is the fact that those commands can see only the VBox filesystem. Using this workaround addresses that issue. So I can cd into some sub-directory of my home, run docker build . and it all just works.

The only reasonable alternative solution that I've seen proposed is your samba based approach. Unfortunately this doesn't work for us. Not for any technical or objective reason, but due mostly to purely subjective concerns. We simply aren't ready to treat Docker as our primary file system during development. Maybe eventually, but not yet.

My personal preference would be for a native Windows client for Docker, but I've seen no sign that this is planned or even on the horizon. In the meantime we're using this solution because it works for us. Since we only use it on personal development machines many of the concerns cited here do not apply to us (which isn't to say they aren't real, we just don't share them).

If you'd like to explore any of this in more detail I'd be happy to do so directly (just drop me an email).

@SvenDowideit
Member

@sfitts please re-read :)

I just noticed a way to share a directory from your windows box to the Docker vm (and thats what I talk about above).

we all agree that a windows native Docker client is a big deal - in fact, I think its a bigger issue than the -v bind mount one.

@sfitts
sfitts commented Jul 29, 2014

@SvenDowideit -- sorry, given the references to OSX and the fact that this doesn't preserve the underlying host FS structure (something you need to make the use of the Linux docker client work as I describe above), it wasn't immediately obvious how this applied to my situation. But I'll see if I can tweak it to make it work for us.

@aheissenberger
Contributor

What I found independed the Solution (nfs, vbox) I tried, none of them supports "inotify" which breaks most of the tools who automatically rebuild stuff. I hope the "new" solution docker ist working on will provide the kind of signals.

@nathanleclaire
Contributor

@SvenDowideit raises a good point with the security concern (don't just share your SSH keys willy nilly etc.).

What if we gave users option to set up shared folder themselves with boot2docker share command?

Then, if you don't care about the security implications of mounting ~ in the VM, you can do:

boot2docker share ~

and docker run -v /host:/container will "Just Work" anywhere within your home directory.

Or if you prefer, you can set up a little "workspace" folder for doing Docker work that involves this usage of -v:

boot2docker share ~/docker-workspace

Then, you aren't forced into sharing secrets or anything that you haven't consciously put into that directory (~ usually gets littered with dotfiles etc.).

You wouldn't be forced into doing anything if you don't do it explicitly, so you can use workarounds like a Samba volume container if you like those or they suit your usecase better, and it's just one extra command (on top of boot2docker init etc.) for the users who want convenience over security. Not too much mental overhead. I think you may need to reboot the VM after adding a shared folder, though, so there's that.

@SvenDowideit
Member

I'm sorry @nathanleclaire but if you make users type a choice between a short line, and a long line, you've effectively defaulted to the short one - and then you get on your high horse and tell them it was their fault.

add to this that boot2docker is intended to require no user action to make the best way work.

the biggest group that we should think of first, are the ones that don't and likely will never understand the risks involved, and will happily follow anything they can cut and paste from some place on the internet....

@mitar
mitar commented Jul 31, 2014

I don't understand the issue of mounting home directory into boot2docker. Isn't it exactly the same on Linux? Running container on Linux which has access to Docker socket can be used to get SSH keys from home directory of the user.

@aheissenberger
Contributor

@mitar in a native docker enviroment docker uses a linux specific api to map the subdirectory in a secure way into a container. There is no kind of "sharing" based on something like nfs, cifs or vbox involved.

@mitar
mitar commented Jul 31, 2014

Also in boot2docker (at least in existing images with VBox additions) this is done the same. So called "sharing" is used to map Mac OS X users home directory inside Linux host running inside Virtualbox, and then Linux specific API is used to map subdirectories inside containers. I really do not see any difference. Containers without Docker socket access inside VBox additions enabled boot2docker cannot access SSH keys in exactly the same way as on Linux machine.

@keymon
keymon commented Jul 31, 2014

@mitar is right, the only risk is that boot2docker iso contains malicious code... but if the official boot2docker.iso includes the vbox modules, we assume that is OK because the user already boot2docker-cli the host (so it has access to the /Users already)... and then we assume that you trust boot2docker.

That is why it is important that boot2docker provide a way to get the vbox drivers.

@SvenDowideit
Member

no, @mitar is wrong. the risk is essentially that by sharing the Desktop user's home dir, we provide clever containers the keys to their servers, and the keys to building and releaseing software signed using their certificates. - ie, that a container uses the ~/.ssh and ~/.gpg` dir's - or plays with their bookmarks and browser addins to download an exploit next time they goto their bank.

Security is about layers, and the extra layer that running boot2docker in a virtual machine allows us to protect the user.

the vbox modules don't actually achieve anything that the approach I'm going to take for 1.3.0 does, except limit our ability to not increase the security risks.

and Yes, using other tools flaws to say its ok for Boot2docker to essentially get not only root on the VM, but on your Windows or OSX box, is hard to justify.

Boot2Docker needs to be safe for users that will never know what the risks are

@mitar
mitar commented Aug 1, 2014

the risk is essentially that by sharing the Desktop user's home dir, we provide clever containers the keys to their servers

The only thing I am saying is that clever containers can access your keys on your Linux-only machine as well. If am using my Linux desktop PC with SSH keys as a host for Docker and I am developing and I run a clever container, such container can access my SSH key as well (through misusing Docker socket, etc.).

So, if it is OK for Linux-based developers, why it cannot be good enough for Mac OS X based developers? I didn't know that one of boot2docker design goals was to increase security more than what native Linux users would have. Maybe this is the goal. But I think the main goal is that Mac OS X (and Windows) developers would be able to use and develop with Docker at all. And not that they would have more security.

@mitar
mitar commented Aug 1, 2014

Boot2Docker needs to be safe for users that will never know what the risks are

It is exactly the same security concern as running Docker on native Linux desktops.

@SvenDowideit
Member

no, its not the same risk, as the user group is not the same. Also, those that have read a little more about Docker security, have read that its safer to contain your Docker daemon inside a VM - which Boot2Docker does.

Running Boot2Docker on OSX is like running Boot2Docker on Linux (which I do), safer.

Its not OK / good enough for Linux developers - its a problem on Linux that needs a safer solution too.
I have no intention of just passing on risks that occur on one platform onto another where its not necessary.

And if you didn't know that our goal for both Docker and Boot2Docker is to iteratively reduce the security risks to all Docker users, you do now.

@mitar
mitar commented Aug 1, 2014

no, its not the same risk, as the user group is not the same.

Why not? Developers on Mac OS X are less technical savvy than those on Linux?

If you want to provide boot2docker also for Linux, then why Docker is not suggesting boot2docker on Linux as well? Why in boot2docker installation instructions there is no mention of how to use and install it on Linux?

I am saying that you might be right that boot2docker should become a standard way of running Docker on desktop machines. But currently it is presented as a way to get Docker experience on Mac OS X and Windows, and that Docker experience should be at least as such as it is running Docker directly on Linux. We could go further and make it even better (safer), but let's first get to the phase that it is at least as such.

@sylvinus
sylvinus commented Aug 1, 2014

Thanks @shykes for raising the priority of this! Definitely our n.1 issue too.

I strongly prefer a forward-compatible, temporary solution, albeit with some known issues (symlinks?), than the current alternative which is for us not to use boot2docker at all in our development workflow and stick to bloated VMs.

@aanand aanand referenced this pull request in noplay/docker-osx Aug 1, 2014
Open

Refuse to run as superuser #35

@SvenDowideit
Member

I think its important to remember that the users of a trivial to install suite of tools like Boot2Docker have very wide ranges in knowledge and interest, and that its our responsibility as contributors to these tools, to ensure a default level of security that assumes that users of the suite are not exposed to risks that they are either unaware of, or would not want to be distracted by.

Boot2Docker has come to the point where its possible for someone to tell their non-technical user to install it, and then run a very simple and potentially misleading commands.

By way of explanation, please consider these scenarios:

  • Someone new to the world of computers wants to help out on a project that has a Dockerfile, and instructions how to use it. They install Boot2Docker and do so, totally unaware that there could be any risks - they are after all only helping work on project X. Is it fair to them that we default to sharing their tax information, their Mothers tax information, and who knows what other personal data.
  • A non-computing professional uses a tool that is delivered using Docker, and uses Boot2Docker for installation on non-Linux systems - again, the same risks to both that user, and any other users of the OSX / Windows computers.
  • A corporation considers the use of Boot2Docker to deploy its business related systems, client side, whatever, and their Network Admins need to ensure that the confidential information on those computers is not less safe by installing Boot2Docker and therefore Docker.

In all these quite reasonable use cases for Boot2Docker, we have a situation where defaulting to a newly created Subdirectory prevents unrealised harm, whereas defaulting to sharing either the entire filesystem, or the users home dir causes un-necessary risks, or worse means that Boot2Docker cannot be used.

Meanwhile, by choosing to implement the Desktop file sharing to default to a safe ~/docker-share , that doesn't stop users who think they know what they are doing (I'm avoiding judging if its true or not) from changing the default.

Yes, I do think that OS X and Windows users are a much broader range of knowledge and experience than Linux Developers - and by delivering an all in one GUI installation tool, we need to be very conscious that our users are not only Developers.

@mitar
mitar commented Aug 3, 2014

What about an easy non-default installation option in the wizard? So a checkbox "share all /Users" or share a "docker-share" directory, with default the latter?

@silenceisgolden

Just stumbled onto this thread while bumping into this problem so pardon any ignorance:

@SvenDowideit is making an important point on security which should immediately rule out any sharing of the home directory. However that shouldn't stop users from using a boot2docker share-like command to allow for configurability.

An option would be to have the docker directory be ~/docker_dev and it automatically be shared into the boot2docker configuration (share might seem odd to non-knowledgable users, and the problem seems to stem around dev files) and then have a command available that would allow the directory to change. This could be boot2docker share or maybe even boot2docker devdir and the script would gracefully error if the user tried to share/mount/include a home directory. I think this solves a majority of the problems while still allowing the user, IT admin, dev-ops person or whoever else to still have configuration options that they might be looking for.

Edit: And thanks a whole heck of a ton @mattes for the .iso.

@mitar
mitar commented Aug 4, 2014

I think what is important is that volume mounting command on Linux works the same on Mac OS X or Windows. If I say:

docker run -v /Users/user/docker_dev/files:/files my_image

This should work. So docker_dev should be added under /Username/user inside boot2docker.

@mitar
mitar commented Aug 4, 2014

(For Mac OS X, wouldn't it be better if it would be under ~/Library? Like ~/Library/Application Support/Docker? Instead of docker_dev in home directory?)

@dgageot
dgageot commented Aug 4, 2014

This thread has become so long to read... It'd be funny if volume mounting on OSX was not a pain in the ass.

Couldn't we give a try to vbox guest additions and see if it makes users happy? We've tried the samba way and it doesn't make users happy. It is elegantly using a container to solve the problem, it is secure and performant but let's face it, users hate it. Sorry if that's harsh but that's the reaction of every user I saw trying to use it.

I want to stay positive, a good solution will be found!

@silenceisgolden

@mitar I'm not sure the ~/Library works. I think enough people are used to entering the command line at ~ that a subdirectory in there would work just fine, and like you mentioned it should normalize the location between different operating systems.

@steeve
Contributor
steeve commented Aug 4, 2014

Hey folks. I think I'm gonna update and merge this PR. It won't load the module by default, but it's there and judging by the length of this PR, I think people will appreciate it.

@tianon @SvenDowideit

@nathanleclaire
Contributor

First off: Everyone, @SvenDowideit is very correct. You really do not want to share your SSH keys, other secrets, and essentially anything in your home directory with containers running arbitrary images. Arbitrary images are from the Internet and it is important to treat the public Internet as if everyone on it is actively trying to kill you (steal your bank passwords, etc.).

The tradeoff between security and usability is 100% worth it here: it'd be very convenient to log into any account that you have using a password of "password" but that doesn't mean it's a good idea.

Meanwhile, by choosing to implement the Desktop file sharing to default to a safe ~/docker-share , that doesn't stop users who think they know what they are doing (I'm avoiding judging if its true or not) from changing the default.

So Sven, if I understand you correctly, you are in favor of this (~/docker-share mounted where volumes will "just work")? Because I am pretty +1 on this. It seems like a reasonable tradeoff, and personally I'd be happy to do all of my Dockerized work (which involves volumes at least) inside of a pre-prescribed directory.

Additionally I'm starting to come around to the samba container method more for instances where I can control the volume commands. However things where -v is out of your control (e.g. the Docker build scripts) it is still a little annoying. For the shorter/medium term some ideas:

  • Publishing the existing blog post on using samba container method (in particular there is no mention of e.g. ⌘-K to connect to the server which would stop me dead in my tracks if I was just following our existing documentation). Or I could look into merging that post into the official doc. Let me know what you think @SvenDowideit . Additionally:
  • We could consider a boot2docker samba (or better named) command to group the commands to "make it work" into one unified thing? I wonder if perhaps users get lost in the four or so steps to get the samba method working.
@bfirsh
Member
bfirsh commented Aug 4, 2014

To be clear: sharing your home directory with the virtual machine does not mean arbitrary images have access to anything in your home directory. They have access to what you choose to give them access to in your home directory, in the same way that running Docker on Linux works. E.g. this will only give the container access to files in ~/my-project:

$ docker run -v ~/my-project:/code

This is off-topic from VBox guest additions though. We could perhaps discuss the best to set up shares on this issue: boot2docker/boot2docker-cli#202

@aanand
Contributor
aanand commented Aug 4, 2014
@nathanleclaire
Contributor

To be clear: sharing your home directory with the virtual machine does not mean arbitrary images have access to anything in your home directory. They have access to what you choose to give them access to in your home directory, in the same way that running Docker on Linux works.

Sure, but that doesn't stop users from accidentally allowing this with a docker run -v $HOME:/free_secrets command concealed in a run.shscript, or copy-pasted from the Internet by users who aren't familiar with the CLI, etc.

I'll move discussion over to the other issue.

@wavded
wavded commented Aug 5, 2014

Pardon my ignorance but if Docker running on Linux directly allows you to share whatever (what I understand from @bfirsh comment above) and therefore is OK running nasty run.sh scripts, why is this boot2docker's problem? Isn't it more a security issue with Docker itself that should be addressed there and not here?

@SvenDowideit
Member

@steeve no, you are not going to merge this. b2d 1.3.0 will solve it properly, and we do not have time to test all the problems it will cause before 1.2.0 is released.

see boot2docker/boot2docker-cli#202 for the plan.

@SvenDowideit
Member

one particularly scary user-story I told the other day, is when someone installs b2d on their family computer to try out some SW that can be run using it, then days later is finished, and forgets all about it. for the next 5 years, b2d is running (for some auto-start at boot time reason), and therefore is not updated to fix what we missed - then someone else clicks a link in an email that gets around a tls impl issue and hands the magically run container the docker socket

  • yay.

boot2docker is already a tool that can be used by non-developers - and there will be more all the time.

@1mentat
1mentat commented Aug 5, 2014

You cannot protect people who are willing to copy and paste from the
internet. It is outside the info sec concerns of any project.
On Aug 4, 2014 7:16 PM, "Sven Dowideit" notifications@github.com wrote:

one particularly scary user-story I told the other day, is when someone
installs b2d on their family computer to try out some SW that can be run
using it, then days later is finished, and forgets all about it. for the
next 5 years, b2d is running (for some auto-start at boot time reason), and
therefore is not updated to fix what we missed - then someone else clicks a
link in an email that gets around a tls impl issue and hands the magically
run container the docker socket

  • yay.


Reply to this email directly or view it on GitHub
#284 (comment)
.

@mitar
mitar commented Aug 5, 2014

@SvenDowideit, in any computer security discussion, the first thing is to define a threat model. Because, will boot2docker protect users against NSA as well?

@nathanleclaire
Contributor

Pardon my ignorance but if Docker running on Linux directly allows you to share whatever (what I understand from @bfirsh comment above) and therefore is OK running nasty run.sh scripts, why is this boot2docker's problem? Isn't it more a security issue with Docker itself that should be addressed there and not here?

@wavded Well, this is why Sven says he runs boot2docker when working with Docker in Linux as well. It provides an additional layer of security should something wonky happen. Additionally on Linux you have to deliberately add the user to the docker group to run without sudo, on Mac/Windows a lot of this kind of thing is abstracted away from users, thus making them less aware of the risks.

You cannot protect people who are willing to copy and paste from the internet. It is outside the info sec concerns of any project.

@1mentat Sure you can. This is why Facebook attempts to mitigate attacks made by tricking people into copy-pasting malicious JavaScript into their URL bar. Just because someone will always fall for tricks doesn't mean you shouldn't even try. Even people who know better copy-paste commands and code from the Internet from time to time. Not to mention that's not the only attack surface, there are a huge variety of attacks and if a Docker exploit comes out tomorrow we're all going to be very glad we have a VM sitting between Docker and our "real" computer.

in any computer security discussion, the first thing is to define a threat model. Because, will boot2docker protect users against NSA as well?

If only.

Keep in mind everyone that most likely the solution implemented will allow you to share your home directory if you want to, but it won't do that by default. Being vulnerable should be "opt-in" not "opt-out".

@steeve
Contributor
steeve commented Aug 5, 2014

@SvenDowideit alright, closing then.

@steeve steeve closed this Aug 5, 2014
@hrldcpr
hrldcpr commented Aug 5, 2014

Just so other people don't have to scroll around to find it, here is the new issue:

boot2docker/boot2docker-cli#202

@bfirsh
Member
bfirsh commented Aug 5, 2014

I'm pretty sure we're going to need this if we do some kind of directory sharing as described in boot2docker/boot2docker-cli#202.

@mitar
mitar commented Aug 5, 2014

Keep in mind everyone that most likely the solution implemented will allow you to share your home directory if you want to, but it won't do that by default. Being vulnerable should be "opt-in" not "opt-out".

Vulnerable to whom and for what? Again, what is a threat model?

@tianon tianon referenced this pull request Sep 11, 2014
Merged

VirtualBox Guest Additions #534

@bfirsh
Member
bfirsh commented Sep 11, 2014

This has now been reopened as #534. (Just so you all get a notification!)

@gansbrest

VirtualBox Guest Additions are unusable/slow for project with lots of small files ( tested with 17K files ). Is it just me?

I created Hodor github.com/gansbrest/hodor to streamline dev workflow for Mac and Linux. Let me know what you guys think.

@alex-zige

@gansbrest @dduportal Yeah. You are not alone. Had the same problem. :(

@jmreicha

@gansbrest @dduportal is there a workaround for the VBox guest addition horrible performance issue? I haven't looked at hodor yet.

@gansbrest

@jmreicha hodor! ))

@tianon tianon deleted the vboxsf branch Dec 16, 2014
@nathan-zhu

hi, any news for this, i'm use docker1.7 but still have same problem. please help.

@thaJeztah

@nathan-zhu no single solution yet. The performance issue isn't related to Docker itself, just the VBox guest additions. You can find some alternative approaches in the discussion above though, that might help in your situation.

However, the Docker 1.7 "experimental build" offers "Volume Drivers" (see https://github.com/docker/docker/blob/master/experimental/plugins_volume.md), which could potentially open up some possibilities (for example, see docker/docker#13420 (comment))

@mattes
Contributor
mattes commented Jun 30, 2015

@nathan-zhu Check out https://github.com/synack/docker-rsync. It's pretty experimental though.

@gansbrest

@nathan-zhu I guess I still have to recommend Hodor (https://github.com/gansbrest/hodor) for now for fast bidirectional sync through Unison.

@ehernandez-xk

Hi,
What is the status of this? because I have the problem with the following configuration:

Windows 7
I have a custom boot2docker form 1.11.1 version
VirtualBox 5.0.16
Vagrant 1.8.5

Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attemped was:

set -e
mount -t vboxsf -o uid=`id -u docker`,gid=`getent group docker | cut -d: -f3` b5
973a5087 /var/lib/docker/docker_1472079332_51007
mount -t vboxsf -o uid=`id -u docker`,gid=`id -g docker` b5973a5087 /var/lib/doc
ker/docker_1472079332_51007

The error output from the command was:

mount: mounting b5973a5087 on /var/lib/docker/docker_1472079332_51007 failed: Pr
otocol error

Do you have an example to use it on windows? I'm using Vagrant and docker as a provider.

@ehernandez-xk

When I run mountmanually I get this message.

-sh: getent: not found
gid= requires an argument (i.e. gid==<arg>)
mount: mounting vagrant on /vagrant failed: Protocol error
@dduportal
Contributor

Hello @ehernandez-xk !
This is due to a regression in Vagrant, from 1.8.5 until 1.8.5 included:

For now, I strongly recommend you to stay on Vagrant 1.8.1 and VirtualBox 5.0.x line, since Vagrant support of VBox 5.1.x landed on... vagrant 1.8.2...

@ehernandez-xk

Thank you @dduportal

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