Bind mount not working on Docker Desktop 4.30.0 with gRPC FUSE

[thierry-stul]

Description

To reproduce the bug, bind mount a volume, e.g.

docker run --rm -it -v ./test.json:/test.json busybox /bin/sh

Then modify the "test.json" on the host. The changes are not reflected in the container. Modifying the file in the container will modify it on the host, though (so only the "host to container binding" is broken, not the "container to host binding").

This only happen on Docker Desktop 4.30.0 with gRPC FUSE file sharing implementation.
Docker Desktop 4.29.0 with gRPC FUSE works well, and Docker Desktop 4.30.0 with VirtioFS works as well.

Reproduce

1. vim test.json
2. add some content to file and save
3. docker run --rm -it -v ./test.json:/test.json busybox /bin/sh
4. (back on host) vim test.json (and modify content)
5. (in container) cat test.json (the changes are not reflected)

Expected behavior

The changes on the file "test.json" should be reflected inside the container

docker version

Client:
 Cloud integration: v1.0.35+desktop.13
 Version:           26.1.1
 API version:       1.45
 Go version:        go1.21.9
 Git commit:        4cf5afa
 Built:             Tue Apr 30 11:44:56 2024
 OS/Arch:           darwin/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.30.0 (149282)
 Engine:
  Version:          26.1.1
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.9
  Git commit:       ac2de55
  Built:            Tue Apr 30 11:48:28 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.31
  GitCommit:        e377cd56a71523140ca6ae87e30244719194a521
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    26.1.1
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.0-desktop.1
    Path:     /Users/thierry.stulemeijer/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.27.0-desktop.2
    Path:     /Users/thierry.stulemeijer/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.29
    Path:     /Users/thierry.stulemeijer/.docker/cli-plugins/docker-debug
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     /Users/thierry.stulemeijer/.docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.23
    Path:     /Users/thierry.stulemeijer/.docker/cli-plugins/docker-extension
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.4
    Path:     /Users/thierry.stulemeijer/.docker/cli-plugins/docker-feedback
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.1.0
    Path:     /Users/thierry.stulemeijer/.docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/thierry.stulemeijer/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.8.0
    Path:     /Users/thierry.stulemeijer/.docker/cli-plugins/docker-scout

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 43
 Server Version: 26.1.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e377cd56a71523140ca6ae87e30244719194a521
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.6.26-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 11.68GiB
 Name: docker-desktop
 ID: 71f601a2-090b-4925-b03f-1e8e5ecc9c6c
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/thierry.stulemeijer/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: daemon is not using the default seccomp profile

Diagnostics ID

4C6EEAC0-A4DE-4CA9-A20E-028F0FD38F38/20240508163022

Additional Info

No response

[ferminmoli]

I am having the same issue

[AngelCifuentes]

Same here in multiple configurations (Mac, Windows 10/11 too).
Must rollback to docker 4.29.0 and all fine.
I'll try changing volumen tag ":consistent", clean cachés, etc, nothing work except rollback to 4.29.0

[fermolinuevo]

Did rollback to 4.29.0 and all fine as the previous comment

[kimegede]

Experienced the same problem with @skliask with Docker desktopn 4.30.0.
Rolled back to 4.29.0

With Homebrew this can be done with:

History for docker: https://github.com/Homebrew/homebrew-cask/commits/master/Casks/d/docker.rb

$ brew install --cask https://raw.githubusercontent.com/Homebrew/homebrew-cask/cadb3aad3e1f57386fc7d2173b76feafcf1a4302/Casks/d/docker.rb

[MihaelaStoica]

Thanks for finding the issue and apologies for the inconvenience it's caused. We are working on a fix, but in the meantime the workarounds are either using VirtioFS, or downgrading to 4.29.0.

[nrhope]

Also experiencing the same problem via a mount in docker-compose.yml . Unfortunately the default VirtioFS filesystem has never worked for us ever on MacOs Sonoma 12.2.1 (Intel) when deploying from mounted autodeploy directories for Wildfly 26 or Tomcat 9, as the apps start but then continually bounce as if the deployment files are changing on the Mac host when they aren't. Hence until VirtioFS is ever fixed, gRPS fuse is critical for us. I also tried osx legacy filesystem which worked better until docker desktop went to sleep (with the leaf) but then it wouldn't start again, so that doesn't seem an option either. Will try the downgrade to 4.29.0 others in this thread have suggested.

[marcobalk-berlinger]

Have the same problem here, but using VirtioFS is not an option because of #6690
For now downgrading is the only option, which seems to work.

[RaubJo]

I also have this problem, VirtioFS doesn't work because it prepends /host_mnt to the /private filepath (#6375)

[maxcleme]

Closing this issue because a fix has been released in Docker Desktop 4.31.0. See the release notes for more details.