Attempting to change ownership or permissions on a bind-mounted volume via docker exec fails

[samling]

I noticed this behavior yesterday when trying to bind-mount a local directory containing a webapp into my container so I could work on it without having to restart the container after every change. The app's framework is very particular about permissions, so I thought I'd try using docker exec to change them. The run command is something like:

docker run -v /Users/sboynton/project/webapp/:/app -t imagename

Then I ran the following to check permissions:

docker exec container_name ls -la /app

Which gives:

[...]
-rw-r--r--   1 1000 staff   174 Jun 26 22:24 build.properties
-rw-r--r--   1 1000 staff 10347 Jun 26 22:24 build.xml
-rw-r--r--   1 1000 staff  1464 Jun 26 22:24 index.php
drwxr-xr-x   1 1000 staff   102 Jun 26 22:24 lib
drwxr-xr-x   1 1000 staff   102 Jun 26 22:24 plugins
[...]

The following command should work, and does on files created by e.g. "docker exec container_name touch file_name", but doesn't in this scenario:

docker exec container_name chown www-data:www-data /app/build.xml

Running ls -la /app/build.xml still returns:

-rw-r--r--   1 1000 staff 10347 Jun 26 22:24 build.xml

Some other things that have been tried are creating a new file in the container's /tmp directory and attempting the same ownership change (works), creating a new file via docker exec in /app and attempting the same (fails), and attempting to change ownership using uid/gid instead of names (e.g. 33:33) (fails). chown, chgrp and chmod all exhibit this same behavior.

If this is a Docker issue and not a boot2docker issue, please let me know and I'll take the issue over there. However, users who tried the above from a Linux Docker host instead of through boot2docker were able to successfully modify permissions/ownership, which leads me to believe this is an issue with boot2docker.

[SvenDowideit]

this is a duplicate of #581(I'm not closing to make it easier for people to find)

[mnapoli]

+1 been pulling my hair all day on this.

[crucialfelix]

To add to this, not only do chown/chmod not have any effect from inside the container, they also do not have any affect from the boot2docker vm shell. so its natural that the container has no ability to modifiy since the host (boot2docker VM) cannot modify the files on the real host (OS X)

I guess this is a read only mount ?

Permissions show the files as owned by docker:

docker@boot2docker:/Users/crucial/shared/postgres$ ls -la
-rwxr-xr-x    1 docker   staff        19130 Nov  3  2013 postgresql.conf

But can't touch this:

# no error message, but does not actually touch the file
 docker@boot2docker:/Users/crucial/shared/postgres$ touch /Users/crucial/shared/postgres/postgresql.conf
# sudo make me a sandwich
docker@boot2docker:/Users/crucial/shared/postgres$ sudo touch postgresql.conf

Still untouched:

-rwxr-xr-x    1 docker   staff        19130 Nov  3  2013 postgresql.conf

cat throws an error:

cat "# added a line" >> /Users/crucial/shared/postgres/postgresql.conf
-sh: can't create /Users/crucial/shared/postgres/postgresql.conf: Operation not permitted

chown and chmod of course do not work. although I'm doing this on a large postgres data directory and it does take a while to run. so it is doing work. but there is no change

[paolomainardi]

Same issue here, shared local volumes from osx to containers are unable to handle permissions properly, which makes boot2docker unusable for a local dev environments. I've also tried to work just with data containerz, but exporting them with NFS/samba is a performance nightmare, a simple 'git status' takes seconds.

[paolomainardi]

This is.probably related:

http://superuser.com/questions/640027/why-cant-i-chown-a-virtualbox-shared-directory

[paolomainardi]

My temporary solution is to use NFS shared folders instead of vboxfs, as vagrant does.

From osx "/etc/exports":
/Users -mapall=[youruser]:[yourgroup] [boot2dockerip]

From boot2docker umount/remount /Users using NFS:

sudo umount /Users
sudo /usr/local/etc/init.d/nfs-client start
sudo mount 192.168.59.3:/Users /Users -o rw,async,noatime,rsize=32768,wsize=32768,proto=tcp

[SvenDowideit]

@paolomainardi yup, that was one of the solutions we should explore.

[chiefy]

@paolomainardi thanks for that tip - helped me out big time!

[mikeys]

@paolomainardi Maybe i'm doing something wrong: I can't run unmount from within the boot2docker virtual machine...

[paolomainardi]

@mikeys let me see the error log output