[ng-b2d] File ownership incorrect for shared folder mounts about boot2docker-debian

[ehazlett]

This is because of the bind mount to the shared directory. Unfortunately, this won't work. See this for details: boot2docker/boot2docker#581

[mbentley]

Ah so it looks like the reason that it worked before is because the previous boot2docker mounted /Users with docker:staff (1000:50) owning it and the container I've been using starts with the user being 1000 so it magically works.

To get around this same issue, I've had to mount my share manually via /etc/rc.local using something like sudo mount -t vboxsf -o uid=1000,gid=1000 mbentley /media/sf_mbentley so that I am the correct owner.

If it can't be done or needs to break, I understand; just trying to think if this could potentially break local development workflow for other users of boot2docker or not.

[ehazlett]

Ah good point. Perhaps we could check machine side for current uid/gid and chown / chgrp those. @tianon does that sound too crazy to you?

[tianon]

It's a shared folder mount, so chown won't actually work. You'd have to remount, which is putting this hack further into hack territory, especially since what uid users will want it remounted to will vary based on their opinions and the images they're using. IMO the proper solution is to document that this share is a hack, and that serious persistent storage needs should live in /mnt/data, and that should be made larger if more space is necessary.

[mbentley]

So in the current boot2docker, it is handle via the automount-shares script at boot time: https://github.com/boot2docker/boot2docker/blob/master/rootfs/rootfs/etc/rc.d/automount-shares. I get that it is hacky and that sucks but it works.

The only reason for the push back from me is that if I am trying to use b2d as a way to test code changes using docker containers, I can't do things like make those code changes in a container through a volume, assuming that I have it checked out to a location in my home directory on my laptop/workstation and have it just magically work. It'll work if I write bad containers that have everything run as root but we certainly don't want to endorse that. Having to do all of that in /mnt/data inside of b2d is also not ideal at all as I consider a b2d instance just a disposable docker engine.

[huslage]

This has to be completely frictionless for the user. Why isn't the folder mounted with 1000:1000 like before?

[mbentley]

Just as something that is interesting to note: while playing with remounting the share, as an example, sudo mount -t vboxsf -o uid=1000,gid=1000 Users/mbentley /Users/mbentley turns this:

drwxrwx--- 1 root vboxsf    204 Jun 15 13:49 VirtualBox VMs
-rwxrwx--- 1 root vboxsf    422 Jul 22 13:19 docker_machine_keys
drwxrwx--- 1 root vboxsf    170 Feb  3 20:04 git

into this:

drwx------ 1 docker docker    204 Jun 15 13:49 VirtualBox VMs
-rw-r--r-- 1 docker docker    422 Jul 22 13:19 docker_machine_keys
drwxr-xr-x 1 docker docker    170 Feb  3 20:04 git

The default VirtualBox auto-mount seems to mount the share with 0770 permissions which I can somewhat understand from a potential security standpoint but that makes for a bad experience. When I remount, I get my permissions to be passed through as well which would at least make most things work more as expected.

Maybe adding a script for the VirtualBox provider that will remount that share much like the automount-shares script did previously? I know that carrying hacky baggage forward sucks but so does greatly breaking the expected user experience; especially since it seems to be very common for people I talk to for their developers to use locally, not to mention it is what we've been teaching and telling people to do when they ask for our opinion.

[huslage]

Is there not a way to define it when you create the share?

On Wednesday, July 29, 2015, Matt Bentley [email protected] wrote:

Just as something that is interesting to note: while playing with
remounting the share, as an example, sudo mount -t vboxsf -o
uid=1000,gid=1000 Users/mbentley /Users/mbentley turns this:

drwxrwx--- 1 root vboxsf 204 Jun 15 13:49 VirtualBox VMs
-rwxrwx--- 1 root vboxsf 422 Jul 22 13:19 docker_machine_keys
drwxrwx--- 1 root vboxsf 170 Feb 3 20:04 git

into this:

drwx------ 1 docker docker 204 Jun 15 13:49 VirtualBox VMs
-rw-r--r-- 1 docker docker 422 Jul 22 13:19 docker_machine_keys
drwxr-xr-x 1 docker docker 170 Feb 3 20:04 git

The default VirtualBox auto-mount seems to mount the share with 0770
permissions which I can somewhat understand from a potential security
standpoint but that makes for a bad experience. When I remount, I get my
permissions to be passed through as well which would at least make most
things work more as expected.

Maybe adding a script for the VirtualBox provider that will remount that
share much like the automount-shares script did previously? I know that
carrying hacky baggage forward sucks but so does greatly breaking the
expected user experience; especially since it seems to be very common for
people I talk to for their developers to use locally, not to mention it is
what we've been teaching and telling people to do when they ask for our
opinion.

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

Aaron Huslage
Solution Architect - Docker, Inc.
[phone]

[ehazlett]

Unfortunately no -- it's the way the vbox service works. I'm hesitant to continue to the "bad" behavior especially when now would be the time to break it.

That being said, we could probably do something in machine to workaround but same worry as above.

@tianon thoughts around pushing to machine or breakage?

[tianon]

Pushing to machine would be pretty easy, especially given that the Fusion driver already does this manually there (so there's already precedent). Just stop setting the share to "automount", and then do the same post-boot mount ssh that fusion does and it should be good to go. It won't necessarily happen before Docker starts up though (in either case), so any containers using it with --restart=always will definitely break, but that's the case with the Fusion driver as-is too.
Pushing to machine would be pretty easy, especially given that the Fusion driver already does this manually there (so there's already precedent). Just stop setting the share to "automount", and then do the same post-boot mount ssh that fusion does and it should be good to go. It won't necessarily happen before Docker starts up though (in either case), so any containers using it with --restart=always will definitely break.

[ehazlett]

Ok I think this sounds well enough. I still think we should add a warning to the docs stating that it's a bit touchy.

[ehazlett]

Created docker/machine#1608 to track. Closing this.