Docker volume with bind mount option directory still exists after volume and directories and container removed

General
, , ,
1

I am using Docker to run a container with WordPress. I created a bind mount from the directory /Users/ael-korc/Inception/srcs/requirements/wordpress/wordpress_files on my host machine to the directory /var/www/html/wordpress_files in the container. When I delete the volume and the directory on my host machine and I removed the containers, the directory /var/www/html/wordpress_files still exists in the new containers, even though I removed the volumes and the data from both sides.
[EDIT]

wordpress:
   build: ./requirements/wordpress
   container_name: wordpress
   volumes:
     - wp_vol:/var/www/html/wordpress
   env_file:
     - .env
 nginx:
   build: ./requirements/nginx
   env_file:
     - .env
   container_name: nginx
   volumes:
     - wp_vol:/var/www/html/wordpress
   ports:
     - '443:443'
   depends_on:
     - wordpress

volumes:
 wp_vol:
   driver: local
   driver_opts:
     type: noun
     o: bind
     device:/Users/ael-korc/Inception/srcs/requirements/wordpress/wordpress_files

docker container inspect

[
    {
        "CreatedAt": "2023-08-04T19:42:39Z",
        "Driver": "local",
        "Labels": {
            "com.docker.compose.project": "srcs",
            "com.docker.compose.version": "2.13.0",
            "com.docker.compose.volume": "wp_vol"
        },
        "Mountpoint": "/var/lib/docker/volumes/srcs_wp_vol/_data",
        "Name": "srcs_wp_vol",
        "Options": {
            "device": "/Users/ael-korc/Inception/srcs/requirements/wordpress/wordpress_files",
            "o": "bind",
            "type": "noun"
        },
        "Scope": "local"
    }
]

Another thing:
Due to my school limited access to the IMAC root directories, I can’t access to "Mountpoint": "/var/lib/docker/volumes/srcs_wp_vol/_data"
So I think that Mountpoint path is a third party that saves the data in it.

2

Let me start off with: something doesn’t add up here.

Please share how you did all of this (as in exact commands, and if compose was used, the content of the compose file). This allows us to see what and how things have been done. Please do not redact anything except domain names, public ips, usernames, passwords.

Furthermore, also share docker container inspect of the new container.

3

I edited my post, If you want to know something else let me know.
I hope this helps.

4

The compose file configuration for the volume, and the actual used volume use different host paths:
– wp_vol in compose: /home/rockyou/wordpress_files
– srcs_wp_vol volume: /Users/ael-korc/Inception/srcs/requirements/wordpress/wordpress_files

Apparently your compose file is either in a folder called srcs, or you specified -p srcs.

Furthermore, it doesn’t make sense that the volume srcs_wp_vol has a different host path than your compose file declares.

It looks like you created the volume at one point, changed the host path in the device setting and expected the configuration to be used from then on. Though, volumes are immutable: once created, their configuration will not be updated, unless they are removed and re-created using the new values.

It is literately the mount point for the host path you defined in device:.
The volumes source (with bind it’s the host path in “device”) is mounted when at least one container that uses that volume is started, and unmounted when it’s stopped. This is not your problem.

If you remove a named volume backed by a bind with docker volume rm, it will remove its declaration and configuration, but it will not remove the data in the host folder. So if you delete a volume, without emptying the host folder, and re-create it pointing to the same host folder, of course the existing data will be available in the volume inside the container.

5

Apologize, I edited the post again, The path is actually /Users/ael-korc/Inception/srcs/requirements/wordpress/wordpress_files in the docker compose.
I tested the project on my laptop where I have the privileges and everything works fine when I delete the volumes and the data inside of them, So apparently the problem from the limited access in my school’s computers, the data persist until I purge data from docker desktop.
Thank you.

6

That still doesn’t make sense. When a volume backed by a bind is used, the host folder is bind mounted into the volume’s /var/lib/docker/volumes/{volumename}/_data` folder, and from there bind mounted into the container path. All of them point to the same inode in the file system. The volume backed by a bind does not hold a copy of the host folder somewhere, instead if it uses the host folder. So if the data was deleted in the host folder, there is absolute no way a new container using the same host folder as volume could be able to see data from the old container.

1 Like