New issue

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

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

Already on GitHub? Sign in to your account

VBox guest additions #284

Closed
wants to merge 1 commit into
base: master
from

Conversation

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

This comment has been minimized.

Show comment
Hide comment
@shlomifruchter

shlomifruchter Mar 17, 2014

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

shlomifruchter commented Mar 17, 2014

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

@steeve

This comment has been minimized.

Show comment
Hide comment
@steeve

steeve Mar 17, 2014

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@aheissenberger

aheissenberger Mar 21, 2014

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>]
Contributor

aheissenberger commented Mar 21, 2014

👍 @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 added a commit to cameronmaske/docker-osx that referenced this pull request Mar 26, 2014

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.

@aanand aanand referenced this pull request Mar 27, 2014

Closed

volumes not work #172

@lightsofapollo

This comment has been minimized.

Show comment
Hide comment
@lightsofapollo

lightsofapollo Mar 28, 2014

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 :)

lightsofapollo commented Mar 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@steeve

steeve Mar 28, 2014

Contributor

Can we merge this already guys ?

Contributor

steeve commented Mar 28, 2014

Can we merge this already guys ?

@nsfmc

This comment has been minimized.

Show comment
Hide comment
@nsfmc

nsfmc 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.

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

This comment has been minimized.

Show comment
Hide comment
@steeve

steeve Mar 30, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Mar 30, 2014

Contributor

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¢.

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

This comment has been minimized.

Show comment
Hide comment
@aidanhs

aidanhs Apr 2, 2014

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

aidanhs commented Apr 2, 2014

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

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Apr 2, 2014

Contributor

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

Contributor

tianon commented Apr 2, 2014

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

@hunterloftis

This comment has been minimized.

Show comment
Hide comment

hunterloftis commented Apr 12, 2014

+1

@iwootten

This comment has been minimized.

Show comment
Hide comment
@iwootten

iwootten Apr 14, 2014

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?

iwootten commented Apr 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@steeve

steeve Apr 15, 2014

Contributor

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)

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

This comment has been minimized.

Show comment
Hide comment
@bjaglin

bjaglin Apr 15, 2014

Contributor

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)

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

This comment has been minimized.

Show comment
Hide comment
@TheBigBear

TheBigBear Apr 15, 2014

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?

TheBigBear commented Apr 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bjaglin

bjaglin Apr 15, 2014

Contributor

@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 .
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

This comment has been minimized.

Show comment
Hide comment
@TheBigBear

TheBigBear Apr 15, 2014

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?

TheBigBear commented Apr 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Apr 15, 2014

Contributor

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.

Contributor

SvenDowideit commented Apr 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tunix

tunix 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?

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

This comment has been minimized.

Show comment
Hide comment
@mattes

mattes Apr 16, 2014

Contributor

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

Contributor

mattes commented Apr 16, 2014

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

@TheBigBear

This comment has been minimized.

Show comment
Hide comment
@TheBigBear

TheBigBear Apr 16, 2014

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 commented Apr 16, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TheBigBear

TheBigBear Apr 16, 2014

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/

TheBigBear commented Apr 16, 2014

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

This comment has been minimized.

Show comment
Hide comment
@1mentat

1mentat 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 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

This comment has been minimized.

Show comment
Hide comment
@1mentat

1mentat 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.

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

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Apr 17, 2014

Contributor

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

Contributor

SvenDowideit commented Apr 17, 2014

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

@1mentat

This comment has been minimized.

Show comment
Hide comment
@1mentat

1mentat Apr 17, 2014

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

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

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Apr 17, 2014

Contributor

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.

Contributor

SvenDowideit commented Apr 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@1mentat

1mentat 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.

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

This comment has been minimized.

Show comment
Hide comment
@lazywei

lazywei 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?

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

This comment has been minimized.

Show comment
Hide comment
@TheBigBear

TheBigBear Apr 17, 2014

@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 commented Apr 17, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@TheBigBear

TheBigBear Apr 17, 2014

@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"

TheBigBear commented Apr 17, 2014

@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"
@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar 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?

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

