TIL Docker 29 uses the containerd snapshotter by default, and copying an older host's daemon.json onto it either stops the daemon or hides every image you have

New box last week, Docker 29.7.2, no daemon.json on it at all. I went to drop in the same one I use on my other hosts: log rotation, a couple of DNS servers, ulimits, live-restore. Nothing clever. That file broke the host two different ways. First, "storage-driver": "overlay2" . Daemon won't start: failed to start daemon: configured driver "overlay2" not available: unavailable On 29 the containerd snapshotter is the default and the classic overlay2 driver isn't available at all. My other hosts are on older Docker where it is, which is exactly why that line was sitting in the file. The second one took years off me. "features": {"containerd-snapshotter": false} and the daemon comes up clean, except docker ps -a and docker images are both empty. Everything gone. Including an image I'd built on that box and had no tidy way to rebuild. It was all still there. With the snapshotter on, images live in the containerd content store, so a daemon pointed at the classic store is reading an empty directory. docker volume ls never changed, the container metadata was still in /var/lib/docker/containers, and sudo ctr -n moby images ls listed every image exactly where it should be. Flipped the feature back to true, restarted, everything came back. So the check I run now before putting a daemon.json on a host I didn't build: docker info | grep -iE "Storage Driver|driver-type" If it says overlayfs you're on the snapshotter, and storage-driver does not belong in that file. Unrelated, but it cost me a second restart: log-opts only apply to containers created after the change. The existing ones keep logging unbounded until you force-recreate them.