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.

  • Building common dependencies with docker-compose
  • Deploying a .NET Core Web API using Docker on Elastic Beanstalk
  • docker commit data container to private registry
  • Getting “Invalid address” error on gunicorn bind with my server ip . i am trying this within the docker
  • Error running docker container: No space left on device: “/data/db/journal”
  • Docker: Development environments [closed]
  • Locally:

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

    And on the server:

      image: username/repo:tag
        - "/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.

  • Gunicorn is stuck on docker run command with a Flask Application
  • What does COMMAND label means in docker container list?
  • Create docker image from Artifactory
  • Running Cloudant as docker container with docker compose
  • Use ehcache for application deployed via docker against the stateless rule
  • docker-compose restart always not issuing run command
  • 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


    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.