docker
Synchronized file shares stalling and "locks" the entire environment
Description
Upon creating a file share for my project it will scan the files and work for a while, then it will silently error out and everything in Docker will stop working until the tile share is deleted.
Reproduce
- Create a share for the workspace.
- Start the Docker Compose workspace.
- Do some development.
- Notice how everything stops.
- Go into the settings, and see errors like
Host: var/cache/dev/translations/catalogue.pt_BR.Y83vERT.php unable to create file: unable to relocate staged file: file exists
It should be expected that files in cache and tmp directories are purged occasionally while in development.
Expected behavior
It should be faster than without. Or at least as slow as without file shares.
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/arm64
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:04 2024
OS/Arch: linux/arm64
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
```bash
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/nikbr/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.27.0-desktop.2
Path: /Users/nikbr/.docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.29
Path: /Users/nikbr/.docker/cli-plugins/docker-debug
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: /Users/nikbr/.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.23
Path: /Users/nikbr/.docker/cli-plugins/docker-extension
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.4
Path: /Users/nikbr/.docker/cli-plugins/docker-feedback
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.1.0
Path: /Users/nikbr/.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/nikbr/.docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.8.0
Path: /Users/nikbr/.docker/cli-plugins/docker-scout
WARNING: Plugin "/Users/nikbr/.docker/cli-plugins/docker-scan" is not valid: failed to fetch metadata: fork/exec /Users/nikbr/.docker/cli-plugins/docker-scan: no such file or directory
Server:
Containers: 26
Running: 13
Paused: 0
Stopped: 13
Images: 53
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: aarch64
CPUs: 9
Total Memory: 23.44GiB
Name: docker-desktop
ID: 4bacd5ea-52d7-4544-a700-b29136ca8a38
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/nikbr/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
39263439-8ED3-425A-A6C1-A4B1DD929F05/20240513142557
### Additional Info
_No response_
Hi @NiklasBr, the file exists error on the host is typically due to a case conflict. Specifically, files that can co-exist on Linux's case sensitive filesystems can't co-exist on macOS' case-insensitive filesystem. You can exclude these problematic files using a .syncignore file (see this comment for an example). A similar approach for your cache directories might help.
That being said, the existence of case conflicts shouldn't cause the sync to halt. Looking at the diagnostic bundle you sent (thanks!), the synchronization appears to be operating. Can you clarify what you mean by "everything stops?"
By "everything stops" I mean the container(s) become unresponsive, they do not respond to HTTP requests, you cannot connect to the CLI, or otherwise interact with them. It's like they are hard blocked by some process.
i have this same issue, and when i modify a file it does not get modified inside the container even if i delete the container and regenerate it again, i need to restart docker entirely to get my modification inside the container
Thanks for the clarification. Do either of you have a reproducer or list of tools/frameworks that you could share that might trigger the issue? Synchronized File Shares are fairly orthogonal to anything that might freeze a container, so it may be an unrelated issue, but I wouldn't rule anything out yet.
If possible, it would also be very helpful to know if the freezing issue happens with Docker Desktop 4.29.
At the moment we are using a variant of https://github.com/pimcore/skeleton/
I'm not 100% sure I'm having the same issue, but I've noticed that containers keep becoming unresponsive since updating to 4.30.0.
@xenoscopic any progress?
It's growing more and more problematic because even though no containers are running it is impossible to delete shares.
Hey @NiklasBr, I haven't had a chance yet to investigate further. Is there any chance you'd be available for a Zoom call to try debugging the issue directly?
it is impossible to delete shares.
Also, can you clarify whether the "Delete" button for the shares is greyed out or if it simply has no effect?
Sure invite me at [email protected].
It's gray, even when I stop all containers and Quit and re-launch the application:
In this case it looks like the Delete button is greyed out because of the containers using the share (which are currently stopped, but still have the share bind-mounted).
I'll send you an email to schedule a debug session.
This may be related to and/or a duplicate of docker/for-mac#7288, but I'll leave it open until more information is available.
@hbazan-pp If you want to disable Synchronized File Shares, you can delete them, in which case they won't be used. If you want to disable all file sharing (e.g. VirtioFS-based sharing), then you can delete the authorized file sharing paths in the Settings > Resources > File sharing pane under "Virtual file shares". Note that doing both of these will disable your ability to bind-mount host filesystem locations.
I didn't enable file sharing but I'm getting to this state of docker desktop unresponsive until I delete all file shares and restart it. I tried different things and that is the only one that brings the env back up. I had to do it manually. Is there a command to run kindof docker volume prune? All I have is some volumes mapped on docker-compose files, what do you mean by "bind-mount host filesystem locations"?
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
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/nikbr/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.29.2-desktop.2
Path: /Users/nikbr/.docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.34
Path: /Users/nikbr/.docker/cli-plugins/docker-debug
desktop: Docker Desktop commands (Alpha) (Docker Inc.)
Version: v0.0.15
Path: /Users/nikbr/.docker/cli-plugins/docker-desktop
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: /Users/nikbr/.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.25
Path: /Users/nikbr/.docker/cli-plugins/docker-extension
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.5
Path: /Users/nikbr/.docker/cli-plugins/docker-feedback
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.3.0
Path: /Users/nikbr/.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/nikbr/.docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.13.0
Path: /Users/nikbr/.docker/cli-plugins/docker-scout
WARNING: Plugin "/Users/nikbr/.docker/cli-plugins/docker-scan" is not valid: failed to fetch metadata: fork/exec /Users/nikbr/.docker/cli-plugins/docker-scan: no such file or directory
Server:
Containers: 27
Running: 12
Paused: 0
Stopped: 15
Images: 65
Server Version: 27.2.0
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
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: 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: 9
Total Memory: 23.44GiB
Name: docker-desktop
ID: 4bacd5ea-52d7-4544-a700-b29136ca8a38
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/nikbr/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
Can anyone confirm if they're still seeing this issue with Docker Desktop 4.34.2? There were fixes introduced to Resource Saver in 4.34.2 that may have resolved this issue.
I still want to disable this feature, I don't need it, and it is randomly causing issues, from time to time all is locked until I delete each fileshare manually, one by one. I did remove all folders from VirtioFS settings but if I start any container with mounted volumes it ends up filling up the list of shares.
@hbazan-pp You can disabled it by deleting all Synchronized File Shares. If you go to the file sharing pane, you can individually expand and delete each share:
You will need to make sure the share isn't in use by any containers (by deleting them) before deleting the share.
yes, that's what I do, but the next time I run a container with a mounted volume it will show up again on that list.
@hbazan-pp It may be that you're affected by docker/for-mac#7365. Can you check that "Manage Synchronized file shares with Compose" is disabled under the "Features in development" pane?
If it's checked, that could be what's causing the share to reappear.
now I cannot start the containers:
Error response from daemon: Mounts denied:
The path /Users/.../... is not shared from the host and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> Resources -> File Sharing.
See https://docs.docker.com/desktop/settings/mac/#file-sharing for more info.
I did remove all folders from VirtioFS settings
This is most likely the reason - since SFS is now disabled, Docker Desktop will default back to VirtioFS. You can add these back under the "Virtual file shares" section in file sharing. The default locations are as follows:
I'm going to close this for now because I think this was likely fixed by the Resource Saver fixes in Docker Desktop 4.34.2. However, if this issue recurs, please don't hesitate to comment and then we can re-open.