moby: failed to dial gRPC: unable to upgrade to h2c, received 502

Description

Steps to reproduce the issue:

Install Docker for Windows or Docker for Mac, stable.
Run docker build . on a docker project

Describe the results you received:

$ docker build . -t user-manager
ERRO[0000] failed to dial gRPC: unable to upgrade to h2c, received 502 
context canceled

Describe the results you expected:

Docker to work at all.

Additional information you deem important:

Disabling “experimental features” and restarting the docker daemon fixes this. It’s as simple as that.

This issue has been open for over a year at https://github.com/docker-library/docker/issues/71, but while plenty of users have confirmed it across a range of versions and platforms, nothing has been done. The maintainers there punted the problem, said to take it over here, but no one did. When it’s everyone’s responsibility, it’s no one’s responsibility, I guess?

Why are experimental features getting shipped in the stable docker channel at all? Why are they on by default? Why has this issue been open for over a year?

Output of docker version:

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:21:31 2018
 OS/Arch:           darwin/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:29:02 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker info:

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 11
Server Version: 18.06.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.93-linuxkit-aufs
Operating System: Docker for Mac
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.952GiB
Name: linuxkit-025000000001
ID: YYVQ:JL5S:DTBJ:GPUK:OJJ7:DXN3:VC6C:AXSV:WKKT:UH26:B62F:A3PZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 25
 Goroutines: 52
 System Time: 2018-10-03T07:47:43.940101873Z
 EventsListeners: 2
HTTP Proxy: gateway.docker.internal:3128
HTTPS Proxy: gateway.docker.internal:3129
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

VirtualBox 5.2.18r124319 OS X Mojave (10.14)

BUT REMEMBER: this has been seen on Windows and several variants of OS X

About this issue

Original URL
State: open
Created 6 years ago
Comments: 17 (3 by maintainers)

Most upvoted comments

If it is any help, this issue is caused on Mac if you have not let the Docker Desktop completely load. See below:

(fpg_venv) Johns-MacBook-Pro-3:fpg_gitlab johnpeurifoy$ docker build -t iguanaus/ebs_deploy_repository:tag .
ERRO[0000] failed to dial gRPC: unable to upgrade to h2c, received 502 
context canceled
(fpg_venv) Johns-MacBook-Pro-3:fpg_gitlab johnpeurifoy$ docker build -t iguanaus/ebs_deploy_repository:tag .
Sending build context to Docker daemon  857.1kB
....

+11

iguanaus on Apr 6, 2019

I helped diagnose a similar issue with a colleague of mine (she was on OS X) and the fix was to increase the amount of allocated RAM (in the Preferences - Resources tab). From my minimal understanding of docker, the daemon which is responsible for building the image probably ends up being OOM and dies, which terminates the connection between the server (daemon) and the client (CLI) with a status 502.

From a user perspective the experience isn’t great. The error is cryptic and doesn’t tell us much about what could be done. While the assessment done here might be wrong, it would be great if the error was “caught” and some kind of suggestions were given to the user, in this case “increase the amount of allocated RAM”.

tomzx on Aug 18, 2020

One thing I keep needing to remember is that Windows shells run at different permissions levels. I ran into this problem when trying to run the docker sample application.

The fix for me was simply to run my powershell terminal as Administrator. (Similar to running sudo in *nix)

onesimusaz on Aug 14, 2019

have simliar problem.

the problem goes away after I pull the base docker image and re-run the build command.

swuecho on Dec 6, 2018