Azure Pipelines · Container jobs · Checked November 5, 2026

Azure Pipelines container jobs: "Cannot connect to the Docker daemon at unix:///var/run/docker.sock" since agent 5.279.0, and mapDockerSocket

Azure Pipelines agent 5.279.0, released on August 28, 2026, changed the default of mapDockerSocket to false (azure-pipelines-agent #5627). Before it, a container job on a Linux agent got the host's /var/run/docker.sock mounted into the job container whenever the YAML said nothing; now it gets it only when the container resource asks for it. A job that runs Docker from inside its container, to build images or to start containers for tests, fails from the first run on the new agent, with no change to the pipeline.

While container jobs fail after the agent update: Azure DevOps Pull Requests, a plugin for JetBrains IDEs, shows a build policy that started failing as failed next to its pull request in your IDE. Get it on JetBrains Marketplace

What it looks like

The Docker CLI in the job container: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Testcontainers: "Could not find a valid Docker environment". In apache/flink #29177, every Testcontainers-based test in its container jobs failed this way, and the nightly runs had failed since September 4, 2026. Its runs on self-hosted agents still on 5.278.0 passed, and would break once those agents were upgraded.
In community.postgresql #948 all of the collection's Azure Pipelines runs failed until the same one line was added.
In the log of the step that starts the job container, the docker create line no longer has -v "/var/run/docker.sock":"/var/run/docker.sock". apache/flink #29177 compared the last passing run and the first failing one: that mount was the only difference.

Fix: ask for the socket on the container resource

Microsoft's container jobs page gives the opt-in:

resources:
  containers:
  - container: my_container
    image: ubuntu:22.04
    mapDockerSocket: true

Jobs that do not run Docker inside the container need nothing. Microsoft's caution on the same page: with the socket mapped, code inside the container can run as root on the Docker host, so set it only on the containers that need it.

Or run the Docker step on the host

A container job can run single steps outside the container with a step target. A step that only builds or pushes an image does not need the socket inside the container at all:

steps:
- script: docker build -t myapp .
  target: host

Many self-hosted agents and no time to change every YAML

The same Microsoft page gives a short-term way back for an agent host: set the environment variable AZP_AGENT_DEFAULT_MAP_DOCKER_SOCKET_TO_FALSE=false for the agent, and Linux container jobs map /var/run/docker.sock again unless their YAML sets mapDockerSocket. Microsoft says to use it only as a short-term mitigation, since it gives every container job on that agent the host's Docker daemon again.

Telling it apart

"permission denied while trying to connect to the Docker daemon socket": the socket is there, but the user in the container may not use it. That is a different problem from a socket that was never mounted.
A step that runs directly on the agent, not in a container job, is not affected by mapDockerSocket.
Another Linux change that broke pipelines without a change to them: on the Ubuntu 26.04 image the agent runs as runner, so paths under /home/vsts fail.
On Bitbucket Pipelines, the same message has its own cause: a step reaches Docker only through the docker service.

Build validation in IntelliJ IDEA and Rider

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists your pull requests in an IDE tool window with their branch policies in plain words, so a build policy that started failing after the agent update shows up as failed next to the pull request. With Pro, a build that failed or expired has a Run again link that queues it again. The review inbox and the branch policies are free; voting, commenting, completing, running a build policy again and creating pull requests are Pro (US$1 a month, with a 30-day trial).

Get it on JetBrains Marketplace

Azure DevOps and Azure Pipelines are trademarks of Microsoft Corporation; Docker is a trademark of Docker, Inc.; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft, Docker, Inc. or JetBrains.

More: Node.js 6, 10 and 16 leave the agent on November 24, 2026 · "Access to the path '/home/vsts' is denied" on Ubuntu 26.04 · build validation: expired builds and why a pull request build did not run · 日本語