How to fix Error starting daemon: error initializing graphdriver: kernel does not support overlay fs in Docker

DockerINTERMEDIATEHIGHUpdated Dec 6, 2025· 257 views

This error occurs when Docker attempts to use the OverlayFS storage driver but your Linux kernel either lacks OverlayFS support, has an incompatible kernel version, or the backing filesystem doesn't meet requirements like d_type support.

Quick fix

Fixes Error starting daemon: error initializing graphdriver: kernel does not support overlay fs

uname -r
  1. Check your kernel version
  2. Load the overlay kernel module
  3. Check the backing filesystem type and d_type support
  4. Reformat XFS with d_type support (if needed)
docker — error
uname -r
Error starting daemon: error initializing graphdriver: kernel does not support overlay fs

What this error means

The OverlayFS (overlay filesystem) is Docker's recommended storage driver for managing layered container images. When Docker starts, it checks if the kernel supports OverlayFS and if the underlying filesystem is compatible. This error appears when: - Your Linux kernel version is too old to support OverlayFS (requires kernel 3.18+ for overlay, 4.0+ for overlay2) - The overlay kernel module is not loaded or available - The backing filesystem (where /var/lib/docker resides) doesn't support OverlayFS - XFS filesystem is formatted without d_type support (ftype=0 instead of ftype=1) - The filesystem doesn't support extended attributes (trusted.* or user.*) OverlayFS was merged into the Linux kernel in version 3.18, with significant improvements in version 4.0 that enabled the more efficient overlay2 driver. RHEL/CentOS backported support to kernel 3.10.0-514 and higher.

Typical symptoms

  • Docker daemon fails to start with 'kernel does not support overlay fs' message
  • Error message mentions 'error initializing graphdriver'
  • 'overlay' is not supported over extfs or xfs error
  • Docker worked on another system but fails on this one
  • Error appears after migrating Docker data to a new filesystem
  • Container runtime worked before filesystem or kernel changes

Common causes

  1. Linux kernel version is below 3.18 (or 4.0 for overlay2)
  2. The overlay kernel module is not loaded
  3. XFS filesystem formatted without d_type support (ftype=0)
  4. Backing filesystem doesn't support extended attributes
  5. Running in a virtualized environment with limited kernel features
  6. Using an older RHEL/CentOS kernel without OverlayFS backport
  7. NFS mount used for Docker data directory (not supported)
  8. Filesystem corruption preventing overlay mount

How to fix "Error starting daemon: error initializing graphdriver: kernel does not support overlay fs"

1Check your kernel version

First, verify your Linux kernel version meets the minimum requirements:

bash
uname -r

Requirements:
- overlay driver: Linux kernel 3.18 or higher
- overlay2 driver (recommended): Linux kernel 4.0 or higher
- RHEL/CentOS exception: kernel 3.10.0-514 or higher

If your kernel is too old, you'll need to upgrade it or use a different storage driver.

2Load the overlay kernel module

Check if the overlay module is loaded and try loading it:

bash
# Check if overlay module is loaded
lsmod | grep overlay

# Load the overlay module
sudo modprobe overlay

# Verify it loaded successfully
lsmod | grep overlay

If the module fails to load, your kernel may not have OverlayFS support compiled in. Check kernel configuration:

bash
# Check kernel config for overlay support
grep -i overlay /boot/config-$(uname -r) 2>/dev/null || \
  zcat /proc/config.gz 2>/dev/null | grep -i OVERLAY

Look for CONFIG_OVERLAY_FS=y or CONFIG_OVERLAY_FS=m.

3Check the backing filesystem type and d_type support

OverlayFS requires a compatible backing filesystem. Check what filesystem /var/lib/docker uses:

bash
df -T /var/lib/docker

For XFS filesystems, verify d_type support is enabled:

bash
xfs_info /var/lib/docker | grep ftype

You need ftype=1 for OverlayFS support. If it shows ftype=0, the XFS partition was formatted without d_type support.

For ext4 filesystems, d_type is supported by default since kernel 3.14.

