You click Start on a VM, or maybe just Shutdown, and instead of doing what you asked, Proxmox throws back something like TASK ERROR: VM is locked (backup). There's no explanation on screen and no obvious button to fix it. As far as you know, nothing is running on that VM right now.
This happens more often than you'd expect, and it's almost never actually broken. A backup job got interrupted, a migration didn't finish cleanly, or you closed the browser tab in the middle of a snapshot operation. Proxmox left itself a note saying "don't touch this VM yet," and that note never got erased. This guide walks through what these locks actually are, how to tell whether it's safe to remove one, and the exact commands to clear it — for both virtual machines and LXC containers.
What You Will Learn
- What a VM or container lock actually is, and where Proxmox stores it
- Why the lock system exists, and why you shouldn't just fight past it blindly
- How to check whether a lock is safe to remove or a job is still genuinely running
- The
qm unlockandpct unlockcommands, plus a manual fallback - What each lock type (backup, migrate, snapshot, and so on) actually means
- How to stop this from happening on the same VM every week
What Is a Proxmox VE Lock?
Every VM and container in Proxmox VE has a configuration file — plain text, nothing fancy. For VMs it lives at /etc/pve/qemu-server/<vmid>.conf, and for LXC containers it's at /etc/pve/lxc/<ctid>.conf. Open one up and you'll see lines like memory: 4096, cores: 2, and net0: virtio=....
When Proxmox starts a task that shouldn't be interrupted — a backup, a live migration, a snapshot rollback — it adds one more line to that file: lock: backup, lock: migrate, lock: snapshot, and so on. That single line is the whole mechanism. There's no hidden database or background daemon tracking state; it's one line in a config file that Proxmox checks before letting you run most other operations against that guest.
The /etc/pve/ directory itself is worth knowing about too. It's not a normal filesystem — it's pmxcfs, the Proxmox cluster filesystem, which keeps configuration in sync across every node in a cluster (or just stores it locally if you're running a single standalone server). That's why a lock set on one node is visible and enforced cluster-wide.
Current Proxmox VE releases (8.x and 9.x) recognize the following lock values: backup, clone, create, migrate, rollback, snapshot, snapshot-delete, suspended, and suspending. Each one corresponds to a specific operation that was in progress when the lock got written.
Why Would You Use It?
You don't set a lock yourself in normal use — Proxmox manages this automatically. The reason it exists is straightforward: you shouldn't be able to delete a VM while it's mid-backup, and you shouldn't be able to start a migration on a container that's already migrating somewhere else. Locks stop two conflicting operations from touching the same guest at the same time and corrupting something in the process.
Honestly, most of the time you'll never notice this mechanism working at all. It does its job silently, sets the lock, finishes the task, and removes the lock again in under a second. The only time it becomes visible is when something interrupts the task before it can clean up after itself — a crashed backup job, a node that lost power mid-migration, a browser tab closed during a snapshot. That's when the lock gets stuck, and you're the one who has to clear it.
Prerequisites
Before you start, make sure you have:
- Root or sudo-level SSH access to your Proxmox VE host, or access to the Shell from the web GUI (click your node, then Shell in the left menu)
- The VMID or CTID of the affected guest — you'll see this as the number next to the VM or container name in the resource tree
- A Proxmox VE 8.x or 9.x installation (the commands here haven't changed in years and are unlikely to change soon)
- A few minutes to actually check what's going on before you run anything — this is the part people skip, and it's the part that matters most
Step-by-Step Tutorial
Step 1: Confirm the guest is actually locked
Log into the Shell (either via SSH or the GUI console) and run:
qm config 100 | grep lockReplace 100 with your actual VMID. If a lock is set, you'll see a line like lock: backup. No output means no lock — whatever error you're seeing has a different cause. For a container, swap qm for pct:
pct config 101 | grep lockYou can also see this in the web GUI: click the VM, and if it's locked you'll usually notice a small padlock icon next to the status, or the buttons for Start/Stop/Migrate will be greyed out.
Step 2: Check whether the job is actually still running
This is the step that saves you from a bad day. Before removing anything, go to Datacenter → Tasks (or the node's own Task History) and look for a task tied to that VMID — backup, migration, snapshot — that's still showing as running rather than finished or failed. You can also check from the shell:
ps aux | grep -E "vzdump|qmigrate|qm"If you see an active vzdump process still writing to your backup storage, or a migration still transferring data, leave it alone. Removing a lock on a task that's genuinely still in progress can corrupt the backup file or leave the VM in a half-migrated, unbootable state. If the task list shows the job ended hours ago — finished, failed, or was aborted — and nothing shows up in ps aux, it's safe to move on.
Step 3: Remove the lock
For a virtual machine:
qm unlock 100For an LXC container:
pct unlock 101Both commands do the same thing — they strip the lock: line out of the guest's config file. There's no confirmation prompt and no output on success, which throws people off the first time. No news is good news here.
Step 4: Verify it worked
qm config 100 | grep lockIf that returns nothing, the lock is gone. Head back to the GUI and try the original action again — start the VM, open the console, whatever you were trying to do before the error showed up.
Step 5 (fallback): Edit the config file directly
On the rare occasion qm unlock itself errors out (this can happen if pmxcfs is having trouble, which is a separate problem worth investigating on its own), you can remove the line by hand:
nano /etc/pve/qemu-server/100.confFind the line that says lock: backup (or whatever type it shows), delete that entire line, then save with Ctrl+O and exit with Ctrl+X. For a container, edit /etc/pve/lxc/101.conf the same way. This is functionally identical to running the unlock command — it's just doing it by hand.
Commands Explained
| Command | What it does |
|---|---|
qm config <vmid> | Prints the full configuration of a VM, including its lock state if one is set |
pct config <ctid> | Same thing, for LXC containers |
qm unlock <vmid> | Removes the lock entry from a VM's config file |
pct unlock <ctid> | Removes the lock entry from a container's config file |
ps aux | grep vzdump | Lists running processes and filters for anything related to the vzdump backup tool, so you can confirm a backup is (or isn't) actually still running |
qm status <vmid> | Shows whether the VM is currently running, stopped, or in some other state — useful alongside the lock check |
Common Errors
These are the exact messages you'll typically run into, each tied to a different lock type:
TASK ERROR: VM is locked (backup)— a vzdump backup job was interrupted or crashedTASK ERROR: VM is locked (migrate)— a live or offline migration didn't completeCT is locked (snapshot-delete)— a snapshot deletion on a container stopped partway throughVM is locked (mounted)— usually appears if a backup or file-restore operation left a disk image mountedtrying to acquire lock...followed by a timeout — a slightly different issue, usually a stale.lockfile under/var/lock/qemu-server/rather than the config-based lock covered here
Troubleshooting
If qm unlock returns something like unable to open file '/etc/pve/qemu-server/100.conf.tmp.XXX' - Permission denied, you're not running the command as root. Prefix it with sudo or switch to the root shell.
If the lock comes back on its own within minutes of clearing it, don't just keep unlocking it — that's a symptom, not the problem. Check Datacenter → Backup for a job that's repeatedly failing on this VM. A common culprit is backup storage that occasionally drops out mid-job (an NFS share that hiccups, a USB drive that disconnects), which crashes vzdump partway through and leaves the lock behind every time the schedule fires.
If qm unlock hangs entirely or every command against /etc/pve/ times out, the problem probably isn't the VM at all — it's pmxcfs. Run pvecm status to check cluster health, and systemctl status pve-cluster to see if the cluster filesystem service itself is unhappy. That's a bigger issue than a stuck VM lock and deserves its own investigation before you touch anything else.
One more scenario worth mentioning: on a multi-node cluster, a lock set on one node is visible from every other node, because they all read the same /etc/pve/ filesystem. If you're troubleshooting from a different node than the one that originally started the job, that's completely normal — you don't need to SSH into the specific node that triggered the backup or migration. Any node in the cluster can run the unlock command.
Best Practices
Always check the task log before unlocking anything. It takes ten seconds and it's the difference between clearing a harmless leftover and corrupting a backup that's genuinely still writing.
Don't make a habit of unlocking the same VM over and over without asking why. If a particular guest keeps ending up locked after backups, that's Proxmox telling you the underlying job isn't finishing cleanly — fix the storage or network issue causing the crash instead of treating the symptom every time.
Keep your backup and migration storage stable. Most stuck locks I've seen trace back to unreliable network storage — an NFS mount that drops for a few seconds is enough to kill a vzdump job midway and leave the config locked behind it.
Frequently Asked Questions
Is it safe to unlock a VM that's currently running normally?
Yes. Unlocking only removes the lock line from the config file — it has no effect on whether the VM itself is powered on or off, and it doesn't touch your data or disks.
What's the actual difference between qm unlock and pct unlock?
qm manages QEMU/KVM virtual machines, and pct manages LXC containers — they're separate tools for separate guest types, but the unlock behavior is identical between them.
The GUI doesn't show a lock icon, but I still get "VM is locked." Why?
Run qm config <vmid> | grep lock directly — the GUI's visual indicator isn't always obvious depending on your browser window size and Proxmox version. The config file is the source of truth.
Can I just delete the whole config file instead of editing out the lock line?
No — don't do that. The config file holds your VM's entire hardware definition: disks, network cards, memory, everything. Deleting it (rather than just the one lock line) will make Proxmox lose track of the VM completely.
Does unlocking a VM delete or affect its disks?
No. The lock is purely a flag in the configuration file. Your virtual disks, whether on local-lvm, ZFS, or shared storage, are completely untouched by running qm unlock.
Will this happen again after I unlock it once?
Possibly, if the same job keeps failing on the same schedule. A single stuck lock after a one-off event — a reboot during a backup window, a browser crash mid-snapshot — is nothing to worry about. A lock that reappears every night points at a recurring problem with that specific backup or migration job, not a Proxmox bug.
Conclusion
A stuck lock looks alarming the first time you hit it, mostly because Proxmox doesn't explain itself — you just get a terse task error and a VM that won't respond to anything. Once you know it's just one line in a text file left behind by an interrupted job, it stops being scary. Check the task log, confirm nothing's actually still running, run qm unlock or pct unlock, and you're back to normal in under a minute. The only real trap is doing it out of habit without checking first — that's how a five-second fix turns into a corrupted backup.