ctr -n moby containers info shows empty SnapshotKey/Snapshotter when Docker uses io.containerd.snapshotter.v1 (overlayfs) — expected?

[Percivalll]

Hi team,
I’m using Docker 29.0.4 and my Docker daemon reports the following storage driver configuration:

Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1

However, when I run:

ctr -n moby containers info <container-id>

the output shows empty values for SnapshotKey and Snapshotter, e.g.:

"SnapshotKey": "",
"Snapshotter": "",

Is this expected behavior when Docker is using io.containerd.snapshotter.v1? If so, could you explain why these fields are empty (and where the snapshot reference is supposed to be tracked instead)?

containerd version:

Client:
  Version:  v2.1.5
  Revision: fcd43222d6b07379a4be9786bda52438f0dd16a1
  Go version: go1.24.9

Server:
  Version:  v2.1.5
  Revision: fcd43222d6b07379a4be9786bda52438f0dd16a1
  UUID: 657ce268-2ddf-436a-8cd4-3066a121c698

Thanks!

[austinvazquez]

Hi @Percivalll,

Is this expected behavior when Docker is using io.containerd.snapshotter.v1?

From containerd's perspective, this just means the container was created without those pieces of information. From Docker engine's point of view, it depends but I'd say this is a bit by design.

If so, could you explain why these fields are empty (and where the snapshot reference is supposed to be tracked instead)?

Engine has support for both the containerd backend and its legacy graph drivers implementation which can build the container rootfs. The end result is some of the container rootfs construction occurs in the engine process after the container object is created in containerd. More on the docker engine side, but I happen to work on both so I'll just add for the Docker engine 29 release it was an intentional decision to not expose the snapshot details through the API as a simplification. e.g. on-disk pathing might not make sense in some use cases when the container is remote or sandboxed within a virtual machine.