Synchronized file shares stalling and "locks" the entire environment about for-mac HOT 15 OPEN

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?"

from for-mac.

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.

from for-mac.

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

from for-mac.

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.

from for-mac.

At the moment we are using a variant of https://github.com/pimcore/skeleton/

from for-mac.

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.

from for-mac.

@xenoscopic any progress?

It's growing more and more problematic because even though no containers are running it is impossible to delete shares.

from for-mac.

for me i rolled back to version 4.24 that does not have those issues.

from for-mac.

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?

from for-mac.

Sure invite me at [email protected].

It's gray, even when I stop all containers and Quit and re-launch the application:

from for-mac.

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.

from for-mac.

This may be related to and/or a duplicate of #7288, but I'll leave it open until more information is available.

from for-mac.

is there a way to completely disable file shares?

from for-mac.

@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.

from for-mac.

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"?

from for-mac.