Two halves of one failure mode. Running out of space partway through a write does not fail cleanly — it leaves a corrupt artifact, and the corruption is invisible to anything that only checks the file still runs.

What that looks like inside a guest, from a bake that converted on a full filesystem:

$ uname --version
uniq (GNU coreutils) 9.1          # /usr/bin/uname is a valid ELF holding another file's bytes
$ uname -s
uname: option requires an argument -- 's'

plus Exec format error on the same path, EBADMSG on /var/lib/dpkg and /var/lib/apt/lists directory entries, and libidn2.so.0: cannot dynamically load position-independent executable. A settled rootfs hashed byte-identical to its source image in the same session, so the damage is in the write path, not the source. It reaches CI as a compile error ~40s deep (set -euo pipefail; OS="$(uname -s)" in a dependency's build hook) that reads like a broken build script.

Free-space preflight

forkd parent build (conversion) and forkd snapshot (bake) now check free space on the target filesystem before the first write and refuse below a 5 GiB reserve, overridable with FORKD_MIN_FREE_GIB:

refusing to bake a snapshot: only 1.2 GiB free on the filesystem holding /var/lib/forkd/snapshots (need 5.0 GiB).

Conversion is the first multi-GB write of the pipeline (it unpacks a whole image into a fresh ext4) and the snapshot dir holds the clone plus a fresh memory.bin. The reserve matches the threshold forkd doctor already reports as "recommended ≥5 GiB".

doctor::available_bytes(path) is extracted from check_snapshot_dir_space's statvfs, which was private and hardcoded to $XDG_DATA_HOME/forkd/snapshots — that is the wrong filesystem to gate --rootfs/--snapshot-root overrides against, which is why it takes a path now. The probe stays advisory: if statvfs cannot run, it warns and continues rather than blocking work on a broken measurement.

Not included: the same gate on the daemon's restore path. The controller cannot depend on forkd-cli, so that needs the helper in forkd-vmm plus a policy for the 507/409 response. Happy to do it as a follow-up if the shape here looks right.

Staging dir cleanup

forkd snapshot wrote vmstate, memory.bin and snapshot.json into <tag>.staging-<pid> and removed it only on the success path, so any ? after the files were written — boot timeout, snapshot error, publish error, interrupt — left a fully written memory.bin (GBs) beside the snapshot dir with nothing to collect it. A StagingDirGuard now owns the dir for the whole bake; the block comment claiming "a failure at any of those steps drops the staging dir" was not implemented and now is.

The guard holds the path, not a handle, so the successful rename of files out of the dir is unaffected, and the redundant success-path remove_dir_all is gone.

Tests

Guard removal and tolerance of an already-removed dir (the success path may have emptied it, and a stale sweep may beat the guard to it); the probe's ancestor walk, which is what makes it usable before the snapshot dir exists.

cargo fmt --check clean, cargo clippy --all-targets --all-features -D warnings clean, cargo test -p forkd-cli green (56 passed, 1 ignored). No KVM run — both changes are filesystem-level.