docker: failed to start daemon: ...

Docker Daemon Won't Start: Fixing the 'Failed to Start' Error

Linux & Unix Intermediate 👁 10 views 📅 Jun 18, 2026

Docker daemon crapping out on boot? Here's the real fix, based on what I've seen kill it at small biz clients.

Yeah, that's frustrating. Docker just sits there, or systemctl spits out a vague 'failed to start' message. Don't waste time guessing. Here's what I do first, because it fixes this 80% of the time.

Quick Fix: Check Docker Daemon Logs

Run this right now:

sudo journalctl -u docker.service --no-pager | tail -50

Scroll up. You're looking for one of these:

  • can't create unix socket /var/run/docker.sock: permission denied
  • Error starting daemon: error initializing graphdriver: ...
  • listen tcp 0.0.0.0:2375: bind: address already in use
  • overlay2 is not supported

If you see a permission error on the socket, the fix is almost always the Docker group not existing or your user not being in it. Did you install Docker with apt but never added yourself to the Docker group? That's it. Run:

sudo usermod -aG docker $USER
newgrp docker

Then restart Docker: sudo systemctl restart docker. Works like a charm.

Why That Fix Works

The Docker daemon runs as root and creates a Unix socket at /var/run/docker.sock. By default, only root and members of the Docker group can access it. If the group doesn't exist or you're not in it, docker ps fails with a permission error—and sometimes the daemon itself won't start cleanly if the socket creation fails because of leftover issues from a previous install. Adding your user to the group gives you access; the newgrp command refreshes your session so you don't have to log out and back in.

I had a client last month whose whole dev environment was broken because they'd run the Docker install script as root but never added their user. Took me five minutes to fix. They'd been Googling for an hour.

Less Common Variations

Graphdriver Errors

If you see overlay2 is not supported on an older kernel (pre-4.0), or a devicemapper error, the issue is the storage driver. Check your filesystem type:

df -T /var/lib/docker

If it's ext4 or xfs with d_type support, overlay2 should work. If not, you can force it in /etc/docker/daemon.json:

{
  "storage-driver": "overlay2"
}

Then restart. If you're on a weird filesystem like Btrfs or ZFS, you might need a different driver. I've seen this on Docker-for-Mac setups where people mounted volumes from NAS devices. Pain in the ass.

Port Conflict on 2375/2376

If the log shows bind: address already in use, something else is hogging the port. Docker listens on TCP port 2375 (unencrypted) or 2376 (TLS) if you've enabled remote API. Check what's using it:

sudo lsof -i :2375

If it's another Docker instance or some other service, kill it or change Docker's config in /etc/docker/daemon.json:

{
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2376"]
}

Use a different port. Or, if you don't need remote access, remove the TCP host entirely.

Systemd Overrides

Sometimes the Docker socket path gets mangled by systemd. Check /etc/systemd/system/docker.service.d/ for override files. I've seen people accidentally set ExecStart to a wrong binary path. Just delete the override dir and reinstall Docker if you're not sure.

Rootless Docker

If you're running Docker in rootless mode and it fails, the log might show failed to start containerd: timeout. Rootless Docker needs user namespaces and cgroups v2. Make sure /sys/fs/cgroup is mounted correctly. On Ubuntu 20.04, you need to enable cgroups v2 in kernel boot parameters: systemd.unified_cgroup_hierarchy=1. I had a client who tried rootless on an older kernel and it never worked—switched back to rootful Docker.

Prevention

  • Don't install Docker with snap on Ubuntu. Use the official apt repo. Snap can cause weird socket permission issues.
  • Check the daemon log first whenever Docker acts up. journalctl -u docker.service is your friend.
  • Keep your kernel updated. Docker's overlay2 driver needs kernel 4.0+. On Ubuntu 18.04, that's the HWE kernel.
  • Add your user to the Docker group right after install. Saves you the headache.
  • Set up Docker to start on boot: sudo systemctl enable docker. I've seen machines reboot and developers panic because Docker didn't start.

That's it. Docker daemon fails happen, but they're usually quick to fix once you stop guessing and look at the logs. Now go fix it.

Was this solution helpful?