1.3.0 - Only root can write to OSX volumes / Can't change permissions within

[lynxnathan]

Currently only root inside the container is able to modify mounted volumes. Also permissions changed from within have no effect. I'm unsure as to whether cannot be managed dynamically on the blog post refers to any of this.

I would suggest updating the readme to let users know about the existence of native support for volumes and also its limitations (especially if this is one of them).

[mnapoli]

I think I'm having the same issue (latest versions of everything, installed today).

In the container, in a directory shared with the host (i.e. mounted through the virtualbox VM):

• root user can write files
• www-data user can't, even in a directory with 777 permissions

Is that normal or not? (i.e. I did something wrong)

[lukaswelte]

So means if I create a cache folder for example that writes new files and folders to disk during execution, I cannot do this right now?

Cause I experience the same problem as @mnapoli does..

[bradgessler]

I wrote up a simple test case. Let me know if there's anything else I can do to make this bug easier to fix.

First, I create a Dockerfile:

FROM ubuntu:14.04

# Adding user
RUN adduser --system --ingroup staff mugzy

# Setup repos dir.
RUN mkdir /data
RUN chown mugzy:staff -R /data
VOLUME /data

CMD touch /data/file && ls -al /data

Then create a host volume that I'll mount into the Docker instance at runtime:

app[master] → mkdir ./data

When I run the container, I see root:root ownership on the docker /data volume. I'd expect for this to be what I set from the Dockerfile above, mugzy:staff:

app[master] → docker run -i -v $PWD/data:/data c638bc43bfe7
total 4
drwxr-xr-x  1 1000 staff  102 Oct 21  2014 .
drwxr-xr-x 62 root root  4096 Oct 21 01:54 ..
-rw-r--r--  1 1000 staff    0 Oct 21 01:49 file

Obviously when I then run the docker instance as mugzy, the volume has incorrect permissions and I can't write to disk:

app[master] → docker run -i -v $PWD/data:/data -u mugzy c638bc43bfe7
total 4
drwxr-xr-x  1 1000 staff  102 Oct 21  2014 .
drwxr-xr-x 62 root root  4096 Oct 21 01:54 ..
-rw-r--r--  1 1000 staff    0 Oct 21 01:49 file
touch: cannot touch '/data/file': Permission denied

I'd imagine if people are trying to boot services in Docker on Mac, they'd want to be able to setup a volume that a service user can write to for persistence.

[vmaatta]

Mounting a VBox share as UID 999 will allow the created container user to write as it's usually 999. This is just a fragile hack on the hack but it does allow writing…

sudo mount -t vboxsf -o uid=999,gid=50 your-other-share-name /some/mount/location

[lukaswelte]

So can I use this command to set the /Users share to be writeable?
Or do I have to create a special share for every application that needs to be able to write in a folder?

[vmaatta]

/Users is a bit special as it's mounted by the boot2docker script (any share matching the names listed in release notes), changing it requires customising the code. I just created a custom share anyway as I don't want to share the whole /Users structure with containers.

1. Overriding the /Users default share on boot2docker start:

boot2docker --vbox-share=$(pwd)/share-location=share-name up

2. boot2docker ssh in and mount the custom share:

sudo mount -t vboxsf -o uid=999,gid=50 share-name [SHARE-FULL-PATH]/share-location

[lukaswelte]

Thanks for the workaround.
Although it would be great to have that behavior built into the boot2docker script (don’t want coworkers to do much extra action).

[SvenDowideit]

@tianon ?

[tianon]

This is bizarre - do we need to tweak something about the way we mount the share?

There's nothing special about what we do: https://github.com/boot2docker/boot2docker/blob/master/rootfs/rootfs/etc/rc.d/automount-shares (just uid=...,gid=... as mentioned here)