Closed alcohol closed 1 year ago
Same here with M1Max, after updating to 4.6.0 Docker is starting forever.
The same for me on M1 MBP
The same for me on Intel chip, then i reinstall old version 4.5.0(74594) docker engine is unable to start too.
See https://github.com/docker/for-mac/issues/6244#issuecomment-1073446399 if you are in urgent need of recovery.
See #6244 (comment) if you are in urgent need of recovery.
Thanks for sharing, will give that a try when I get back home today.
See https://github.com/docker/for-mac/issues/6244#issuecomment-1073446399 if you are in urgent need of recovery.
Didn't work for me.
The same for me on Intel chip, then i reinstall old version 4.5.0(74594) docker engine is unable to start too.
uninstall and run The following command
rm -rf ~/Library/Group\ Containers/group.com.docker
rm -rf ~/Library/Containers/com.docker.docker
rm -rf ~/.docker
then, reinstall docker desktop. it useful for me. but will clean all containers. @alcohol @mikhin
I cleaned up all the docker related directories I could find. Then did a reinstall but it still got stuck on starting and then went into stopped state again. I then quit docker desktop and started it again, and that seemed to do the trick finally. Unfortunately, no idea what was wrong/misconfigured/broken and what actually fixed it now.
I have cleaned all my directories, uninstalled, reinstalled, quit and re-opened docker desktop, but still have not gotten it to work on my intel chip. I will keep trying daily until it works or until the end of time. Whichever comes first.
I've hit the same issue when I enabled the new feature. My Docker install is no longer functioning.
The same for me on Intel chip, then i reinstall old version 4.5.0(74594) docker engine is unable to start too.
uninstall and run The following command
rm -rf ~/Library/Group\ Containers/group.com.docker rm -rf ~/Library/Containers/com.docker.docker rm -rf ~/.docker
then, reinstall docker desktop. it useful for me. but will clean all containers. @alcohol @mikhin
Ok, after multiple days of trying these commands it does seems to work. Now this time before enabling VirtioFS, I enabled the new Virtualization framework first and then enabled VirtioFS and everything is running.
Simple steps to disabling crashing virtiofs ....
~/Library/Group\ Containers/group.com.docker/settings.json
useVirtualizationFrameworkVirtioFS
to false
In my case the actual culprit was the fact that gFUSE doesn't care if a shared folder doesn't exist, but virtiofs does so if any of the shared folders listed in the config is missing, it will fail to start.
The above worked for me too! Might be worth chucking in some exception handling into docker desktop for folders that dont exist, as there was no descriptive message in the UI to indicate why
Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
comment.
Stale issues will be closed after an additional 30 days of inactivity.
Prevent issues from auto-closing with an /lifecycle frozen
comment.
If this issue is safe to close now please do so.
Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale
No luck with the latest version 4.12.0
. Enabling VirtioFS make docker restarting forever on an M1 Macbook.
No luck with the latest version
4.12.0
. Enabling VirtioFS make docker restarting forever on an M1 Macbook.
Same here.
No luck with the latest version
4.12.0
. Enabling VirtioFS make docker restarting forever on an M1 Macbook.
Same with Intel Macbook. Log last lines are from com.docker.virtualization before getting "still waiting docker..." messages:
accepted connection on AF_VSOCK, forwarding fd to filesystem-fd.sock
dialing filesystem-fd.sock: dial unix filesystem-fd.sock: connect: no such file or directory
No luck with the latest version
4.12.0
. Enabling VirtioFS make docker restarting forever on an M1 Macbook.Same with Intel Macbook. Log last lines are from com.docker.virtualization before getting "still waiting docker..." messages:
accepted connection on AF_VSOCK, forwarding fd to filesystem-fd.sock
dialing filesystem-fd.sock: dial unix filesystem-fd.sock: connect: no such file or directory
Weird. After some (unrelated) reboots on the computer, the virtiofs was enabled and started working!! Really no idea what gave it the permissions to the sockets, but now it works for me and it's quite fast (almost docker-sync fast).
Same here on an M1 mac, enabling it breaks Docker Desktop and it cannot start properly. https://github.com/docker/for-mac/issues/6241#issuecomment-1116214506 fixed the issue after a reboot
Within docker desktop settings all of my file sharing folders exist so I have no idea what's causing this issue
Same on macbook m1 pro. Docker falls completely unusable. Such a shame because when it's working VirtioFS is just amazing ! Hope we will find what is causing such pain.
Is there any where we can see logs of what docker fails to start with the VirtioFS options enabled ?
/remove-lifecycle stale
In my case the actual culprit was the fact that gFUSE doesn't care if a shared folder doesn't exist, but virtiofs does so if any of the shared folders listed in the config is missing, it will fail to start.
Every shared folder are existing in my host machine. I even remove every other folders than /Users
And still not working. :'(
I had the same issue last week on my m1, had to revert back by editing settings.json
.
Tried again today, now it works flawlessly. Either 4.13.0
or upgrading to macOS ventura fixed it for me, can't really tell since I installed both at the same time.
M1 MBP latest Ventura 13.0.1, latest docker 4.14
, if virtiofs is enabled, Docker Desktop does not boot, flipping it to false in settings.json helps me boot, but I can find no way to get it to work.
Edit: Got it working on mine! I looked more carefully into settings.json, as I had migrated recently from an older laptop. I found a directory I did not have on the new Mac listed in filesharingDirectories
, removed it and VirtioFS started. And it is indeed much faster!
Surely a missing directory should produce some sort of obvious error somewhere ;)
Simple steps to disabling crashing virtiofs ....
- Stop docker desktop
- Edit
~/Library/Group\ Containers/group.com.docker/settings.json
- Change
useVirtualizationFrameworkVirtioFS
tofalse
- Profit!
In my case the actual culprit was the fact that gFUSE doesn't care if a shared folder doesn't exist, but virtiofs does so if any of the shared folders listed in the config is missing, it will fail to start.
gRPC FUSE allows both non-existent folders as well as file sharing directly to a file instead of folder. In my case the hanging was caused by sharing a file in the docker settings instead of the containing folder.
There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale
comment.
If not, this issue will be closed in 30 days.
Prevent issues from auto-closing with a /lifecycle frozen
comment.
/lifecycle stale
I think this is still an issue https://youtrack.jetbrains.com/issue/RIDER-93564
Closed issues are locked after 30 days of inactivity. This helps our team focus on active issues.
If you have found a problem that seems similar to this, please open a new issue.
/lifecycle locked
I enabled the feature mentioned here https://twitter.com/Docker/status/1504144282688659457 and since then the Docker engine has been unable to start. I tried to reset to factory defaults but this feature no longer works. I tried to uninstall through the docker troubleshoot -> uninstall, but this also does not work. I manually removed docker.app from applications and rebooted and tried installing again using the latest versions from https://docs.docker.com/desktop/mac/install/, but with no effect. The docker engine is still unable to start and all troubleshooting options are not working.
I am not sure why it is asking about a HTTPS proxy. I do not use any proxies in my local network.
Expected behavior
Docker engine starts.
Actual behavior
Docker engine is unable to start.
Information
Output of
/Applications/Docker.app/Contents/MacOS/com.docker.diagnose check