Why Does a Btrfs Snapshot Stay Busy After Every App Container Stops?

A stopped container can leave a Btrfs snapshot busy when another process, mount namespace, bind mount, send job, or nested subvolume still references it.

Stopping an application container ends its main process, but it does not prove that every related mount, helper process, runtime shim, shell session, backup job, or namespace has released the snapshot path. Btrfs can also reject deletion when the target is mounted, involved in send, configured as the default subvolume, or contains nested subvolumes. Diagnose the exact reference before forcing an unmount or deleting container data.

Confirm the Exact Btrfs Object and Error

Record the full snapshot path, subvolume ID, parent ID, read-only state, UUID, received UUID, and the exact deletion error. Confirm that the path is a Btrfs subvolume rather than an ordinary directory inside one.

The Btrfs subvolume reference explains that snapshots are subvolumes and documents conditions that prevent deletion, including default-subvolume status and an active send operation.

If the error is not EBUSY, follow the actual failure. Permission, read-only mount, default-subvolume, and nested-subvolume problems require different checks from an active mount reference.

Separate Container Stop From Container Removal

List containers in running, stopped, dead, and removing states. Record the container IDs that used the snapshot through bind mounts, named volumes, or a Btrfs storage driver.

Docker’s CLI reference shows that docker stop signals the main process; it does not mean the container definition, runtime metadata, or every host-side storage relationship has been removed.

Do not delete the snapshot merely because the application UI says the stack is stopped. Check whether a restart policy, health helper, exec shell, sidecar, or container runtime process still exists.

Inspect Mounts in Every Relevant Namespace

Compare the host mount table with the mount namespaces of the container runtime, stopped-container helpers, backup agents, and any long-lived shell that entered the container.

The Linux manual explains that mount namespaces isolate mount lists, so a path can appear unmounted on the host while remaining mounted inside another process namespace.

Use process-specific mount information rather than checking only the current shell. A lazy unmount from the host can hide the symptom without releasing the namespace that still owns the reference.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Look for Container Mounts That Survived in Another Namespace

Identify the process ID of the container runtime, shim, monitoring agent, or helper that may retain the namespace. Inspect its mount tree and the source path corresponding to the Btrfs snapshot.

Red Hat documents a verified case where a mount in another namespace causes device-or-resource-busy cleanup errors, matching the situation where the host appears clear but the snapshot remains referenced.

Terminate only the proven stale helper or restart the relevant runtime during a maintenance window. Killing unrelated namespace owners can disrupt other containers and mounts.

Use fuser and Open-Handle Checks With Namespace Limits in Mind

Check open files, current working directories, mapped files, and mount users under the snapshot path. Run the tools with sufficient privileges and compare their process list with runtime processes.

Debian’s fuser manual warns that it may not see block devices mounted by processes in a different mount namespace, so an empty result does not prove the snapshot is unused.

Also check for shell sessions whose current directory is inside the snapshot, file-indexing services, antivirus scanners, backup readers, and application log tailers. Close one confirmed user at a time and retry the read-only status check.

Rule Out Mounted, Default, Nested, and Sending Subvolumes

List every mount that resolves to the snapshot’s subvolume ID, check the filesystem’s default subvolume, enumerate nested child subvolumes, and inspect active Btrfs send jobs.

ArchWiki advises that a mounted subvolume should not be deleted, making mount identity and nested layout required checks before removal.

Stopping app containers does not stop an independent Btrfs send, snapshot replication, or backup process. Wait for the send to finish or stop it cleanly, then recheck the snapshot state.

Release the Proven Reference and Delete Safely

Unmount the snapshot from the namespace that owns it, remove or restart the stale container runtime object when appropriate, exit working directories, stop the confirmed send task, and delete nested subvolumes in dependency order.

The ZimaSpace article on snapshotting NAS app data provides the adjacent context for identifying which persistent paths and application states a container snapshot actually covers.

The issue is resolved when no namespace or process references the subvolume, the correct non-default snapshot deletes through the supported Btrfs command, background cleanup completes, and the application stack restarts with its intended live data paths intact.