containerd - Where to find the related files

/var/lib/containerd (The "Hard Drive")

This is the Persistent Storage. Everything in this directory is meant to survive a reboot. If you delete this folder, you lose your images, your downloaded layers, and the record of your containers.

Key Subdirectories:

• io.containerd.content.v1/: This is the "content store." It contains the actual blobs (the raw data) of the container images you have pulled. Files here are addressed by their SHA-256 hash.
• io.containerd.snapshotter.v1/: This is where the "layers" live. Containerd uses snapshotters (like overlayfs) to manage the different layers of an image. When you pull an image, it is unpacked into this directory so it can be mounted as a filesystem.
• io.containerd.metadata.v1/: This contains a BoltDB database (meta.db). This database is the "Source of Truth" for containerd. It maps image names to their hashes, tracks which snapshots belong to which containers, and manages namespaces.
• io.containerd.runtime.v2/: Storage for persistent data needed by the container runtimes.

Summary: This is where the "weight" of your containers lives. It is usually the directory that consumes the most disk space.

/run/containerd (The "RAM")

This is the Runtime State. In most Linux distributions, /run is a tmpfs (a virtual filesystem stored in RAM). Everything here is wiped when the system reboots.

Key Files and Subdirectories:

• containerd.sock: This is the Unix Domain Socket. This is the "phone line" that nerdctl, crictl, or the Kubelet use to talk to the containerd daemon.
• io.containerd.runtime.v2.task/: This is the most active area. Every running container has a subdirectory here. It contains:
  • config.json: The OCI runtime spec (the instructions for runc).
  • rootfs/: The active mount point where the container's filesystem is currently joined and running.
  • Standard I/O Pipes: The FIFOs (First-In-First-Out) used to capture the container's stdout, stdin, and stderr.
• containerd.pid: A simple text file containing the Process ID of the currently running containerd daemon.
• Shims: Containerd uses a "shim" process for every container (so the container can stay running even if containerd restarts). The control sockets for these shims live here.

Summary: This is where the "activity" lives. It manages the communication between the daemon and the actual running processes on the CPU.

/etc/containerd/ (The Configuration)

This is the most important directory for administrators.

• config.toml: This is the primary configuration file for the containerd daemon.
• What's inside?
  • Plugin settings: Configuration for the CRI (Container Runtime Interface).
  • Runtime definitions: This is where you tell containerd how to use gVisor (runsc) or Kata Containers.
  • Mirror/Registry settings: If you have a private registry or want to use a proxy, you configure it here.
  • CNI paths: Tells containerd where to find your network configuration.

/etc/cni/net.d/ (The Networking Logic)

containerd does not handle networking natively (unlike Docker, which has its own built-in bridge logic). Instead, it uses CNI (Container Network Interface).

• What's inside? JSON files (e.g., 10-containerd-net.conflist) that define how IP addresses are assigned to your containers and how the bridge is set up.
• Relationship: When you start a container, containerd looks in this folder to figure out how to "wire up" the container to the network.

/opt/cni/bin/ (The Network Binaries)

While /etc/cni has the instructions, this folder contains the tools.

• What's inside? Small executable binaries like bridge, loopback, portmap, and host-local.
• Relationship: containerd calls these binaries to physically set up the network interfaces. If this folder is empty, your containers will start but will have no network access.

/var/log/pods/ and /var/log/containers/ (The Logs)

If you are using containerd as part of a Kubernetes cluster (via the CRI), this is where the action is.

• /var/log/pods/: Contains subdirectories for every Pod, and inside those, the actual .log files for every container.
• /var/log/containers/: This directory is full of symbolic links. It links the cryptic filenames in /var/log/pods to more readable names (e.g., web-app_default_container-0.log).
• Note: If you are using nerdctl standalone, logs are often managed via the journal (systemd) or stored under the /run/containerd task directory mentioned earlier.

Rootless Mode Locations (The "Home" Shift)

If you are running containerd in Rootless mode (as a non-root user), the entire filesystem hierarchy shifts into your home directory to avoid needing sudo permissions:

• Config: ~/.config/containerd/config.toml
• Data: ~/.local/share/containerd/
• Runtime: /run/user/1000/containerd/ (where 1000 is your User ID)

Summary Checklist

Directory	Purpose	Why go there?
/etc/containerd	Config	To enable gVisor, add private registries, or change runtimes.
/etc/cni/net.d	Network Config	To change the Pod IP range or subnet settings.
/opt/cni/bin	Network Tools	To check if CNI plugins are actually installed.
/var/log/pods	K8s Logs	To debug why an application inside a Pod is crashing.
/usr/local/bin	Binaries	To see which versions of containerd and runc are installed.

Pro-Tip for Debugging

• Disk Full? Check /var/lib/containerd. You probably need to run a cleanup command (like nerdctl system prune or crictl rmi --prune).
• Container "Stuck" or Socket errors? Check /run/containerd. Sometimes a stale socket or PID file here can prevent a service from restarting correctly, though containerd is generally very good at cleaning this up itself.