Skip to content
Latchkey

Buildah storage driver falls back to slow vfs in CI

Buildah prefers the overlay storage driver, but rootless in an unprivileged CI container often cannot use native overlay. It falls back to vfs, which makes a full copy of the filesystem for every layer, so builds are correct but extremely slow and disk-heavy.

What this error means

Buildah builds succeed but take far longer than expected, and buildah info shows "graphDriverName": "vfs". Disk usage balloons because layers are not shared.

buildah
WARN[0000] Failed to mount overlay: overlay is not supported, falling back to vfs
# buildah info shows:
"store": { "graphDriverName": "vfs" }

Common causes

No fuse-overlayfs in a rootless container

Rootless overlay needs fuse-overlayfs when the kernel or container does not allow native rootless overlay; without it, Buildah drops to vfs.

The container blocks native overlay mounts

An unprivileged CI container without the needed access cannot mount overlay, forcing the vfs fallback.

How to fix it

Install and configure fuse-overlayfs

  1. Install the fuse-overlayfs package in the build image.
  2. Set the storage driver to overlay with the fuse-overlayfs mount program.
  3. Re-run and confirm buildah info reports overlay, not vfs.
storage.conf
# /etc/containers/storage.conf
[storage]
driver = "overlay"
[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"

Or run privileged so native overlay works

If the runner can grant it, a privileged build container can use native overlay directly and avoid fuse entirely.

pod.yaml
securityContext:
  privileged: true

How to prevent it

  • Install fuse-overlayfs in rootless build images.
  • Set storage.conf to overlay with the fuse-overlayfs mount program.
  • Check buildah info for the active graph driver in CI.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →