fix: remove stopped containers referencing a volume before restore - #5225
fix: remove stopped containers referencing a volume before restore#5225Siumauricio wants to merge 3 commits into
Conversation
Volume restore aborted with "volume is in use" whenever a stopped container still referenced the target volume, forcing users to SSH in and remove it manually. Running containers still block the restore, but stopped ones are now removed automatically before the volume is recreated. Fixes #3995
dosubot
Bot
added
the
size:M
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| RUNNING_CONTAINERS=$(echo "$CONTAINERS_USING_VOLUME" | awk -F'|' '$3 == "running"') | ||
| STOPPED_CONTAINERS=$(echo "$CONTAINERS_USING_VOLUME" | awk -F'|' '$3 != "running"') |
There was a problem hiding this comment.
When a volume-referencing container is paused or restarting, $3 != "running" classifies it as stopped and passes it to docker rm -f, causing an active workload to be forcibly deleted before its volume is replaced.
Knowledge Base Used:
| echo "$STOPPED_CONTAINERS" | while IFS='|' read container_id container_name container_state labels; do | ||
| echo " 🗑 Removing stopped container: $container_name ($container_id) [status: $container_state]" | ||
| docker rm -f "$container_id" >/dev/null 2>&1 || true | ||
| done | ||
|
|
||
| echo "" | ||
| echo "❌ Volume restore aborted - volume is in use" | ||
|
|
||
| exit 1 | ||
| echo "Removing existing volume and proceeding with restore" | ||
| docker volume rm ${volumeName} --force |
There was a problem hiding this comment.
When docker rm -f leaves a container attached, || true suppresses the error and the script also continues after the resulting volume-removal failure. The restore then extracts into the existing volume, leaving files absent from the backup in place while reporting a successful restore.
Knowledge Base Used:
| echo "$STOPPED_CONTAINERS" | while IFS='|' read container_id container_name container_state labels; do | ||
| echo " 🗑 Removing stopped container: $container_name ($container_id) [status: $container_state]" | ||
| docker rm -f "$container_id" >/dev/null 2>&1 || true |
There was a problem hiding this comment.
If a stopped container starts after the one-time docker ps -a snapshot, the removal loop does not recheck its state before invoking docker rm -f, causing the newly active workload to be deleted while restore proceeds toward replacing its volume.
Knowledge Base Used: Backups and restore
- Only treat exited/created/dead containers as safely removable; paused/restarting/removing containers now still block the restore like a running one does. - Re-check each container's live state right before removing it, to avoid deleting one that started running again after the initial docker ps -a snapshot. - Stop swallowing docker rm/docker volume rm failures with '|| true'; abort the restore instead of silently continuing and extracting into a volume that may still be attached to a container.
dosubot
Bot
added
size:L
The restore script runs under /bin/sh, not bash. Process substitution
("< <(...)") is a bashism dash doesn't support, so the previous fix
failed at runtime with a syntax error and the restore never ran.
Write STOPPED_CONTAINERS to a temp file and read the while loops from
that instead — same effect, works under plain POSIX sh.
1 participant
Fixes #3995
Volume restore aborted with "volume is in use" whenever a stopped/exited container still referenced the target volume, forcing users to SSH in and manually remove the container before restoring. This is common after stopping a compose service from the UI — Docker keeps the exited container attached to the volume.
Change
In
restoreVolume's in-use check, containers referencing the volume are now split into running vs stopped:docker rm -f) before the volume is recreated and the restore proceeds.Verified
Reproduced end-to-end against a local Dokploy instance (Playwright UI + real Docker):
exitedbut kept referencing the volume.Greptile Summary
This PR allows volume restores to remove containers considered stopped before recreating the target volume.
Confidence Score: 2/5
The PR is not safe to merge until automatic removal is restricted to confirmed stopped containers and all destructive preconditions are revalidated and enforced.
The changed restore path can force-delete paused, restarting, or concurrently started containers, and ignored cleanup failures can make an overlay extraction into the old volume appear successful.
Files Needing Attention: packages/server/src/utils/volume-backups/restore.ts
Reviews (1): Last reviewed commit: "fix: remove stopped containers referenci..." | Re-trigger Greptile
Context used: