Problem updating docker from 4.71.0 to 4.72.0

Hi guys!

I’ve tried to update Docker today but i got an error on windows11 with the following log to it:

fork/exec C:\Users\user\AppData\Local\Temp\DockerDesktopUpdates\Docker Desktop Installer (225998).exe: The requested operation requires elevation.

I updated it multiple times before with no issue whatsoever. Is there a fix to it?

Thanks in advance!

There was another issue related to elevation. Someone wrote it would likely be fixed in 4.72. The issue is still open, but if it was fixed (I don’t see it in the release notes), it is possible that it introduced a new issue.

https://github.com/docker/desktop-feedback/issues/335#issuecomment-4388817034

But there is this in the new features list:

  • New installations of Docker Desktop for Windows have a choice between per-user (Beta) or all-user installs.

It is for new installations, but I can imagine it breaking something for updates.
I also updated my Docker DEsktiop on Windows, but I didn’T experience the linked issue either and I had 4.58. Upgrading to 4.72 worked without any problem.

If you have no data in Docker Desktop, you could try reinstalling. That would confirm that new installations works.

Or you can open a new ticket on GitHub and link the one I linked above as possible related issue.

I have exactly the same problem.

But I have many projects running on Docker with multiple containers. If I download a new release and install it, would it just update Docker, or would it erase everything?

close Docker and quit. Search for Docker and right-click Run as Administrator. Docker will start, then do the upgrade.

Yep that does the trick nicely, thanks. I’m not sure why it’s not prompting the elevated UAC prompt for it to update this time though? Previous updates all went through OK.

It worked thanks! Such an easy workaround hehe

Not sure, but I thought you would also uninstall the old version first. You wouldn’t lose anything if you don’t store data on the container filesystems and use bind mounts instead of local volumes or local volumes with a custom host path in a WSL distro where WSL integration is enabled. That way you don’t depend on data stored in Docker Desktop and you could recreate everything if you have compose files. Just an idea for the future.

It is not important now. Running Docker Desktop as administrator was a good idea. :+1:

at first i just installed a new version, next update i closed docker and run it as admin. no problems updating with elevated privliges

I found the solution was to navigate to the file in ApData and run it as admin. It installed the new version but my existing docker set-ups remained in place.

Today I have updated the Docker Desktop on my notebook with elevated privileges and lost all my data kept on Docker volumes. So, I would not recommend this update unless fresh install.

Can you check the location of the Disk image location in “Settings → Ressources”?
I can only guess that it points to a different path and thus does not use the old existing set of virtual disks. From what I remember the path should point to a folder underneath your user’s appdata folder. I am not on a Windows machine right now, so I can’t paste the exact path.

How did you install the update? From within Docker Desktop, or did you download from the website and install manually?

Got the same problem, had to update with elevated privilege, but today i got a new update to version 4.74.0 (227015) and it went just fine.

I updated to 4.75.0 and I got stuck on the starting screen here is how I fixed it https://medium.com/@0l4m1de/docker-desktop-4-75-0-stuck-on-starting-docker-engine-on-windows-11-heres-the-fix-a113077dfb8b

Your blog post about simply deregistering the docker desktop related distributions, fails to mention a not that unimportant fact: if an existing docker-desktop-data distribution existed and get unregistered, the existing state will be lost: all images, containers, volumes…

Furthermore, you claim that the update broke thousands of Windows 11 installs. Could you be so kind to share the source for this?

You’re absolutely right and that’s an important caveat, thank you. I’ve updated the article with a warning and backup steps before the unregister commands. In my case docker-desktop-data didn’t exist so I didn’t encounter data loss.