The Docker daemon, when asked to perform a build or pull operation, timed out waiting for a response from the Docker client, specifically during the initial connection setup or while streaming data.
The most frequent culprit is a flaky network connection between your Docker client and the Docker daemon. This could be intermittent Wi-Fi, a VPN dropping, or even a local network congestion. The fix is to ensure a stable connection. If on Wi-Fi, try a wired connection. If using a VPN, disconnect it temporarily to see if the issue resolves. Sometimes, simply restarting your router or modem can clear up transient network issues. The daemon gets stuck because the client’s requests or data packets are being lost or delayed indefinitely, exceeding the daemon’s internal timeout.
Another common cause is an overloaded Docker daemon or host machine. If your system is running out of CPU, memory, or disk I/O, it can’t respond to the client in a timely manner. Check your system’s resource utilization. On Linux, top or htop will show CPU and memory. iotop can show disk I/O. On macOS, Activity Monitor is your friend. The fix is to free up resources: close unnecessary applications, stop other Docker containers, or scale up your hardware if this is a persistent issue. The daemon’s internal queues fill up, and it can’t process incoming requests from the client.
A misconfigured or outdated Docker client or daemon can also lead to this. While less common for "context canceled" specifically, it’s worth checking. Ensure you’re running recent, stable versions of Docker Desktop or Docker Engine. To update, follow the official Docker installation guide for your OS. Sometimes, a simple restart of the Docker daemon can resolve transient state issues. On Linux, this is sudo systemctl restart docker. On macOS/Windows with Docker Desktop, use the UI to restart. This resets the daemon’s internal state, allowing it to re-establish a clean communication channel.
Network configuration on the Docker daemon side, particularly involving proxy settings, can interfere. If you’re behind a corporate proxy, Docker needs to be aware of it. For the daemon, this is often configured in /etc/docker/daemon.json (Linux) or via Docker Desktop’s settings. For example, to set an HTTP proxy:
{
"proxies": {
"default": {
"httpProxy": "http://your_proxy.example.com:8080",
"httpsProxy": "http://your_proxy.example.com:8080",
"noProxy": "localhost,127.0.0.1,docker-registry.example.com"
}
}
}
After modifying daemon.json, restart the Docker daemon. This ensures that Docker can correctly route its outgoing requests, including pulling images or communicating with registries, even when a proxy is in place. Without these settings, traffic might be dropped or rerouted incorrectly, leading to timeouts.
Less frequently, DNS resolution issues on the client or daemon side can cause delays that manifest as timeouts. If the Docker daemon cannot resolve the hostname of an image registry (like registry-1.docker.io), it will eventually give up. You can test DNS resolution from your client with ping registry-1.docker.io and from the daemon itself by running a temporary container with docker run --rm alpine nslookup registry-1.docker.io. If DNS is the problem, you might need to adjust your host’s /etc/resolv.conf (Linux) or network settings (macOS/Windows) to point to a reliable DNS server, or configure Docker’s DNS specifically in daemon.json:
{
"dns": ["8.8.8.8", "8.8.4.4"]
}
Restart the daemon after changes. This ensures that the daemon can quickly and reliably find the IP address of the registry it needs to communicate with.
Finally, consider the sheer size of the image or build context. Very large image layers or massive build contexts can strain the network and the daemon’s ability to process them within default timeouts. While not a direct cause of "context canceled" on its own, it exacerbates underlying network or resource issues. Optimizing Dockerfiles to reduce image size, using multi-stage builds, and cleaning up build cache (docker builder prune -a) can help. For pull operations, if you’re pulling a very large image, ensure your network is stable and your daemon has sufficient disk space and memory. The fix here is about reducing the load, making the operation more manageable for the existing infrastructure.
The next error you’ll likely encounter after fixing these "context canceled" issues is a manifest unknown error if the registry was unreachable, or a connection refused if the daemon itself is no longer running correctly.