VMware Fusion Cannot Unlock a Virtual Machine From the CLI
Unlocking a virtual machine from the command line was not reliable in VMware Fusion on macOS. The limitation was easy to misread as an incorrect command, a damaged virtual machine, or a stale lock file, because all three can produce similar-looking failures.
The useful comparison was running the same task in VMware Workstation on Windows. Against a comparable virtual-machine setup, the command-line workflow worked there. That moved the focus away from the VM and toward the difference between the two VMware products.
Why the comparison matters
Virtual machines often carry state that makes troubleshooting noisy: snapshots, lock files, suspended sessions, and paths that differ from one host to another. If a command fails only in Fusion, it is tempting to keep changing the command until it appears to work.
Testing the equivalent operation in Workstation is more informative. It keeps the intended action the same while changing the product responsible for managing the VM. In this case, that comparison showed that the CLI approach itself was viable; Fusion on macOS was the limiting environment.
What not to conclude
This does not mean every Fusion command-line operation is broken, or that every VM lock has the same cause. A lock can still be legitimate when a VM is running or when another process owns it. Check that first.
The conclusion is narrower: when this VM-unlock workflow is required, VMware Fusion does not provide the same dependable CLI behaviour as VMware Workstation did in the tested setup.
What to use instead
When command-line unlocking is part of the workflow, use VMware Workstation on Windows for that task. It produced the expected result without having to alter the virtual machine just to accommodate the host application.
If moving the work to Workstation is not practical, use Fusion’s supported graphical controls and confirm that the VM is fully powered off before changing anything. Avoid deleting lock-related files by hand unless their purpose is understood; doing that while a process still owns the VM can turn a manageable lock into a damaged state.
A useful troubleshooting record
When you run into this, record the product version, macOS or Windows version, VM power state, and the exact command result. That makes it possible to distinguish a product limitation from an environment-specific regression later.
For this case, the final answer was straightforward: the command worked in VMware Workstation on Windows, but not reliably in VMware Fusion on macOS. Treat Fusion as the constraint and choose the tool accordingly.