docker-compose volumes not mounting to host directories

I’m using docker-compose for deployment, with a 2 docker-compose.yml setup where I’m building the image locally and pulling from docker hub on the server.

Besides building vs pulling an image, the volumes config is the same.

  • How to run a docker command in Jenkins Build Execute Shell
  • Boot2Docker: Can't create directory: Protocol Error
  • Docker error on Windows 2016 “Client.Timeout exceeded while awaiting headers”
  • Best way to reduce the size of a custom Docker image
  • Managing directory permissions across the host and Docker container environments
  • godep vendor with docker
  • Locally:

    app:
      build: .
      volumes:
        - "/data/volume:/volume"
    

    And on the server:

    app:
      image: username/repo:tag
      volumes:
        - "/data/volume:/volume"
    

    In my Dockerfile:

    volume /volume
    

    Locally my volume mounts to the specified directory fine, with files created by the app persisted there outside the container. On the deployment server, however, this does not happen.

    Files are however created and persisted through deploys, even though my deployment script runs docker-compose down -v which presumably removes named & anonymous volumes on the container.

    I’m sure I’m doing something wrong, but I can’t see what. Could it be a caching issue? The volume configuration was not the same on initial deploy.

    More Info:

    I actually can’t seem to force the images to be lost between deploys. I ran:

    docker-compose down -v --rmi all --remove-orphans
    docker rm $(docker ps -a -q)
    docker rmi $(docker images -q)
    docker volume rm $(docker volume ls -q)
    

    … which I thought would leave me with a clean slate for redeploying, then:

    docker pull username/repo:tag
    docker-compose build --no-cache --force-rm
    docker-compose up -d
    

    … and the files which are supposed to be in the mounted volume are still there, and there’s still nothing in the mounted dir on the disk. Any ideas?

    Still more info

    Running docker inspect <container> on the server yields a mount configuration like this:

    "Mounts": [
      "Source": "/data/volume",
      "Destination": "/volume",
      "Mode": "rw",
      "RW": true,
      "Propagation": "rprivate"
    ]
    

    I notice there’s no Driver specified, and not sure about the significance of “rprivate”, but the Source and Destination do appear to be correct.

  • Where is Docker storing the images? [closed]
  • How to copy multiple files into a docker data volume
  • Difference between Docker and AMI
  • How to see which docker volume is or was being used by which container
  • Handling ports in Shipyard Load Balancer with Docker
  • docker-machine inside Symfony Process
  • 2 Solutions collect form web for “docker-compose volumes not mounting to host directories”

    I suggest on the server check the permissions on /data/volume change them to 777 temporary for testing if this is the issue. Also user server is just a Linux machine? Or is a virtualized environment created with docker-machine or something like that.

    The volumes you are using are not anonymous or named but host mounted. There is no command in docker which will delete a host mounted volume.

    I also suggest to do the same procedure using docker run instead docker-compose to discard a problem with docker-compose

    Regards

    The problem was that I’d mounted a EBS volume to /volume after the Docker service had been started.

    The directory was mounted in the container, which is why the docker inspect looks correct, but it mounted the pre-existing mount point which was overlayed by the host’s own mount.

    This mount happened after the Docker service was started, but long before any containers were actually started up, so it didn’t occur to me that Docker might not be respecting the filesystem change which had happened earlier.

    The solution was just to restart the Docker service.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.