This comment has been minimized.

Show comment
Hide comment
@silenceisgolden

silenceisgolden Aug 4, 2014

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.

silenceisgolden commented Aug 4, 2014

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

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar 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 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

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar 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?)

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

This comment has been minimized.

Show comment
Hide comment
@dgageot

dgageot 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!

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

This comment has been minimized.

Show comment
Hide comment
@silenceisgolden

silenceisgolden Aug 4, 2014

@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.

silenceisgolden commented Aug 4, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@steeve

steeve Aug 4, 2014

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@nathanleclaire

nathanleclaire Aug 4, 2014

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.
Contributor

nathanleclaire commented Aug 4, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bfirsh

bfirsh Aug 4, 2014

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. 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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@aanand
Contributor

aanand commented Aug 4, 2014

@nathanleclaire

This comment has been minimized.

Show comment
Hide comment
@nathanleclaire

nathanleclaire Aug 4, 2014

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.

Contributor

nathanleclaire 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.

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

This comment has been minimized.

Show comment
Hide comment
@wavded

wavded 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?

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

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Aug 5, 2014

Contributor

@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.

Contributor

SvenDowideit commented Aug 5, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Aug 5, 2014

Contributor

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.

Contributor

SvenDowideit commented Aug 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@1mentat

1mentat 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)
.

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

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar 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?

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

This comment has been minimized.

Show comment
Hide comment
@nathanleclaire

nathanleclaire Aug 5, 2014

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".

Contributor

nathanleclaire 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?

@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

This comment has been minimized.

Show comment
Hide comment
@steeve

steeve Aug 5, 2014

Contributor

@SvenDowideit alright, closing then.

Contributor

steeve commented Aug 5, 2014

@SvenDowideit alright, closing then.

@steeve steeve closed this Aug 5, 2014

@hrldcpr

This comment has been minimized.

Show comment
Hide comment
@hrldcpr

hrldcpr 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

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

This comment has been minimized.

Show comment
Hide comment
@bfirsh

bfirsh Aug 5, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar 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?

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

This comment has been minimized.

Show comment
Hide comment
@bfirsh

bfirsh Sep 11, 2014

Contributor

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

Contributor

bfirsh commented Sep 11, 2014

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

@gansbrest

This comment has been minimized.

Show comment
Hide comment
@gansbrest

gansbrest Oct 5, 2014

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.

gansbrest commented Oct 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@alex-zige

alex-zige Oct 5, 2014

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

alex-zige commented Oct 5, 2014

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

@jmreicha

This comment has been minimized.

Show comment
Hide comment
@jmreicha

jmreicha Oct 24, 2014

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

jmreicha commented Oct 24, 2014

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

@gansbrest

This comment has been minimized.

Show comment
Hide comment
@gansbrest

gansbrest commented Oct 24, 2014

@jmreicha hodor! ))

@tianon tianon deleted the vboxsf branch Dec 16, 2014

@nathan-zhu

This comment has been minimized.

Show comment
Hide comment
@nathan-zhu

nathan-zhu Jun 30, 2015

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

nathan-zhu commented Jun 30, 2015

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

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jun 30, 2015

@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 moby/moby#13420 (comment))

thaJeztah commented Jun 30, 2015

@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 moby/moby#13420 (comment))

@mattes

This comment has been minimized.

Show comment
Hide comment
@mattes

mattes Jun 30, 2015

Contributor

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

Contributor

mattes commented Jun 30, 2015

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

@gansbrest

This comment has been minimized.

Show comment
Hide comment
@gansbrest

gansbrest Jun 30, 2015

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

gansbrest commented Jun 30, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@ehernandez-xk

ehernandez-xk Aug 25, 2016

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 commented Aug 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ehernandez-xk

ehernandez-xk Aug 25, 2016

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

ehernandez-xk commented Aug 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dduportal

dduportal Aug 26, 2016

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...

Contributor

dduportal commented Aug 26, 2016

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

This comment has been minimized.

Show comment
Hide comment

ehernandez-xk commented Aug 26, 2016

Thank you @dduportal

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