Docker bind mount is deleting container's files

General
1

Isn’t this plain wrong?

    volumes:
      - <path/to/your/config>:/etc/nginx
      - <path/to/your/certs>:/etc/ssl/private

When you start your container through docker-compose, it will automatically create the folder and populate it with the contents of the container.

From: How to set up an easy and secure reverse proxy with Docker, Nginx & Letsencrypt

A bind mount will “overwrite” the content of the docker container. Right?!

I’ve tested it and it did “overwrite” container’s! Because this is the error I got from Nginx container (and it exited immediately):

docker nginx [emerg] 1#1: open() “/etc/nginx/nginx.conf” failed (2: No such file or directory)

So I wonder then if I’m not understanding that article properly? Or it’s wrong? According to the article, the expectation is, the container should start and it should load config files into the host’s volume!

Now you should have a config folder on your host. Changing to that directory, you should see a bunch of different files and a folder called conf.d.

Of course it’s been 4 years since that article was written, so it could be also due to some changes in how Docker works since then?

1 Like
2

I think I’ve got my answer here:

“a bind mount won’t copy the container contents to the host automatically, unlike a named volume”

3

Only named volumes copy existing content from the target directory back into the volume, and only when the volume is empty. So it’s a one shot operation. In case you update the image and the files change, your volume will not copy over the changed files.

Your example does not use volumes (=handle), it uses binds (=host path). The copy on first use operation is not available for binds.

While volumes are listed with docker volume ls, binds are not.

Tis is not true for binds. This is only true for (named) volumes. Though, you are using binds, so there is no copy on first use.

Update: I missed your second post. Just ignore my post.

1 Like
4

To avoid overwriting the SSL certificate file that is already present in the container, you can mount the SSL certificate directory as a read-only volume. This will prevent any modifications to the mounted directory and preserve the existing SSL certificate file inside the container.

Here’s an example of how you can mount the SSL certificate directory as a read-only volume:

version: '3'
services:
  web:
    image: nginx
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./ssl:/etc/nginx/ssl:ro
    environment:
      - NGINX_HTTPS=true
      - NGINX_SSL_CERT=/etc/nginx/ssl/cert.crt
      - NGINX_SSL_KEY=/etc/nginx/ssl/key.key

In this example, we’ve added the :ro (read-only) option to the end of the volume definition to indicate that the mounted directory should be read-only. This means that any modifications to the SSL certificate file inside the container will be blocked, and the existing file will be preserved.

Note that this approach assumes that the SSL certificate file already exists in the container at the specified location. If the file doesn’t exist, you’ll need to create it manually or use a different approach to mount the SSL certificate.

via ChatGPT, this solution works. ro mount will not deleting container’s files.