Docker Community Forums

Share and learn in the Docker community.

Beta 9: Unable to access mounted volumes owned by root

(Mark Anders) #1

Expected behavior

Mapped volumes should be accessible to docker if they are accessible to the current user.

Actual behavior

Host directories owned by root seem to not be usable when mounted.
I’ve mounted 2 volumes owned by root mounted via docker-compose and neither seems to be able to accessible (either read or write). I have them set up in docker-compose.yml as follows.

    - /data/pgdata:/pgdata

    - /certs:/certs

In the /certs folder I placed 2 cert files. After starting the containers, and having nginx shutdown, I exec’ed in and found the /certs dir correctly mapped. However, it did not appear to contain any cert files. Note: /certs is owned by root, the files are owned by me.

For postgres, on startup, no data files are created.

I then changed the directories to be off of ~ (~/certs, and ~/data/pgdata) and everything worked as expected.


OS X: version 10.11.5 (build: 15F28b) version v1.11.0-beta9
Running diagnostic tests:
[OK]      docker-cli
[OK]      Moby booted
[OK]      driver.amd64-linux
[OK]      vmnetd
[OK]      osxfs
[OK]      db
[OK]      slirp
[OK]      menubar
[OK]      environment
[OK]      Docker
[OK]      VT-x
Docker logs are being collected into /tmp/20160430-082638.tar.gz
Most specific failure is: No error was detected
Your unique id is: 86DF8E94-5D0E-4814-8A71-11F007590D3D
Please quote this in all correspondence.

(David Sheets) #2

Hi Mark,

Only the directories /Users, /Volumes, /tmp, and /private are mounted straight-through from OS X into the VM. Please see in the section Namespaces for more information. If you’d like to use /certs or /data, you’ll need to prefix them with /Mac for now: /Mac/certs and /Mac/data. This convention is temporary and will be removed before we leave Beta in favor of a more flexible namespace mechanism.

Thanks for participating in the Docker for Mac Beta!


(Mark Anders) #3

Thanks David! I think I got confused by:

All other paths used in -v bind mounts are sourced from the Moby Linux VM running the Docker containers, so arguments such as -v /var/run/docker.sock:/var/run/docker.sock should work as expected.

Will the “more flexible namespace mechanism” include a way to have a single file that can have different prefixes depending on where its deployed?

Thanks again!


(David Sheets) #4

What do you mean by

a way to have a single file that can have different prefixes depending on where its deployed


(Mark Anders) #5

Sorry for not being clearer. Meaning will there be a way to have a “prefix” where it resolves to different things on different platforms.

For example, if I have in my compose file /Mac/certs, when running docker compose, I assume it strips off /Mac and looks for /certs. However, if I ran the same compose on Linux, would it do the same? Or would it look for a directory called /Mac/certs?

Note: I haven’t tried pushing /Mac/certs to my Linux box so it may work now.

Currently, I can use ~ as my prefix and it will resolve to a sensible place on both boxes. Just not sure I want my certs and database in ~.

I hope I’m explaining things in a way that makes sense.

(David Sheets) #6

There are two stages of name translation in your use of the volume mount system:

  1. Shell translation, e.g. ~ is translated to $HOME, before the client command is executed
  2. VM bind mount translation, e.g. /Users is translated to /Mac/Users in the Linux VFS

The /Mac mount point will be disappearing because it is, as you say, not portable to Linux.

If you want portable client-side scripts, I recommend using consistent rooted path naming across your deployment targets or parameterizing your commands or scripts over a command-line argument or environment variable (or wiring those into a configuration file).

Hope this helps,


(Mark Anders) #7

Makes perfect sense.

I had spent a while googling for how to use environment variables in a docker-compose file and found Stack Overflow accepted solutions that had workarounds for env vars, so I did not know they existed.

Very nice. Thank you!