Skip to content
Commitpedia
Log in Join & edit

Fix: TASK ERROR: VM is locked (backup)

A VM or container still carries a backup lock, usually after a backup was interrupted. Check that no backup is running, then remove the stale lock with qm unlock or pct unlock.

Not checked by a trusted editor yet Last edited Outdated?

Edit history of Fix: TASK ERROR: VM is locked (backup): 1 recorded edit
Edit history · 1 edit
Type
Article
Edits
1
Editors
1
First issued
15 Oct 2026
Last edit
15 Oct 2026
Reading
2 min

When you try to start, stop, change or back up a guest, the task fails with:

TASK ERROR: VM is locked (backup)

In a backup job log the same problem appears as ERROR: Backup of VM 108 failed - VM is locked (backup). The word in brackets names the operation that set the lock; you may also see (migrate), (snapshot) or (clone).

What the lock means

Backups, snapshots and migrations put a lock: line into the guest’s configuration so that no conflicting action runs at the same time. The lock is removed when the task ends. If the task is interrupted, the lock can stay behind. Common causes, most likely first:

  1. A backup is still running, for example a long nightly job. Then the error is correct and you only need to wait.
  2. A backup was stopped or aborted (for example with the Stop button) and left the lock behind.
  3. The backup target went away or ran full during the backup (NAS rebooted, network storage unreachable, “No space left on device”).
  4. The node crashed or rebooted during the backup, for example from memory or I/O pressure.
  5. The guest agent hung while freezing file systems for a snapshot-mode backup.

Fix it step by step

  1. Confirm the lock and its type: qm config 108 | grep lock (or pct config 108 | grep lock for a container).
  2. Make sure no backup is running. Check the task list at the bottom of the web UI, or run pvenode task list --source active on the node, and look for a vzdump process with ps aux | grep [v]zdump.
  3. If a backup is still running, let it finish or stop it from the task viewer, then check whether the lock is gone.
  4. If no task is running, remove the stale lock on the node that hosts the guest: qm unlock 108 for a VM or pct unlock 108 for a container.
  5. Retry the original action, then run a manual backup to confirm backups work again.
qm config 108 | grep lock
pvenode task list --source active
ps aux | grep [v]zdump
qm unlock 108
vzdump 108 --storage nas-backup

Only unlock when you are sure the operation that set the lock is no longer running. Unlocking a guest during an active backup or migration can lead to inconsistent backups or a broken migration.

If unlocking fails

If qm unlock fails with an error about files under /etc/pve, the cluster file system may be read-only, for example because the node lost quorum. Check pvecm status and systemctl status pve-cluster corosync and fix quorum first.

Prevent it from happening again

  • Look at the failed backup’s task log to find the real cause: storage errors, timeouts or out-of-space messages.
  • Make sure the backup storage has enough free space and use retention (prune-backups) so old backups are removed.
  • Avoid aborting running backups unless necessary, and check for leftover locks afterwards (for example with pvesh get /cluster/resources --type vm, which shows a lock field).

Official documentation

Did this work for you?

No votes yet. Be the first.

If it did not work, the report form below tells the editors what went wrong.

See also

Repos in the wild

History

Every saved edit is kept. The plot on the sleeve draws one line per edit. Open any edit to see exactly what changed.

  1. Commitpedia +2,927 chars

Report a problem

Something wrong, unsafe or copied? Tell the editors.
What is wrong?