docker
Volumes not updating from hosts from versions > 4.32
Description
We can make changes to code on versions <= 4.32 but when we upgrade to any of the new versions no changes occur because the volume is not syncing with the host.
Reproduce
here’s my script for creating volumes docker volume create --driver local --opt type=none --opt device=/var/www --opt o=bind www docker volume create --driver local --opt type=none --opt device=/var/pgsql --opt o=bind pgsql sudo chown -R $USER:wheel /var/www sudo chown -R $USER:wheel /var/pgsql
here’s some of my composer file volumes: www: external: true pgsql: external: true
services: php-fpm: container_name: php-fpm restart: always build: context: . dockerfile: ./php/DockerFile ports:
- “9000:9000” volumes:
- type: volume source: www target: /var/www volume: nocopy: true
httpd: container_name: httpd restart: always build: context: . dockerfile: ./httpd/DockerFile ipc: host privileged: true volumes:
- type: volume source: www target: /var/www volume: nocopy: true
- ./logs:/usr/local/apache2/logs:consistent ports:
- “80:80”
- “443:443” depends_on:
- php-fpm
Expected behavior
Should work like previous versions where you can make changes on the host and it updates on the container
docker version
Client:
Version: 27.2.0
API version: 1.47
Go version: go1.21.13
Git commit: 3ab4256
Built: Tue Aug 27 14:14:45 2024
OS/Arch: darwin/arm64
Context: desktop-linux
Server: Docker Desktop 4.34.0 (165256)
Engine:
Version: 27.2.0
API version: 1.47 (minimum version 1.24)
Go version: go1.21.13
Git commit: 3ab5c7d
Built: Tue Aug 27 14:15:41 2024
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.7.20
GitCommit: 8fc6bcff51318944179630522a095cc9dbf9f353
runc:
Version: 1.1.13
GitCommit: v1.1.13-0-g58aa920
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
Client:
Version: 27.2.0
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.16.2-desktop.1
Path: /Users/eamon.straughn/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.29.2-desktop.2
Path: /Users/eamon.straughn/.docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.34
Path: /Users/eamon.straughn/.docker/cli-plugins/docker-debug
desktop: Docker Desktop commands (Alpha) (Docker Inc.)
Version: v0.0.15
Path: /Users/eamon.straughn/.docker/cli-plugins/docker-desktop
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: /Users/eamon.straughn/.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.25
Path: /Users/eamon.straughn/.docker/cli-plugins/docker-extension
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.5
Path: /Users/eamon.straughn/.docker/cli-plugins/docker-feedback
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.3.0
Path: /Users/eamon.straughn/.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/eamon.straughn/.docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.13.0
Path: /Users/eamon.straughn/.docker/cli-plugins/docker-scout
Server:
Containers: 9
Running: 8
Paused: 0
Stopped: 1
Images: 30
Server Version: 27.2.0
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: runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version: 8fc6bcff51318944179630522a095cc9dbf9f353
runc version: v1.1.13-0-g58aa920
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
cgroupns
Kernel Version: 6.10.4-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: aarch64
CPUs: 10
Total Memory: 15.6GiB
Name: docker-desktop
ID: 5c7b8fec-8175-440b-859d-1385455a10e3
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/eamon.straughn/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
29CD53F1-757D-4C7A-9A73-BB455ED91723/20240912114209
Additional Info
4.32 and previous works perfectlt
I experience the same issues in docker desktop since >= 4.33 on my Mac with M1 cpu and it seems to be related to symlinks as far as my tests went.
Reproduce
The compose.yml looks like this
services:
mount:
image: alpine
environment:
- TZ=Europe/Berlin
volumes:
- /Users/hendrik/Webserver/test:/var/www/html:consistent
tty: true
I have a single text file in this folder
/var/www/html # ls
test.txt
/var/www/html # cat test.txt
1234
Then I created a symlink on the host system to this file and can access it inside the container ln -s test.txt link
/var/www/html # ls
link test.txt
/var/www/html # cat link
1234
I then deleted the symlink on the host system. Inside the container it looks like the symlink is not available anymore but can still be accessed
/var/www/html # ls
test.txt
/var/www/html # cat link
1234
Also I tried to create the file named link from within the container. There is no error but the file is also not created
/var/www/html # touch link
/var/www/html # ls
test.txt
Expected Behaviour
When Docker Desktop is downgraded to 4.32.0 the above tests work as expected. If the symlink file is deleted or changed on the host system it reflects immediately in the container.
/var/www/html # ls
test.txt
/var/www/html # cat link
cat: can't open 'link': No such file or directory
@bsousaa any movement on this. Literally upgraded to the latest version of docker and the problem still persist. It's not just on M1s but on M3 Max as well, seems Macs are affected by this bug. Can't make any edits on host and it sync to container at all, I've just had to downgrade to 4.32 again on my new mac
It seems this issue has been resolved with 4.35.0 (https://docs.docker.com/desktop/release-notes/#4350)
The described steps above are now working as expected again.
Tested on 4.36 this bug is still causing an issue, we're stuck on 4.32 as a result
This is still an issue in 4.37
See also
https://github.com/docker/for-mac/issues/7421 https://github.com/docker/for-mac/issues/7438
@bsousaa I don't feel like docker have even attempted to solve this issue. it's in all versions from 4.32 and we cannot upgrade our systems to use the latest and are missing vital updates. Please can someone pay this ticket more attention.
Still an issue in 4.38
See also
https://github.com/docker/for-mac/issues/7421 https://github.com/docker/for-mac/issues/7438
@bsousaa @KatTomrushka any updates on this? Those of us that rely on Docker noticing changes to files on the host side have not been able to update since Docker version 4.32. Thanks!
@bsousaa It maybe helpful to compare a working and non-working version. So, I did the same steps on 4.32.1 and 4.39.0. That is, startup a Django devserver in a container and change code on the host - which triggers a server re-start (noticing code change) on 4.32.1 but not on 4.39.0
Here's the two diagnostics:
- version 4.32.1 - works
1B2C2887-C8F3-4B57-A8F5-76189EBD29C9/20250321081239
- version 4.39.0 - does not work
1B2C2887-C8F3-4B57-A8F5-76189EBD29C9/20250321082213
@eamon-straughn @bnomis I tried to reproduce this issue with 4.42 by creating a volume like described in the original post pointing to /var/www and creating and changing text files, and symlinks on the host. The changed data is always visible from inside the container and vice versa.
Do you also experience syncing problems when you just do a direct bind mount without using a local volume?
The Dockerfile from the original post references two other Dockerfiles that are not available to me. Can you maybe provide me with a simplified example on how to reproduce the issue, either with a minimal Dockerfile or where you mount a local volume into a container and post the exact commands that lead to the problem?
@aheck In my case, I'm mounting a directory from my Mac into a Docker container, changes to files on the Mac are not seen in Docker. It worked in every version of Docker before 4.33.
@bnomis That means when you have a directory e.g. named synctest in your home directory and you do something like:
docker run -it --rm -v /Users/$USER/synctest:/synctest alpine /bin/sh
you cannot see changes you do from the host inside the container?
@bnomis That means when you have a directory e.g. named synctest in your home directory and you do something like:
docker run -it --rm -v /Users/$USER/synctest:/synctest alpine /bin/shyou cannot see changes you do from the host inside the container?
This is correct. Changes made on the host does not change in the container. We're stuck on 4.32.1 as a result as every update since have somewhat lost this functionality.
@eamon-straughn @bnomis I still can't reproduce it locally.
- Did you ever reset Docker Desktop?
- Do you have synchronised file sharing enabled or disabled?
- Do you use a non-standard filesystem for the host locations you share with the container?
It seems to me like there is some other setting or special condition at work that triggers the problem.
Yeah I reseted Docker Desktop with each new version, then ran the build script.
here’s my script for creating volumes docker volume create --driver local --opt type=none --opt device=/var/www --opt o=bind www docker volume create --driver local --opt type=none --opt device=/var/pgsql --opt o=bind pgsql sudo chown -R $USER:wheel /var/www sudo chown -R $USER:wheel /var/pgsql
Nothing special on file sharing as it uses local driver. Just simple mac filesystem, never was an issue until after 4.32
@eamon-straughn @bnomis
Can you please send me the output of the following script?
#!/bin/sh
set -e
SHARED_DIR="$HOME/synctest"
mkdir -p $SHARED_DIR
rm -f $SHARED_DIR/host_file.txt
# start container in the background
docker run -d --name synctest_container -v "$SHARED_DIR":/synctest alpine tail -f /dev/null
# create file on the host
echo "Hello from host!" > "$SHARED_DIR/host_file.txt"
# read from inside container
docker exec synctest_container cat /synctest/host_file.txt
# clean up
echo "Cleanup..."
docker stop synctest_container
docker rm synctest_container
4.32.1 Unable to find image 'alpine:latest' locally latest: Pulling from library/alpine 6e174226ea69: Download complete Digest: sha256:4bcff63911fcb4448bd4fdacec207030997caf25e9bea4045fa6c8c44de311d1 Status: Downloaded newer image for alpine:latest 5a57dfbbddcf8713231c8bf4c7bb215b4e943628e29a2f0b0ab039f33a8d7ebe Hello from host! Cleanup... synctest_container synctest_container
4.44.3 Hello from host! Cleanup... synctest_container synctest_container
Seems after some testing myself that this issue seems to be resolved in 4.44.3 will do some more testing and close this issue once i've confirmed.
@aheck thanks for getting back, synchronised file sharing is disabled, the host file system is standard macOS
Running your test script
$ ./tester.sh # 4.44.3
bb940bc82c0ca8421d702cb1f473ef648a52483ddb5a5e9fd1669b19a20ba121
Hello from host!
Cleanup...
synctest_container
synctest_container
$ ./tester.sh # 4.32.1
535a78dbc60111b788b2118ce63e691c7a2eb1790f7b7c672a6bafefecdef1a1
Hello from host!
Cleanup...
synctest_container
synctest_container
The issue is not reading from the host. The issue is when files are modified on the host, Docker versions after 4.32.1 do not notice the change.
I've tried but failed to make a small reproduction so I will describe the situation. We have a large Django project. The Django dev server is checking file modification times, when a file is modified, a reload is triggered. After 4.32.1 file modifications on the host do not get noticed in Docker. It's a big project with lots of files and several mount points. I wonder if we're just running up against some (reduced) limit or something post 4.32.1. I tried making a small test case but it works as expected - hence my guess it's related to size/number etc.
I can confirm that 4.44.3 the issue seems to be resolved for me and my developers, will leave ticket open for @bnomis until his is fixed
@bnomis Which filesystem are you using? VirtioFS, grpcFUSE or osxfs?
Django seems to use either stat polling or the Python watchdog module (if it is installed). The watchdog module uses inotify on Linux or its equivalents on other platforms.
When I run this script from the watchdog project page in a Linux container and touch or change a file in the same directory it prints filesystem events with every filesystem except for osxfs:
#!/usr/bin/env python3
import time
from watchdog.events import FileSystemEvent, FileSystemEventHandler
from watchdog.observers import Observer
class MyEventHandler(FileSystemEventHandler):
def on_any_event(self, event: FileSystemEvent) -> None:
print(event)
event_handler = MyEventHandler()
observer = Observer()
observer.schedule(event_handler, ".", recursive=True)
observer.start()
try:
while True:
time.sleep(1)
finally:
observer.stop()
observer.join()
Interestingly, I get filesystem events for osxfs when I test it with Docker Desktop 4.32.1