Fix Docker Daemon Not Starting on Linux (2026)

The Docker daemon failed to start because it lost its primary storage driver, overlay2, and couldn’t fall back to a suitable alternative.

Common Causes and Fixes:

Corrupted overlay2 driver data: This is the most frequent culprit. The daemon tries to initialize the overlay2 storage driver, but the underlying data directories (/var/lib/docker/overlay2) are either missing, empty, or corrupted, preventing it from mounting the necessary storage.
- Diagnosis: Check the Docker daemon logs for messages like "failed to mount overlay: no such file or directory" or "failed to create rootfs: layer does not exist." You can view logs with sudo journalctl -u docker.service -f.
- Fix: The safest approach is to back up any important images or containers, then remove the corrupted data and let Docker rebuild it.
```
sudo systemctl stop docker
sudo rm -rf /var/lib/docker/overlay2
sudo rm -rf /var/lib/docker/image
sudo rm -rf /var/lib/docker/containers
sudo rm -rf /var/lib/docker/volumes
sudo systemctl start docker
```
  This command stops Docker, recursively removes the directories associated with the overlay2 driver, image layers, container data, and volumes, then restarts Docker, forcing it to reinitialize these structures.
Missing overlay kernel module: Docker relies on the overlay (or overlay2) kernel module for its storage driver. If this module isn’t loaded or available, Docker cannot initialize overlay2.
- Diagnosis: Run lsmod | grep overlay. If you see no output, the module isn’t loaded. Check dmesg | grep overlay for any errors related to loading it.
- Fix: Ensure the overlay module is loaded. On most modern Linux distributions, it’s loaded automatically. If not, you can try to load it manually:
```
sudo modprobe overlay
```
  If this succeeds, Docker should start. To make it persistent across reboots, you might need to add overlay to /etc/modules-load.d/docker.conf (create the file if it doesn’t exist).
Incorrect storage-driver configuration in daemon.json: If you’ve manually configured Docker’s storage driver in /etc/docker/daemon.json and made a mistake, or if the specified driver is no longer supported or available, Docker will fail to start.
- Diagnosis: Inspect /etc/docker/daemon.json. Look for a "storage-driver" key.
- Fix: Correct the storage-driver value or remove the entry to let Docker use its default (overlay2 on most systems). For example, if the file contains:
```
{
  "storage-driver": "aufs"
}
```
  and aufs is not properly configured or available, change it to:
```
{
  "storage-driver": "overlay2"
}
```
  or simply remove the line to revert to the default. After saving the file, restart Docker: sudo systemctl restart docker.
Filesystem issues on /var/lib/docker: The underlying filesystem where Docker stores its data (/var/lib/docker) might be full, corrupted, or mounted with incorrect options, preventing the daemon from accessing or creating necessary files.
- Diagnosis: Check disk space with df -h /var/lib/docker. Look for errors in dmesg related to the filesystem or storage device.
- Fix: If the filesystem is full, free up space by removing old images, containers, or volumes (docker system prune -a). If there are filesystem errors, you might need to run fsck on the relevant partition (this usually requires unmounting the partition, which might mean stopping Docker and potentially booting into a recovery environment). Ensure the filesystem is mounted with appropriate options (e.g., rw).
SELinux or AppArmor restrictions: Security modules like SELinux or AppArmor can prevent Docker from accessing necessary directories or performing required operations, leading to startup failures.
- Diagnosis: Check sudo ausearch -m avc -ts recent for SELinux denial messages or sudo aa-status and sudo dmesg | grep -i apparmor for AppArmor issues.
- Fix: If SELinux is the cause, you might need to update SELinux policies for Docker. A temporary workaround for testing is to set SELinux to permissive mode: sudo setenforce 0. For AppArmor, you might need to adjust or disable the Docker profile. Note: Disabling security features is a temporary diagnostic step and not recommended for production environments.
Incorrectly managed containerd: Docker relies on containerd for managing container lifecycles. If containerd is not running or is misconfigured, Docker can fail to start.
- Diagnosis: Check the status of containerd: sudo systemctl status containerd. Look for errors in its logs: sudo journalctl -u containerd.service -f.
- Fix: Restart containerd: sudo systemctl restart containerd. If it continues to fail, investigate its configuration, typically found at /etc/containerd/config.toml. Ensure it’s correctly pointing to its data directory and has valid settings.

After resolving these issues and starting Docker, you’ll likely encounter the next common problem: "Error response from daemon: No free ports available."