The first sign of a stopped daemon is almost always an error message that says it can’t connect, and nothing else. On most systems the fix is a single command. The daemon, officially named dockerd, is the background service that manages every container, image, network, and volume on the host.
On Linux it runs through systemd. macOS and Windows have no native Linux container support, so there it lives inside Docker Desktop.
What the Docker Daemon Does
Nobody opens dockerd. Once it’s started, it sits in the background and waits for instructions.
People mix it up with a few other things, so a quick clarification helps. The docker command you type is the client, and all it does is send requests over the API. Docker Desktop is a full application that happens to package the daemon inside it. And the daemon isn’t a container either. It creates and supervises them.
Docker usage among developers jumped 17 percentage points in a single year, reaching 71% of respondents, the largest year-over-year increase of any technology tracked in the survey (Stack Overflow, 2025).
That growth means plenty of people hit a stalled daemon before they’ve fully learned how containerization works under the hood.
How the Docker Daemon Works
The daemon listens on a socket, turns each request into an action, and passes the heavy lifting to lower-level components.
Take a single docker run. The CLI sends the request to dockerd over the socket, and dockerd validates it and keeps track of the desired state. From there containerd takes over image transfer, storage, and the container lifecycle. The last step belongs to runc, which sets up the container’s namespaces and starts the process.
containerd reached CNCF Graduated status in February 2019, the fifth project to graduate after Kubernetes, Prometheus, Envoy, and CoreDNS (CNCF, 2019).
A few defaults worth knowing for the communication setup:
- Default socket: unix:///var/run/docker.sock
- TLS-enabled TCP port: 2376
- Non-TLS TCP port: 2375, not recommended on exposed hosts
- containerd became the default image store for fresh installs starting with Docker Engine 29, released November 2025 (Docker Engine documentation)
Amazon EKS and Google Kubernetes Engine both run containerd as their production runtime, the same component sitting underneath dockerd on a single machine.
The relationship between the two platforms is worth a closer look if you’re comparing Kubernetes and Docker directly.
What the Docker Daemon Requires to Run
The daemon is only as capable as the operating system underneath it.
Beneath dockerd sit containerd, which handles image storage and the container lifecycle, and runc, which creates the isolated namespaces and cgroups each container runs inside.
On Linux, the daemon talks to the kernel directly, using features already built into the system.
On macOS and Windows there’s no native Linux container support, so Docker Desktop runs a lightweight Linux virtual machine and puts the daemon inside it.
- Linux: dockerd runs natively, managed by systemd
- macOS: dockerd runs inside a VM, managed by Docker Desktop
- Windows: dockerd runs inside WSL2 or a Hyper-V VM, managed by Docker Desktop
That’s why the start command changes by platform even though the daemon’s job is the same everywhere.
How to Start the Docker Daemon on Linux
Most Linux distributions manage the daemon through systemd, so starting it takes one command.
Starting with systemctl
This works on Ubuntu, Debian, Fedora, and RHEL.
- Open a terminal and run
sudo systemctl start docker - Wait a few seconds while dockerd initializes containerd and reloads existing containers
- Confirm the command succeeded with
echo $?, which returns 0 on success
No output usually means it worked. systemctl only prints something when a command fails.
Starting with the service command
Older distributions and some minimal server images still ship the legacy service wrapper instead of calling systemctl directly.
sudo service docker start does the same job there. It works on Debian-based systems through System V compatibility, and on most modern distributions it just calls systemctl anyway. You’ll rarely need it unless you’re on a base image without systemd.
Either path lands you in the same place, a running dockerd process bound to /var/run/docker.sock.
How to Start the Docker Daemon on macOS
There’s no dockerd binary to invoke directly on macOS. Docker Desktop owns the whole startup process.
Open Docker Desktop from Applications or Spotlight search, then watch the whale icon in the menu bar. While it animates, the daemon is still coming up. Once it holds steady, dockerd is running and ready.
Docker Desktop handles the launchd integration behind the scenes, so there’s no separate service command to remember.
Once the icon settles, confirm it from the terminal with docker info.
A response listing server details means dockerd, running inside the Docker Desktop VM, accepted the connection.
How to Start the Docker Daemon on Windows
For Linux containers, Windows runs the daemon inside a Linux environment either way, but the backend you pick changes how you start it.
| Platform | Start command | Socket type | Managed by |
|---|---|---|---|
| Linux | systemctl start docker | Unix socket | systemd |
| macOS | Open Docker Desktop | Unix socket in VM | launchd and Docker Desktop |
| Windows | Open Docker Desktop | Named pipe | WSL2 or Hyper-V and Docker Desktop |
WSL2 backend
WSL2 is the default and the one I’d recommend for most people. Launch Docker Desktop from the Start menu and it starts the WSL2 distribution and dockerd inside it automatically. Day-to-day use doesn’t need administrator privileges.
Docker’s own system requirements call for Windows 10 version 22H2 (build 19045) or Windows 11 version 23H2 (build 22631) or higher, plus 8GB of system RAM (Docker Desktop documentation).
If Docker isn’t set up yet on the machine, the Docker installation steps cover both backends before you get to this point.
Hyper-V backend
Hyper-V requires turning on the Hyper-V and Containers Windows features first, then a restart.
After that, Docker Desktop starts the Hyper-V virtual machine and the daemon inside it the same way, through the whale icon.
Membership in the docker-users group grants access to the Docker daemon socket, which is equivalent to granting administrative privileges on the host, according to Docker’s own documentation, so it’s handed only to accounts that actually need Hyper-V or Windows container access.
How to Enable the Docker Daemon on Boot
Starting the daemon once and enabling it to start automatically are different things, and people mix them up constantly.
On Linux, sudo systemctl enable docker creates the symlink that tells systemd to start dockerd at every boot. On macOS and Windows, open Docker Desktop settings and turn on “Start Docker Desktop when you sign in to your computer,” found under the General tab.
Enabling only affects boot behavior, not the current session. A daemon that’s enabled but not started still needs one manual start. To undo it, run systemctl disable docker on Linux or uncheck the same setting elsewhere.
Check enablement status on Linux with systemctl is-enabled docker, which prints “enabled” or “disabled” directly.
That one command saves a reboot just to confirm the setting stuck.
How to Check Whether the Docker Daemon Is Running
A handful of commands will tell you if the daemon is alive.
- Run
docker infoand look for a Server section in the output - Run
docker versionand check that both a Client and a Server block appear - On Linux, run
systemctl status dockerand look for “active (running)”
A full server block means the daemon is up and responding on the socket. Client details with no server block mean it isn’t reachable. And if you see “Cannot connect to the Docker daemon,” the daemon either isn’t running or isn’t listening at the expected socket.
The broader question of whether Docker itself is responding, not just the daemon process, is covered from the container side in a companion piece on checking whether Docker is running.
docker ps works as a quick check too, since it prints a container list (or an empty table) when the daemon is up and a connection error when it isn’t, but it tells you far less than docker info does.
Why the Docker Daemon Fails to Start
When startup fails, it’s usually a blocked socket, a broken config file, or missing virtualization support.
| Error type | Common cause | Typical fix |
|---|---|---|
| Socket error | Stale docker.sock file or port already in use | Remove the stale socket, restart the service |
| Configuration error | Invalid JSON in daemon.json | Validate the file, remove the bad key |
| Virtualization error | Hardware virtualization disabled in BIOS | Enable virtualization, restart the host |
Socket errors
A leftover socket file from a crashed daemon is the most common reason a restart fails.
Look for address already in use in the logs. If it’s there, remove the stale file with sudo rm /var/run/docker.sock and restart the service afterward, not before.
Configuration errors
dockerd refuses to start if daemon.json contains invalid JSON or an unrecognized key.
The fastest way to confirm it is to rename daemon.json temporarily and try starting the daemon again. Then check the daemon logs, which name the exact line of the broken entry.
A daemon that starts cleanly without the file confirms the configuration was the problem.
Virtualization errors
These only show up on macOS and Windows. On Windows, hardware virtualization (VT-x or AMD-V) must be enabled in BIOS or UEFI, while Macs don’t expose an equivalent setting. If Docker Desktop runs inside another VM, nested virtualization has to be on as well. A disabled setting produces a Docker Desktop error before the daemon ever starts.
Native Linux installs skip this category entirely, since the daemon talks to the kernel directly without a virtualization layer.
How to Fix Docker Socket Permission Denied
This error means the daemon is running fine. Your user account just isn’t allowed to talk to it.
- Add your user to the docker group with
sudo usermod -aG docker $USER - Log out and back in, or run
newgrp dockerto apply it immediately - Confirm access with
docker ps, which should now run without sudo
Docker’s own documentation warns that docker group membership is functionally equivalent to root access on the host (Docker Engine documentation).
That’s because anyone in the group can mount the host filesystem into a container and read or write anything on it.
Using sudo docker instead of joining the group avoids that tradeoff, at the cost of typing sudo every time. Personally I’d take the typing on any shared machine.
Rootless Mode Versus Standard Daemon Mode
Standard mode runs dockerd as root, the way Docker has worked since its earliest release.
Rootless mode runs the same daemon inside a user namespace, with no root privileges at any point. A container escape lands in an unprivileged user’s context instead of root’s, and the only SETUID binaries required are newuidmap and newgidmap. That makes it a good fit for shared or multi-tenant hosts where handing out root isn’t an option.
The downsides are real, though. Rootless can’t bind to ports below 1024 by default, unless you adjust a sysctl setting or grant rootlesskit the needed capability (Docker Engine documentation). It has no support for macvlan or ipvlan networks, although user-defined bridge networks do work inside the rootless namespace. Networking is also a bit slower because of the userspace network stack.
Setup has a hard requirement too: /etc/subuid and /etc/subgid must each allocate at least 65,536 subordinate UIDs and GIDs to the user before the daemon will start (Docker Engine documentation).
Standard mode skips all of that, which is why it remains the default for single-user workstations and most CI runners.
When Starting the Docker Daemon Does Not Work
Some environments block the daemon no matter how carefully you follow the steps.
A cloud VM or CI runner with nested virtualization disabled will block Docker Desktop entirely. On Windows, corporate policy sometimes disables Hyper-V or WSL2 at the group policy level. Hosts running a daemonless runtime like Podman have no dockerd process to start in the first place. And if the filesystem holding /var/lib/docker is full or mounted read-only, the daemon won’t come up either.
Namespace isolation, the mechanism rootless mode depends on, is not a guaranteed boundary either.
Qualys’ Threat Research Unit disclosed three separate bypasses of Ubuntu’s unprivileged user namespace restrictions in March 2025, affecting Ubuntu 24.04 and later (Qualys, 2025).
None of those bypasses alone hand over full root access, but they remove a layer of protection the daemon partly relies on.
In every one of these cases the fix sits outside Docker itself, whether that’s BIOS settings, group policy, disk space, or a different runtime altogether.
How to Stop and Restart the Docker Daemon
Stopping the daemon uses the same systemctl pattern as starting it, just with a different verb.
On Linux, sudo systemctl stop docker stops it, and sudo systemctl restart docker does both in one step. On macOS and Windows, right-click the whale icon and choose Restart, or quit the app and relaunch it.
By default, stopping the daemon also stops every running container, since dockerd supervises them directly.
Docker’s Live Restore feature changes that behavior, letting containers keep running while the daemon itself restarts or upgrades (Docker Engine documentation).
It’s a separate setting in daemon.json, off by default, and worth turning on for hosts where uptime matters more than a clean restart.
If the goal is only stopping a single container rather than the whole daemon, the command and the blast radius are both smaller.
The same applies in reverse when you just need to bring one container back rather than restarting a Docker container that crashed on its own.
FAQ on How To Start Docker Daemon
What is the difference between starting the daemon and starting Docker Desktop?
Starting the daemon means launching dockerd itself, the process that manages containers. Starting Docker Desktop launches the whole application, including the VM, GUI, and Kubernetes tooling, with dockerd running as one piece inside it.
Can you start the Docker daemon without systemd?
Yes. Running the dockerd binary directly from a terminal starts the daemon without any init system involved. This works for debugging, but the daemon won’t survive a reboot or restart automatically without systemd or an equivalent service manager.
Does the Docker daemon need an internet connection to start?
No. dockerd starts and manages existing containers and images entirely offline. A connection is only needed for pulling new images from Docker Hub or another registry, not for the daemon’s own startup process.
Can multiple users share one running Docker daemon?
Yes, on Linux. Every user in the docker group connects to the same daemon through the shared socket and sees the same containers, images, and networks. Rootless mode changes this, since each rootless instance runs per user.
Does starting the daemon start existing containers automatically?
Only containers created with a restart policy such as always or unless-stopped come back automatically. Containers without a restart policy stay stopped until someone runs docker start manually, even after the daemon itself is running again.
What port does the Docker daemon listen on by default?
By default dockerd listens on a Unix socket, not a network port. When TCP access is enabled, the daemon uses port 2376 with TLS or port 2375 without it, the latter unsafe on exposed hosts.
Is the Docker daemon the same as the Docker Engine?
No. Docker Engine is the umbrella term for the client, API, and daemon together. The daemon, dockerd, is just one component of the Engine, specifically the background service that does the actual container management work.
What to Fix First When the Daemon Won’t Start
Work through problems in a fixed order. Check that the socket responds, then look at group or rootless permissions, and leave the daemon.json configuration for last.
A socket failure masks every permission or configuration issue sitting behind it, so checking it first saves time.
Choosing standard mode over rootless mode trades a larger attack surface for zero setup overhead, the reverse of what rootless mode accepts in exchange for its extra configuration steps.
That tradeoff holds regardless of platform, since Linux, macOS, and Windows all route through the same dockerd process underneath.
With the daemon active, the next step in this series covers creating a Docker container, the actual reason for running dockerd in the first place.
- How to Turn On Dark Mode in Notepad++ (Built-In, No Plugin) - October 3, 2026
- PostgreSQL Cheat Sheet - October 2, 2026
- How to Repair a Corrupt SQL Server Database Without Any Data Loss - October 2, 2026
