9

I have the following example

version: '2'

services:
  proxy:
    container_name: proxy
    hostname: proxy
    image: nginx
    ports:
      - 80:80
      - 443:443
    volumes:
      - proxy_conf:/etc/nginx
      - proxy_htdocs:/usr/share/nginx/html

volumes:
  proxy_conf: {}
  proxy_htdocs: {}

which works fine. When I run docker-compose up it creates those named volumes in /var/lib/docker/volumes and all is good. However, from the host, I can only access /var/lib/docker as root, because it's root:root (makes sense). I was wondering if there is a way of chowning the host's directories to something more sensible/safe (like, my relatively unprivileged user that I use to do most things on the host) or if I just have to suck it up and chown them manually. I'm starting to have a number of scripts already to work around other issues, so having an extra couple of lines won't be much of a problem, but I'd really like to keep my self-written automation minimal, if I can -- fewer chances for stupid mistakes.

By the way, no: if I mount host directories instead of creating volumes, they get overlaid, meaning that if they start empty, they stay empty, and I don't get the default configuration (or whatever) from inside the container.

Extra points: can I just move the volumes to a more convenient location? Say, /home/myuser/myserverstuff/volumes?

Morpheu5
  • 2,610
  • 6
  • 39
  • 72

1 Answers1

24

It's best to not try to access files inside /var/lib/docker directly. Those directories are meant to be managed by the docker daemon, and not to be messed with.

To access the data inside a volume, there's a number of options;

  • use a bind-mounted directory (you considered that, but didn't fit your use case).
  • use a "service" container that uses the same volume and makes it accessible through that container, for example a container running ssh (to use scp) or a SAMBA container (such as svendowideit/samba)
  • use a volume-driver plugin. there's various plugins around that offer all kind of options. For example, the local persist plugin is a really simple plug-in that allows you to specify where docker should store the volume data (so outside of /var/lib/docker)
thaJeztah
  • 27,738
  • 9
  • 73
  • 92
  • Thanks, the local persist plugin might in fact be exactly what I need. I had thought of using a service container, and export volumes through nfs, but it seemed to be way too much convoluted for my needs. – Morpheu5 Mar 31 '16 at 11:10
  • 1
    Great! I hope it works out for you. There's no "one size fits all", so I thought "let's mention some options to pick from" :-) – thaJeztah Mar 31 '16 at 23:11
  • I also thought of the NFS/SMB export thing..I like the idea of mounting those volumes remotely on my laptop and using my favourite editor/file manager, but then NFS over SSH is painful, I have no use for Kerberos, and I'm not sure SMB offers any encryption (and access control is no less messy than Kerberos). – Morpheu5 Apr 01 '16 at 05:44
  • Actually for just specifying the location of a named volume, the _local_ volume driver (that is shipped with Docker) is sufficient enough. See https://stackoverflow.com/questions/36387032/how-to-set-a-path-on-host-for-a-named-volume-in-docker-compose-yml for an example. – Christian Ulbrich Apr 19 '18 at 12:12
  • OP specifically wanted the named volume behaviour of copying container contents to host on empty mount. Is there any reason why this solution wouldn't be appropriate @thaJeztah? https://stackoverflow.com/a/45039609/3080207 – mikey Jun 14 '18 at 06:48
  • @mikeyjk yes the local driver option should work as well; I think that approach was not yet investigated at the time I wrote this answer – thaJeztah Jun 22 '18 at 00:45