VirtualBox Guest Additions #534

Merged
merged 2 commits into from Sep 15, 2014

Projects

None yet
@tianon
Contributor
tianon commented Sep 11, 2014

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

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

This has been tested on Linux, Mac OS X, and Windows.

If you'd like to test it out without any changes to boot2docker-cli, use:

  • Mac OS X: VBoxManage sharedfolder add boot2docker-vm --name /Users --hostpath /Users --automount
  • Windows: VBoxManage.exe sharedfolder add boot2docker-vm --name /c/Users --hostpath C:/Users --automount (note that this will NOT WORK from inside the msys bash shell because of http://www.mingw.org/wiki/Posix_path_conversion - you must either run it from cmd directly, or create the share of C:\Users named as /c/Users manually)

This will make it so that things like docker run -v "$(pwd)":/some/container/path ... work as you'd expect from Mac OS, and also so that the /Users or /c/Users directory is available for easy access when you boot2docker ssh into your VM.

As a side note, if anyone has ideas for how to disable or prevent that msys path conversion from happening without linking against msys.dll, please please please let me know (I can't find anything useful).

@sfitts
sfitts commented Sep 11, 2014

I've run into the msys auto-conversion thing myself and the only thing I've found is that if you add an extra / to the path it should prevent the conversion (though you end up with both slashes, so sometimes that doesn't really help). Not sure if trick will work here, but it might be worth a shot (I'll try it out myself at some point, but that won't be for a bit due to other work priorities).

Oh -- and thanks for resurrecting this. I know it is controversial, but it really does make life for those of us working on Windows a lot nicer (the lack of a native Docker client there gives us a few more issues than our Mac brethren).

@SvenDowideit
Member

Where's the Documentation?

@tianon
Contributor
tianon commented Sep 11, 2014

Fair point - I'll write up something. 👍

@SvenDowideit SvenDowideit and 1 other commented on an outdated diff Sep 11, 2014
+RUN mkdir -p /vboxguest && \
+ cd /vboxguest && \
+ \
+ curl -L -o vboxguest.iso http://download.virtualbox.org/virtualbox/${VBOX_VERSION}/VBoxGuestAdditions_${VBOX_VERSION}.iso && \
+ 7z x vboxguest.iso -ir'!VBoxLinuxAdditions.run' && \
+ sh VBoxLinuxAdditions.run --noexec --target . && \
+ mkdir amd64 && tar -C amd64 -xjf VBoxGuestAdditions-amd64.tar.bz2 && \
+ mkdir x86 && tar -C x86 -xjf VBoxGuestAdditions-x86.tar.bz2 && \
+ \
+ KERN_DIR=/linux-kernel/ make -C amd64/src/vboxguest-${VBOX_VERSION} && \
+ cp amd64/src/vboxguest-${VBOX_VERSION}/*.ko $ROOTFS/lib/modules/$KERNEL_VERSION-tinycore64/ && \
+ \
+ mkdir -p $ROOTFS/sbin && \
+ cp x86/lib/VBoxGuestAdditions/mount.vboxsf $ROOTFS/sbin/ && \
+ \
+ cd / && rm -rf /vboxguest
@SvenDowideit
SvenDowideit Sep 11, 2014 Member

please do not delete the code - that makes debugging harder.

@tianon
tianon Sep 11, 2014 Contributor

Fair, although it does make the image bigger. Can I at least delete the
ISO and the tarballs since they're already extracted into the directory at
this point?

@SvenDowideit
SvenDowideit Sep 11, 2014 Member

if you really think it makes a noticeable difference to the 1.7GB image...

@tianon
tianon Sep 11, 2014 Contributor

Sure, in the context of 1.7GB, 62M isn't much, but even with a 15mbit
internet connection that 62M ISO still takes roughly half a minute extra
assuming the connection is maxed out (which it usually isn't, and even that
connection speed is likely overestimated on the average case).

@SvenDowideit SvenDowideit and 1 other commented on an outdated diff Sep 11, 2014
rootfs/rootfs/bootscript.sh
@@ -39,6 +39,9 @@ if grep -q '^docker:' /etc/passwd; then
fi
fi
+# Automount VirtualBox magic (bails gracefully on non-VBox)
+/etc/rc.d/vboxsf
@SvenDowideit
SvenDowideit Sep 11, 2014 Member

can we use the better hypervisor detection to make a name based switch here?

@tianon
tianon Sep 11, 2014 Contributor

The first thing the script does is use "modprobe vboxguest" to bail on
non-virtualbox platforms. I thought it'd be cleaner to have the
conditional in the script itself than in here, but I don't mind moving it
or duplicating it if you disagree.

@SvenDowideit
SvenDowideit Sep 11, 2014 Member

I want to add an sshfs based version soon after this lands for my remote b2d's.

@tianon
tianon Sep 11, 2014 Contributor

I think that sounds awesome - so what do you propose I change here? Rename
the file so it can be the center of "share mounting" instead of being
specific to VirtualBox?

@SvenDowideit
SvenDowideit Sep 12, 2014 Member

yeah, something like that - i'd rather not 'try every script and fail' but having it hardcoded to vbox is :/

@tianon
tianon Sep 12, 2014 Contributor

That's definitely reasonable IMO! :) I'll update with that in the next
batch.

@SvenDowideit SvenDowideit and 1 other commented on an outdated diff Sep 11, 2014
rootfs/rootfs/etc/rc.d/vboxsf
+ return 1
+ fi
+
+ return 0
+}
+
+# this will bail quickly and gracefully if we're not in VBox
+if modprobe vboxguest &> /dev/null && modprobe vboxsf &> /dev/null; then
+ # bfirsh gets all the credit for this hacky workaround :)
+ try_mount_share /Users 'Users' \
+ || try_mount_share /Users \
+ || try_mount_share /c/Users 'c/Users' \
+ || try_mount_share /c/Users \
+ || try_mount_share /c/Users 'c:/Users' \
+ || true
+ # TODO replace this hacky bit with VBoxService --only-automount
@SvenDowideit
SvenDowideit Sep 11, 2014 Member

What about boot2docker on linux?

@tianon
tianon Sep 11, 2014 Contributor

For boot2docker on linux, VBoxService would really be ideal so that we only
share $HOME by default and let it automount properly (especially so we
don't have the share mount breaking /home/docker in the guest, or have
/home/docker bleeding outwards into the host), but since the VBox binaries
won't work properly in our 32bit userspace with our 64bit kernel, we can't
even enumerate the current shares and just have to poke around in the dark.
I do want to fix that as a future enhancement, though, which is why I
mentioned VBoxService in the comment here. I've definitely been testing
this all in Linux.

@SvenDowideit
SvenDowideit Sep 12, 2014 Member

so, how exactly does it work on linux.... right now?

@tianon
tianon Sep 12, 2014 Contributor

I named my "/home/tianon" share "Users", and then it gets mounted at "/Users" for the initial testing. For more testing, I did a boot2docker ssh into the machine afterwards with my share named "home/tianon" instead and then did sudo -Hi to get a root shell, . /etc/rc.d/vboxsf to source the "try_mount_share" function, then try_mount_share /home/tianon home/tianon to actually mount it, and that worked too.

@SvenDowideit
SvenDowideit Sep 12, 2014 Member

ah, ok, so a tiny amount of post processing - like in boot2docker up can fix that up for us, sweet.

I do wonder - why are we not doing the same thing for OSX & Windows, thus at minimum increasing the safety of the other users files?

@tianon
tianon Sep 12, 2014 Contributor

Specifically because it requires post-processing in "boot2docker up", but
if we could get "VBoxService" working (or even just "VBoxControl", but in
my testing they both fail in the same way because of the same issues) we
could have that without any extra work by either side, which I'd definitely
be +1 on (and is actually exactly why I wanted to hard lock the share-name
to the inside-the-guest path like I have here, since it makes it easier for
people to set up scenarios like that if they want to).

@tianon
tianon Sep 12, 2014 Contributor

I'm trying to minimize the external interface to this (ie, I don't
want users to have to know that
/etc/rc.d/whatever-this-scripts-ends-up-being-called is actually a
thing, especially in case we have to or want to change it later).

@dduportal
Contributor

That's a good job !

One point to (maybe?) help you : while it's perfectly working with vagrant (see my custom vagrant image, based on the previous work - http://vagrantup.com/dduportal/boot2docker), we should throw an eye on how vagrant did it on Windows ?

@tianon
Contributor
tianon commented Sep 12, 2014

Just as an update, I was dealing with some ill family today. I've updated the technical bits here, but hope to get some docs done tomorrow.

@tianon
Contributor
tianon commented Sep 13, 2014

Ok, this has some basic documentation now, too. 👍

@SvenDowideit SvenDowideit commented on the diff Sep 14, 2014
README.md
+2. `/Users` share at `/Users`
+3. `c/Users` share at `/c/Users`
+4. `/c/Users` share at `/c/Users`
+5. `c:/Users` share at `/c/Users`
+
+If some other path or share is desired, it can be mounted at run time by doing
+something like:
+
+```console
+$ mount -t vboxsf -o uid=1000,gid=50 your-other-share-name /some/mount/location
+```
+
+It is also important to note that in the future, the plan is to have any share
+which is created in VirtualBox with the "automount" flag turned on be mounted
+during boot at the directory of the share name (ie, a share named `home/jsmith`
+would be automounted at `/home/jsmith`).
@SvenDowideit
SvenDowideit Sep 14, 2014 Member

so - why not do this now? it'd be safer than always sharing /Users, and a heffalump more flexible for Linux hosts that run b2d

(even though I presume you would want to do this using the non-working VBoxService - you have full access to getting boot2docker-cli to tell the vm what you need to know...)

@SvenDowideit
SvenDowideit Sep 14, 2014 Member

Considering it further - Given that the boot2docker vm that we create using b2d is not accessible to any other users (if you log in as a different user, they won't see this one, and would init a new one, Why are we sharing /Users/ ?

@tianon
tianon Sep 14, 2014 Contributor

From rootfs/rootfs/etc/rc.d/automount-shares:

    # TODO replace this whole hacky bit with VBoxService --only-automount
    # (the problem with that being that we can't run VBoxService because the
    #  32bit VBoxService won't work with the 64bit kernel modules, but the 64bit
    #  VBoxService won't work with our 32bit userspace; good times)
@tianon
tianon Sep 14, 2014 Contributor

So, mostly because I think a solution where we open SSH to instrument the VM after the fact in boot2docker-cli is a really bad hack that relies way too much on the internals of the VM.

@SvenDowideit
SvenDowideit Sep 14, 2014 Member

mmm, ok - I think handing /Users/ is a worse hack, especially as this implementation currently doesn't work on Linux.

@tianon
tianon Sep 15, 2014 Contributor

Ok, so a further justification is that this hack will definitely be compatible in future versions of boot2docker, where that other hack is likely not to be, but I feel like we might be going in circles now. I'll go add some docs to mention Linux.

@SvenDowideit
Member

This PR is only missing some documentation to say that it does not work for Linux - even if you share /home as Users, it will then be mounted in the wrong place, and the -v $(pwd):/data will thus fail.

once that's done - LTGM

@tianon tianon Update VBox Additions code with some minor changes (especially for ca…
…che-ability)

Also, this includes a hacky init script that bfirsh gets to take all the credit for that tries to mount `/Users` and/or `/c/Users`, since we can't run `VBoxService` proper (thanks to hairy issues with 32bit userspace of TCL; good times).
1bf1671
@tianon
Contributor
tianon commented Sep 15, 2014

Ok, I've updated with a paragraph about the nonexistent Linux support: (copied here for easier review)

In case it isn't already clear, the Linux host support here is currently hazy.
You can share your /home or /home/jsmith directory as Users or one of the
other supported automount locations listed above, but note that you will then
need to manually convert your docker run -v /home/...:... bind-mount host
paths accordingly (ie, docker run -v /Users/...:...). As noted in the
previous paragraph however, this is likely to change in the future as soon as a
more suitable/scalable solution is found and implemented.

@SvenDowideit
Member

LGTM - will there be a b2d-cli PR to set these up?

@tianon
Contributor
tianon commented Sep 15, 2014

Yeah, that's the plan - I've been working on that on the side while this one got some review. 😄

@tianon tianon merged commit 83fd8c2 into boot2docker:master Sep 15, 2014
@tianon tianon deleted the tianon:vbox-guest-additions branch Sep 15, 2014
@bfirsh
Member
bfirsh commented Sep 16, 2014

\o/

spinal_tap_-_up_to_eleven

@wavded
wavded commented Sep 16, 2014

wOOt!

@michaelneale
Contributor

+1. @SvenDowideit is this really a stopgap before the docker client can share a local volume to a "remote" daemon?

@bfirsh
Member
bfirsh commented Sep 16, 2014

@michaelneale Yes, this is a stopgap until Docker itself supports remote volumes. See docker/docker#7249

@SvenDowideit
Member

@michaelneale just you wait! the awesomness that @bfirsh and @tianon are working on is...

@bsr203
bsr203 commented Sep 22, 2014

Hello, a docker newbie and stuck at how to mount my home folder(Mac - /Users/bsr ) to the container. As per the doc, https://github.com/boot2docker/boot2docker#virtualbox-guest-additions, the /User folder is automatically mounted. but, I don't see it. I guess it is because I use latest release (v 1.2) and this pull request merged after. So, what option I have. Is there a way to update my boot2docker (installed through homebrew) to master branch. or a better way?

when I tried, mount -t vboxsf -o uid=1000,gid=50 /Users/bsr /Users
it gave error, I guess, no vbox addition is not yet in 1.2
mount: unknown filesystem type 'vboxsf'

@sciutand

I had the same problem, you can clone this repositiory. Cd in to it and build the image:

$ docker build -t user/boot2docker .

It takes a little while. Once finished you need to to extract it's iso. This is how I've done it:

$ docker run -i -t --rm user/boot2docker /bin/bash

open a new terminal

$ docker cp <Container-ID>:boot2docker.iso image

You'll find the iso file inside the dir image.

At this point stop your current boot2docker

$ boot2docker stop

Do a backup

$ mv ~/.boot2docker/boot2docker.iso ~/.boot2docker/boot2docker.iso.backup

replace the image file with:

$ mv image/boot2docker.iso ~/.boot2docker/boot2docker.iso

don't forget to mount the desired directory.

$ VBoxManage sharedfolder add boot2docker-vm -name /Users -hostpath /Users

now you should be able to restart boot2docker and folders will be mounted as per documentation.

@bsr203
bsr203 commented Sep 22, 2014

@sciutand thanks a lot.. I was keep refreshing for a response.. and gonna try now .. thanks a ton


docker build my/boot2docker . gave error, so I searched for how to build custom image, and ended up doing this.

 git clone https://github.com/boot2docker/boot2docker.git
 cd boot2docker/
 docker build -t my-boot2docker-img .
 docker run --rm my-boot2docker-img > boot2docker.iso
 boot2docker stop
 mv ~/.boot2docker/boot2docker.iso ~/.boot2docker/boot2docker.iso.backup
 mv boot2docker.iso ~/.boot2docker/boot2docker.iso
 boot2docker up
 docker run -d -P --name web ubuntu

/Users is not mounted. Tried, manually as per doc

 mkdir /Users
 mount -t vboxsf -o uid=1000,gid=50 /Users /Users
 mount: wrong fs type, bad option, bad superblock on /Users,
        missing codepage or helper program, or other error
        In some cases useful info is found in syslog - try
        dmesg | tail  or so
@sciutand

@bsr203 No problem, I also tried the Volume container via samba as per docs but for some reason the mounting was very flaky, basically unusable not sure why.

@sciutand

Sorry my bad missed the -t flag.

Once you have the iso image you can try to test it directly with virtualbox. When it launched you should see the message that it has VB guest addition on. Also I forgot the step where you ad the shared folder named /User to any directory on your host in virtualbox either via GUI or command line. I'll update the comment to reflect that.


Sent from Mailbox

On Tue, Sep 23, 2014 at 9:12 AM, bsr203 notifications@github.com wrote:

@sciutand
docker build my/boot2docker . gave error, so I searched for how to build custom image, and ended up doing this.

git clone https://github.com/boot2docker/boot2docker.git
cd boot2docker/
docker build -t my-boot2docker-img .
docker run --rm my-boot2docker-img > boot2docker.iso
boot2docker stop
mv ~/.boot2docker/boot2docker.iso ~/.boot2docker/boot2docker.iso.backup
mv boot2docker.iso ~/.boot2docker/boot2docker.iso
boot2docker up
docker run -d -P --name web ubuntu

/Users is not mounted. Tried, manually as per doc

mkdir /Users
mount -t vboxsf -o uid=1000,gid=50 /Users /Users
mount: wrong fs type, bad option, bad superblock on /Users,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

dmesg | tail
device veth09bc entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): veth09bc: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth09bc: link becomes ready
docker0: port 1(veth09bc) entered forwarding state
docker0: port 1(veth09bc) entered forwarding state
IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready
docker0: port 1(veth09bc) entered forwarding state
sf_read_super_aux err=-22
sf_read_super_aux err=-22
sf_read_super_aux err=-22

do you see any issue in my procedure.. thanks again.

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

@bsr203
bsr203 commented Sep 22, 2014

Also, being a newbie, I tried to follow your instruction

docker run -i -t --rm my-boot2docker-img /bin/bash
root@8c8b662:/#

then I guess, I cannot run the next command from this shell.

root@8c8b662a08f1:/# docker cp 8c8b662a08f1:boot2docker.iso boot2docker.iso
bash: docker: command not found

then I opened another terminal,

$ docker cp 8c8b662a08f1:boot2docker.iso boot2docker.iso
boot2docker stop
mv ~/.boot2docker/boot2docker.iso ~/.boot2docker/boot2docker.iso.backup2
mv boot2docker.iso ~/.boot2docker/boot2docker.iso

it never started the VM

boot2docker up
Waiting for VM and Docker daemon to start...
.................................

@sciutand

Ok so my original post had quite a few mistakes.

  • Yes you need to open a new terminal. I had issues piping out the iso directly but if it worked for you directly great.
  • it never starts the vm because we were copying a directory called boot2docker.iso not the actual file. Updated original comment.
  • my is too short as domain I updated to user in the original comment.

I think you are close just need to mount the shared folder in your virtualbox. Also make sure you are running virtualbox version 4.3.16

@bsr203
bsr203 commented Sep 22, 2014

indeed ..worked like a charm.. it would be better to be this
VBoxManage sharedfolder add boot2docker-vm -name /Users -hostpath /Users
explicitly mention in the documentation, for user not aware of it.. thanks again for your patience and help..

@odewahn
odewahn commented Sep 22, 2014

+1

This worked great for me, as well. Thanks, @sciutand

On Mon, Sep 22, 2014 at 6:14 PM, bsr203 notifications@github.com wrote:

indeed ..worked like a charm.. it would be better to be this
VBoxManage sharedfolder add boot2docker-vm -name /Users -hostpath /Users
explicitly mention in the documentation, for user not aware of it.. thanks
again for your patience and help..


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

@bfirsh
Member
bfirsh commented Sep 23, 2014

We're working on a UI and documentation for this before we launch it, don't worry! Appreciate the enthusiasm though. ;)

@dylanlindgren

Thanks very much @sciutand! Your instructions worked perfectly for me! 😄

@mkolodny

Yes, thanks @sciutand! Those instructions line for line worked for me.

@gaastonsr

Eager for this to be in the official release.

@bfirsh
Member
bfirsh commented Sep 25, 2014

UI is here: boot2docker/boot2docker-cli#258

This will be in the next official release.

@razic
razic commented Sep 28, 2014

Wow this actually made it in?

@stevepereira

Is this release waiting to sync with the next Docker release?

@tianon
Contributor
tianon commented Sep 30, 2014

Yes, boot2docker releases are synced to Docker releases, so this will be in
1.3 or 1.2.1, whichever comes first.

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

@SchumacherFM

Nice work @gansbrest !
Sounds like a great solution as we are using Magento with the same amount of files and it is so slow via shared folders ...

But I don't like Ruby so I'm gonna to rewrite it in Go. I also need the sync on Windows :-(
Go has a library for cross plattform sync: https://github.com/howeyc/fsnotify no idea if that works well....

@AkeemMcLennon

Hmm, @gansbrest and @SchumacherFM bring up some interesting points and ideas.

However, since these changes are ultimately intended for the fig project, perhaps it might be useful to integrate this filesystem monitoring into Fig directly?

@bfirsh
Member
bfirsh commented Oct 6, 2014

You might be interested in docker/compose#184

@huahaiy
huahaiy commented Oct 8, 2014

These changes should be independent from Fig. The results of Fig's monitoring filesystem change is to rebuild and reload the container, but that may be too expensive. People often prefer to use their development environment's own system reloading mechanism, e.g. Clojure's lein-ring, etc. boot2docker should support these use cases.

@SvenDowideit
Member

@huahaiy there is nothing in these changes that are dependant on fig - there are comanion changes in boot2docker-cli to make it work. - if you read @AkeemMcLennon 's comment, it asks about integrating this change into fig :)

@gansbrest

Sorry guys, I'm not too familiar with fig. From the brief look, Hodor seem to follow similar concepts ( define config and run task ). You may probably take and integrate file sync/forwarding parts. I just wanted to create simple tool to allow our team to do develop in the docker environment efficiently.

@dekz
dekz commented Oct 11, 2014

Correct me if I am wrong but no longer have to build from source (as per @sciutand comment) for this support, you can just curl the iso and use that.

http://static.dockerfiles.io/boot2docker-v1.2.0-virtualbox-guest-additions-v4.3.14.iso

@tianon
Contributor
tianon commented Oct 11, 2014

That ISO isn't an official release. ;)

@dekz
dekz commented Oct 11, 2014

Oh maybe I misunderstood based on the URL.

Would you say one should follow the original @sciutand advice in building and copying the ISO over then?

@gaastonsr

If the above ISO works why not use it?

@abilash222

the above ISO is not working. /User directory is not mounted

@dekz
dekz commented Oct 14, 2014

@abilash222 did you use VBoxManage to share the folder into boot2docker?

@vmaatta
vmaatta commented Oct 21, 2014

Ok so folders on the Mac host (under $HOME) can now be shared with the container… and you can do nothing with them:

Operation not permitted, Permission denied, could not create directory

I've tried chowning them to 999:999, changed folder rights to 777… and still, those volume folders are just as unusable from the container.

E.g. -v ($HOME)/projects/data/db/:/var/lib/postgresql/data/

@michaelneale
Contributor

@vmaatta I ran `docker -it -v /Users:/Users ubuntu:14.04 /bin/bash' and was able to ls and cat files from my him dir just fine - this is stock Docker 1.3

@vmaatta
vmaatta commented Oct 21, 2014

Ok, say:

  1. docker run -v /Users/vmaatta/test:/tmp/test -it --rm debian:latest bash: I can manually read, write files and create folders in the container.
  2. I make the same folder a data volume for a postgres /var/lib/postgresql/data and here's the result:
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... initdb: could not create directory "/var/lib/postgresql/data/global": Permission denied
initdb: removing contents of data directory "/var/lib/postgresql/data"

The same with a different container, a web server that needs to write all kinds of files, they both fail with the aforementioned access problems.

@vmaatta
vmaatta commented Oct 21, 2014

And it seems there's an issue for it… #581. The release notes are really quite misleading / missing an important note.

@huahaiy
huahaiy commented Oct 23, 2014

@vmaatta I seem to be able to run postgres container just fine on boot2docker, see my Postgres Dockerfile here. initdb run as the user postgres, so make sure that user have permission on the $PGDATA directory.

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