CODEWITHSUNDEEP
dockerdocker-compose
numbers1311407
numbers1311407

Reputation: 34072

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.

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.

Upvotes: 22

Views: 57486

Answers (4)

Federico Ba&#249;
Federico Ba&#249;

Reputation: 7715

Windows 11 - wsl 2

I was having issue when adding volume (both via cli, Dockerfile, docker-compose) So for instance

version: '3'

services:
  myserver:
    restart: unless-stopped  
    volumes:
      - "./app:/app"

It was not creating the volume, I could testing by running in the dockerfile this

FROM python:3.7-buster

ENV DEBIAN_FRONTEND noninteractive

CMD ["ls", "/app","-lah"]

Which would show just an empty result when running

docker-compose up

The solution to use absolute imports instead of relative in the volume declaration so that the final docker-compose would like as this:

version: '3'

services:
  myserver:
    restart: unless-stopped  
    volumes:
      - "home/user/app:/app"

Upvotes: 2

rustyx
rustyx

Reputation: 85462

Just want to add that if you're developing on Windows, you should explicitly allow Docker to access your C: drive. Until you do that, any mapped volumes will appear as empty.

If running via Hyper-V (Docker for Windows):

  • Go to Settings -> Shared Drives, check "C:"   (source)

If running via VirtualBox:

  • VBoxManage sharedfolder add default --name c --hostpath /c --automount (source)

Upvotes: 6

numbers1311407
numbers1311407

Reputation: 34072

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.

Upvotes: 18

Carlos Rafael Ramirez
Carlos Rafael Ramirez

Reputation: 6234

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

Upvotes: 2

Related Questions