Synchronized file shares stalling and "locks" the entire environment #7281
Comments
|
Hi @NiklasBr, the 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. |
NiklasBr
changed the title
|
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. |
|
for me i rolled back to version 4.24 that does not have those issues. |
|
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?
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 I'll send you an email to schedule a debug session. |
|
This may be related to and/or a duplicate of #7288, but I'll leave it open until more information is available. |
|
is there a way to completely disable file shares? |
|
@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 |
|
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? |
|
|
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 #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: |
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: 
|
|
ok that works. Thanks |
|
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. |
and others
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
Host: var/cache/dev/translations/catalogue.pt_BR.Y83vERT.php unable to create file: unable to relocate staged file: file existsIt 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: de40ad0The text was updated successfully, but these errors were encountered: