Escolar Documentos
Profissional Documentos
Cultura Documentos
1.3.0 ‑ Only root can write to OSX volumes / Can't change New issue
permissions within #581
Open lynxnathan opened this issue on Oct 20, 2014 · 230 comments
# Adding user
RUN adduser --system --ingroup staff mugzy
# Setup repos dir.
RUN mkdir /data
RUN chown mugzy:staff -R /data
VOLUME /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.
This was referenced on Oct 22, 2014
VirtualBox Guest Additions #534 Merged
Cannot remove mounting of /Users on OS X #586 Open
@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)
So I definitely need more information about what's going wrong if we're going to figure out how to fix
it.
New container
root@7a795aa575df:/# useradd test-user
root@7a795aa575df:/# cat /etc/passwd
…
test-user:x:1000:1000::/home/test-user:/bin/sh
root@7a795aa575df:/tmp/test# su - test-user
No directory, logging in with HOME=/
$ cd /tmp/test
$ touch test-user-test-file
touch: cannot touch `test-user-test-file': Permission denied
VM
docker@boot2docker:~$ ls -lAF /Users/vmaatta/projects/data/writetest/
total 8
drwxr-xr-x 1 999 staff 68 Oct 23 20:44 root-dir/
drwxr-xr-x 1 999 staff 68 Oct 23 20:45 user-dir/
-rw-r--r-- 1 999 staff 5 Oct 23 20:48 user-file
lrwxr-xr-x 1 999 staff 9 Oct 23 20:49 user-link -> user-file
Now, as you said, it's very difficult to come up with a general fix. And this is actually not that different
from the situation of running docker on a Linux host without boot2docker or any other virtualisation
layer. Issues with volume folder rights are a challenge there as well.
Currently the vboxsf mount is UID / GID 1000 50. That's docker:staff in the VM and, no‑one:staff or
first user to default group in a container. I changed this to 999 50 which matches the new group and
user scenario by UID. GID is still 50 and this allows the VM docker user access and also the container
root user is fine. The web server I mount a volume for uses the new group and user scenario as well
so it works for me.
I don't know… maybe there's a better / more general UID / GID combination but I've seen 999 999
mentioned already a couple times in the Hub for containers' documentation. No surprise as they add
both group and a user. But YMMV and that's why I've just done this in bootlocal.sh instead of a pull
request.
And maybe we need something completely different [from vboxsf] to solve this.
Postgres being a bit bad example now as initdb dies on hard links now but oh well… there's
nothing we can do for that here unfortunately.
Yeah, in the general Linux case this is easier because the permissions
actually can be munged, generally speaking. With "vboxsf", we have to
choose one mapping, and no matter what we pick we're going to alienate a
non‑trivial number of people, so we defaulted to "docker:staff" to at least
make the reasons for the default choice clear and obvious.
Maybe making the exact uid/gid configurable via the persistent storage
"profile" file is the way to go, but that's really just pushing the already
bad situation down on our users (however, with the benefit that they can
actually get themselves to the workaround without a huge amount of effort,
compared to where we're at now with hacks in bootlocal, etc).
yup, @vmaatta has it baout right ‑ you could do this by hand, but you probably should consider that
you might be better off working out a different way to acheive it ‑ like using volume containers.
if [ -e /Users/username ]; then
umount /Users
fi
mkdir -p /Users/username/projects
mount -t vboxsf -o uid=999,gid=50 projects /Users/username/projects
@SvenDowideit I'm probably missing the point but… Volume containers are great and should always
be used where they make sense. But with regards to bind mounting something from the host they
don't change anything. They suffer from the same problems any other container does.
@vmaatta yeah ‑ you get around that atm by creating your data container like:
docker run --name data -v /data busybox chmod 777 /data
and then you need to copy that data to your local machine using another container.
I use samba containers for a reason :)
If anyone has a solid solution that will actually work long‑term without
extra developer friction (including but not limited to fragile
reconfiguring of external services that are frankly outside our reasonable
realm of control), we're all ears.
Support for "vboxsf" was added as a first‑pass solution to the basic
problem of accessing your data from inside the VM, with full knowledge that
it has limitations that make it not necessarily well‑suited for a number of
use‑cases, this one included (which was why adding it in the first place
was so controversial). It is important to keep in mind that it is strictly
better than what we used to have (which was absolutely nothing).
As has been stated previously, the real solution for this ought to come in
Docker itself, since this is a common problem to anyone whose client and
daemon don't live and play in the same filesystem.
@cnaicc remount is not a solution, containers should have access to multiple uid/gid and they need
to be isolated by the host environment.
Guys to solve all the permissions problems you just have to switch to NFS
instead of vboxfs, it''s not really a matter of dlite or whatever.
Just Google: docker‑machine‑nfs
Il 10/mar/2016 15 04, "Pierre" notifications@github.com ha scritto:
@JulienD https://github.com/JulienD : I had the same problem, I
switched to dlite https://github.com/nlf/dlite, it just works.
—
Reply to this email directly or view it on GitHub
#581 (comment)
.
2
Step 2: Change the command in docker‑compose.yml to run this script instead of the ordinary
command.
Example:
# Local database server to mimic a cloud database
localdb:
image: mysql:5.6.27
volumes:
- ./stack/localdb/.db/mysql:/var/lib/mysql:rw
- ./stack/localdb/:/stack/localdb:rw
ports:
- "3306"
environment:
MYSQL_ROOT_PASSWORD: "local-mysql-pass"
command: "/stack/localdb/run.sh"
millerdev added a commit to dimagi/docker‑riak‑cs that referenced this issue on Jun 8, 2016
Fix permissions in set-admin-keys.sh … 00e1b49
With docker‑library/mysql#161 you should be able to run mysql as the owner of the directory in
question:
docker run -d -e MYSQL_ROOT_PASSWORD=foobar1234 --user 1000:50 -v /Users/my-user/mysql-data
This will fix the permissions problem, but I cannot guarantee that mysql will always run on a
VirtualBox Shared Folder. MongoDB for example cannot run on the shared folder since the file
system does not support everything it needs.
motin commented on Sep 5, 2016
@ababushkin I have read reports from users of native Docker for Mac that they no longer need any
workaround. I created the permissions script to make it work on Docker Toolbox.
@TyIsI, many of the images provided by Docker Official Images (like rabbitmq ) were modified to
allow running as a different user so that you would not need to create or modify the user in the
image. See docker‑library/rabbitmq#60 and the other PRs linked from there. What this means is that
in most instances when using boot2docker on a Mac, you can do something like the following:
$ docker run -d -v /Users/myuser/rabbitdir/:/var/lib/rabbitmq/ --user 1000:50 rabbitmq:3-ma
Some notable exceptions that don't work with the VirtualBox shared folder are MongoDB (docker‑
library/mongo#74 (comment)) and MariaDB 10.1 (docker‑library/percona#42 (comment)).