Unsupported filesystems:
- NFS (doesn't support extended attributes)
- Some older ext3 configurations

4Reformat XFS with d_type support (if needed)

Warning: This will destroy all data on the filesystem. Back up your data first!

If your XFS filesystem lacks d_type support (ftype=0), you need to reformat it:

bash
# Stop Docker
sudo systemctl stop docker

# Back up Docker data if needed
sudo tar -cvzf docker-backup.tar.gz /var/lib/docker

# Unmount the filesystem (adjust device as needed)
sudo umount /var/lib/docker

# Reformat with ftype=1 for d_type support
sudo mkfs.xfs -n ftype=1 -f /dev/sdX

# Remount and restore
sudo mount /dev/sdX /var/lib/docker

# Start Docker
sudo systemctl start docker
5Use an alternative storage driver

If you cannot upgrade your kernel or fix the filesystem, configure Docker to use a different storage driver:

bash
sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<EOF
{
  "storage-driver": "vfs"
}
EOF

sudo systemctl restart docker

Available alternatives:
- vfs: Universal fallback, works everywhere but very slow and uses more disk space
- devicemapper: Works on older systems (deprecated, not recommended for new deployments)
- btrfs: If your filesystem is Btrfs
- zfs: If your filesystem is ZFS

Note: The vfs driver doesn't use copy-on-write, so each layer is fully copied. Use it only as a last resort.

6Upgrade your kernel (recommended long-term fix)

If your kernel is too old, consider upgrading:

Ubuntu/Debian:

bash
sudo apt update
sudo apt install linux-generic
sudo reboot

RHEL/CentOS 7:

bash
sudo yum update kernel
sudo reboot

RHEL/CentOS 8+ / Fedora:

bash
sudo dnf update kernel
sudo reboot

After reboot, verify the new kernel and retry Docker:

bash
uname -r
sudo modprobe overlay
sudo systemctl start docker
7Ensure overlay module loads at boot

To make the overlay module load automatically at boot:

bash
# Add overlay to modules to load at boot
echo "overlay" | sudo tee /etc/modules-load.d/overlay.conf

# Verify it's configured
cat /etc/modules-load.d/overlay.conf

Alternatively, on systemd-based systems:

bash
sudo tee /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter
8Verify Docker is working

After applying fixes, verify Docker is functioning correctly:

bash
# Check Docker daemon status
sudo systemctl status docker

# Verify the storage driver in use
docker info | grep "Storage Driver"

# Run a test container
docker run --rm hello-world

The storage driver should now show "overlay2" (or your configured driver), and the test container should run successfully.

Advanced notes

Kernel Version Requirements by Driver:
| Driver | Minimum Kernel | Recommended |
|--------|---------------|-------------|
| overlay | 3.18 | 4.0+ |
| overlay2 | 4.0 (or RHEL 3.10.0-514) | 4.0+ |
| fuse-overlayfs | Any (userspace) | For rootless Docker |

Filesystem Compatibility Matrix:
| Filesystem | overlay/overlay2 Support |
|------------|-------------------------|
| ext4 | Yes (recommended) |
| XFS | Yes, with ftype=1 |
| Btrfs | Use btrfs driver instead |
| ZFS | Use zfs driver instead |
| NFS | No (lacks extended attributes) |
| tmpfs | Yes |

XFS d_type Explained:
The d_type (directory entry type) field allows the filesystem to store file type information directly in directory entries. Without it, the kernel must perform additional stat() calls to determine file types, which breaks OverlayFS assumptions.

Check d_type support:

bash
xfs_info /path | grep ftype
# ftype=1 means d_type is supported
# ftype=0 means d_type is NOT supported

Rootless Docker and fuse-overlayfs:
If you're running rootless Docker and OverlayFS isn't available, consider using fuse-overlayfs:

bash
# Install fuse-overlayfs
sudo apt install fuse-overlayfs  # Debian/Ubuntu
sudo dnf install fuse-overlayfs  # Fedora/RHEL

# Configure for rootless Docker
mkdir -p ~/.config/docker
cat > ~/.config/docker/daemon.json <<EOF
{
  "storage-driver": "fuse-overlayfs"
}
EOF

Virtualized Environments:
In VMs (especially Xen, OpenVZ, or some cloud providers), the host kernel may not expose OverlayFS to guests. Options:
- Use the vfs driver (slow but universal)
- Request OverlayFS support from your hosting provider
- Use a VM with a full kernel (not container-based virtualization)

Checking OverlayFS in /proc:

bash
cat /proc/filesystems | grep overlay

If "overlay" appears, your kernel has OverlayFS support.

Frequently asked questions

What does "Error starting daemon: error initializing graphdriver: kernel does not" mean?
The OverlayFS (overlay filesystem) is Docker's recommended storage driver for managing layered container images. When Docker starts, it checks if the kernel supports OverlayFS and if the underlying filesystem is compatible. 0+ for overlay2) - The overlay kernel module is not loaded or available - The backing filesystem (where /var/lib/docker resides) doesn't support OverlayFS - XFS filesystem is formatted without d_type support (ftype=0 instead of ftype=1) - The filesystem doesn't support extended attributes (trusted.
How do I fix "Error starting daemon: error initializing graphdriver: kernel does not"?
This error occurs when Docker attempts to use the OverlayFS storage driver but your Linux kernel either lacks OverlayFS support, has an incompatible kernel version, or the backing filesystem doesn't meet requirements like d_type support.
What causes "Error starting daemon: error initializing graphdriver: kernel does not"?
Linux kernel version is below 3.18 (or 4.0 for overlay2) The overlay kernel module is not loaded XFS filesystem formatted without d_type support (ftype=0)
Is the "Error starting daemon: error initializing graphdriver: kernel does not" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading