Not able to run Azurite after upgraded to 4.37.1

Docker Desktop
,
1

I have been using Docker Desktop for 4 years without any problems, and always keep updating to latest version, and I have more than 7 running containers (rabbitmq, redis, elasticsearch, progress-db…), and a docker image from Microsoft called Azurite : mcr.microsoft.com-azure-storage-azurite.
I am running Docker Desktop on Windows 11 with WSL 2 integration, and running as Linux containers.

I upgraded from desktop 4.36 (or maybe 4.35) to 4.37.1.
after upgrade all my containers were removed.
I tried to run the images again, and all work excpet the azurite.
the image itself is not downloading.
When I do
docker pull mcr.microsoft.com/azure-storage/azurite

I get the error:

Using default tag: latest
Error response from daemon: failed to resolve reference "mcr.microsoft.com/azure-storage/azurite:latest": failed to do request: Head "https://mcr.microsoft.com/v2/azure-storage/azurite/manifests/latest": EOF

I tried to downgrade to earlier version, but the problem is still the same.
I tried to pull a specific version, :3.10.0, but still the same problem.
So I am not sure what did happen on my machine.

As I said, all other containers and images are working fine (6 other containers).

It is my own personal computer, so there is no proxy or VPN or anything like that.

I tried many times to prune everything ,I stopped all containers and did
dockery system prune
and then re-run all containers, and still Azurite not working.

Desktop is running as linux containers

My details :

Docker info produce the following:

Client:
 Version:    27.4.0
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
....
Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 27.4.0
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 472731909fa34bd7bc9c087e4c27943f9835f111
 runc version: v1.1.13-0-g58aa920
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
 Kernel Version: 5.15.153.1-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 15.5GiB
 Name: docker-desktop
 ID: 1c8aa3a1-8550-471c-9181-6481ae5d2ed9
 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=npipe://\\.\pipe\docker_cli
 Experimental: true
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile
2

Either it was a temporary error on Docker Hub or there is something between your machine and Docker Hub. I updated to the same version and it still works and downloads the image.

3

I know something on my machine, but not sure what it is.
And don’t know how to find out.
Something interesting is all other containers are from docker hub itself, except the Azurite, because it is from Microsoft container.
As you see the url for the container is : mcr.microsoft.com
I ping that address and I got the IP correctly, and from the web browser I can access the URL ok.
But the error message says that it cannot access that URL.

4

Those are images. Not important now, but it is always good to known what is what.

What is more important is that I somehow assumed these images would come from Docker Hub, but of course they don’t. So if there was or is any issue with the registry, it is not Docker Hub and you could try to report it to Microsoft.

Even if it is something in your environment, it is hard to tell remotely. The issue can be caused by proxies, but I guess it could be also caused by routers. If curl works, then maybe it is a client problem, but I don’t see how it would be when you can download images from Docker Hub.

You can try to pull other images from Microsoft to see if the problem happens only with this image or all images from Microsoft.

A ping is an ICMP package. Try curl instead with the HTTPS URL you see in the error message.

5

I did try to access that URL in fault in the error message: https://mcr.microsoft.com/v2/azure-storage/azurite/manifests/latest
I was able to access it from CURL and from the web browser.
ping mcr.microsoft.com is working fine.

6

I have been using Docker Desktop on Windows 11/10 for at least 3 years without problems, and always keep up-to-date with docker desktop update without any problem.
I have 7 images/containers (ElasticSearch, RabbitMQ, Redis, progress-db…) and one image from Microsoft called Azurite.

I am runnig Docker Desktop with WSL 2 integration, and running as Linux containers.

On my last upgrade for Docker Desktop to version 4.37.1, my containers were wipe out (which is not unusual on upgrade).
I tried to redownload the images and run the containers.
All worked except the Azurite.
when I do this command:

docker pull mcr.microsoft.com/azure-storage/azurite

I got this error

Error response from daemon: failed to resolve reference "mcr-microsoft-com azure-storage\azurite:latest": failed to do request: Head "mcr-microsoft-com\v2\azure-storage\azurite\manifests/latest": EOF

As you see from the error Docker server cannot access the URL: mcr-microsoft-com\v2\azure-storage\azurite\manifests\latest

I am able to access that URL from browser and from “CURL” tool. I am able to ping mcr.microsoft.com without any problem. I tried to prune all docker images on my system and run it again using:

docker system prune --all

I tried to uninstall DOcker Desktop and install an older version.
All failed

I tried to download other docker images from Microsoft like .net sdk, .net runtime and they all are failing with similar error.

Something on my machine that prevent Docker server from accessing that URL mcr.microsoft.com.

My machine is a personal machine, and I don’t have any proxy setting or VPN or anything like that.

But I am not sure if the following is effecting my connectivity:

I have Azure Artifact Credential Provider is configured to work with a private feed on Azure to get NuGet, and this setup has been created for last year, and didn’t have problem with it before. And the setup of Artifact Credential provider seems ok, because I can do dotnet restore successfully, and my stored credentials are used to get the nuget packages from there.

The URL for that private nuget feed is

https://pkgs.dev.azure.com/{name-of-org}/_packaging/{name-of-org}/nuget/v3/index.json

As I said, the private Nuget might have nothing to do with docker, but this is the only thing that special about my machine, and I have Azure cli is configured to work with my tenant on Azure.

Any help please.
I don’t know how to solve the problem, and my only option is to reset my laptop which is a big deal.

My docker details when I do docker info

Client:
 Version:    27.4.0
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
....
Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 27.4.0
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 472731909fa34bd7bc9c087e4c27943f9835f111
 runc version: v1.1.13-0-g58aa920
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
 Kernel Version: 5.15.153.1-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 15.5GiB
 Name: docker-desktop
 ID: 1c8aa3a1-8550-471c-9181-6481ae5d2ed9
 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=npipe://\\.\pipe\docker_cli
 Experimental: true
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile
7

I merged your new topic to your old one. You can always send a new post to your existing topic to remind users that the issue is still not resolved, but please, don’t open a new topic for the same issue.

Since you did, and the spam filter noticed it, it also blocked your previous posts automatically which I restored now.

1 Like
8

Sorry for not replying to your message 6 days ago, but I had no new ideas.

You can try a solution shared by another user (which I didn’t remember last time), but it was about insecure registries where the error message was similar.

Be careful, because it would delete ll your data, but I assume at this point you have nothing more to lose.

Another idea is that you can try disabling “Containerd” as image store in the general settings. If I remember correctly, that also helped someone when it was about losing images.

If you think there is a bug, you can also check issues on GitHub and report yours as new issue if you don’t find an existing one

9

Both solutions didn’t work.
I think my only option now is to reset my machine itself to factory.

10

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.