Device Bind Mount Disconnecting from Container Directory

I primarily do my development in networks setup by compose files, where I map a specific local folder into a specific folder on my container. I have noticed recently that I am having an issue consistently where after a short period of time my container will stop receiving the changes for files located inside the mount.

I am trying to figure out where to report this issue, as I am not sure its Desktop for Mac related, or if its just the Engine on Mac.

Here is how my compose file is setup:

version: "3"

services:
    frontend:
        image:           inductiveautomation/ignition:8.1.16
        container_name:  frontend
        ports:
        - "80:8088"
        volumes:
        - project_data:/usr/local/bin/ignition/data

volumes:
    project_data:
        driver: local
        driver_opts:
            type: none
            device: "myProjectPath/Data"
            o: bind

At first everything looks fine and works, however after a while I can make changes in VS Code on my Mac directly:
(Note the extra folders)

├── views
│   ├── Gemba Boards
│   │   ├── Blends
│   │   ├── Embedded Views
│   │   ├── Filter
│   ├── General

That do not make their way into the container if I actually attach to it to look at its file contents

├── views
│   ├── Gemba Boards
│   │   ├── Blends
│   ├── General

Potentially relevant note is that I am also using git, and this typically happens when I am switching between git branches. So it may be something to do with the large amount of files being changed at once?

Restarting the container does not resolve this issue, however completely restarting Docker Desktop does (Which I am pretty sure is also restarting the engine, so I am not sure which thing is fixing this.)

MacOS Version: Monterey 12.4
Docker Desktop Version: 4.8.1 (78998)
Docker Engine Version: 20.10.14
Compose: v2.5.0

Any ideas are greatly appreciated! And if the solution is for me to post this somewhere else, that’s appreciated too!

I also posted this on the for-mac repo for reference (Not sure which place was correct!): Device Bind Mount Disconnecting from Container Directory · Issue #6317 · docker/for-mac · GitHub
As well as the image providers forums: Docker Bind Mount disconnecting from Container - General Discussion - Inductive Automation Forum

Looks like this can actually be easily recreated on another Mac (Video from another Developer here)

All of them. If you know which component is the problem, you can open an issue in its repository, if you don’t, the “for-*” repos are fine. If you don’t know if something is a bug or not, we can help you with that orr help you to find the cause. Thanks for the links too!

It’s “funny”, becuase it seems to me it is related to Docker Compose and not Docker Desktop, neither Docker Engine. Can you confirm the following?

First test

  • I run

    docker compose up -d
    docker compose exec frontend bash
    

    in terminal 1.

  • I change the directory to “data” and watch the files

    cd data
    watch 'ls -la'
    

    in terminal 1.

  • I run

    for i in {1..10000}; do unlink test.$((i-1)).txt || true; echo $i > test.$i.txt; echo "Created test.$i.txt"; sleep 1; done
    

    in terminal 2.

Using the above commands I can’t see any new files in terminal 1.

Then I destroy the containers and the volume:

docker compose down -v

Let’s try with Docker Compose v1. On MacOs, you can use docker-compose-v1 too.

  • I run
    docker-compose-v1 up -d
    docker-compose-v1 exec frontend bash
    
    in terminal 1.
  • I change the directory to “data” and watch the files
    cd data
    watch 'ls -la'
    
    in terminal 1.
  • I run
    for i in {1..10000}; do unlink test.$((i-1)).txt || true; echo $i > test.$i.txt; echo "Created test.$i.txt"; sleep 1; done
    
    in terminal 2.

Now I can see the files changing.

Second test:

Just start the “first test” again and when you don’t see the files changing, open a new terminal (terminal 3.) and run a standalone container without Docker Compose with voplume created by Docker compose:

docker run --rm -it -v dockertest2_project_data:/app --workdir /app bash:5.1

Note: My project name was “dockertest2”, use your own project name to have the same volume.

I don’t really understand why this is happening. I would not have thought that Docker Compose v2 would do anything else than communicating with the Docker Enfgine’s API, but it looks like Docker Compose v2 is somehow responsible for mounting the volume without proper syncronization and when I mount the same volume from an other container, that container syncronizes the filesystem so the frontend container can see it too.

I tried it with Docker Compose v2.0 too with the same result.