You click power on and VMware answers with Failed to lock the file, or Cannot open the disk, or insists the virtual machine appears to be in use - usually the morning after the host crashed or lost power. The VM is almost never damaged. It is guarded by its own leftover lock files, and removing them safely is a two-minute job.
While a VM runs, Workstation creates small lock folders ending in .lck next to the VM's files so nothing else can open them. A host crash, a power cut, or a forced shutdown can leave those locks behind after the VM itself is long dead. The fix is real but must be done carefully and in order: prove nothing is running, let Workstation's own prompt try first, and delete only the lock folders - never the VM's actual files.
The lock is a safety feature, not corruption. Workstation refuses to open a disk that another process claims to hold, because two writers on one virtual disk would destroy it. After an unclean host shutdown, the claim outlives the process that made it. Your job is simply to prove the claim is stale and clear it - not to repair the disk, which is almost certainly fine.
This step is the whole safety of the procedure, so do not shortcut it:
vmware-vmx.exe - a still-running copy means a VM process survivedReopen Workstation and try the VM again. If it says the virtual machine appears to be in use and offers a Take Ownership button, use it - that is the supported route and it clears the stale state itself. Many people delete files manually without ever seeing this prompt because they edited the folder before reopening Workstation. Only move to the manual step if the prompt never appears or power on still fails with the lock error.
With Workstation fully closed, open the VM's folder on the host. If space allows, copy the whole folder somewhere safe first - cheap insurance. Then delete only the folders whose names end in .lck, such as the ones beside the .vmdk and .vmx files. Nothing else. Reopen Workstation and power on. The VM should start normally, because the locks regenerate fresh each run and vanish on a clean shutdown.
Honesty line: lock removal fixes lock errors only. If power on now complains that a file cannot be found, or the snapshot chain is inconsistent, that is a different and more serious problem - do not keep deleting things in hope. Restore the VM folder from the copy you made, or from your backup, and treat it as a recovery job. Guessing your way through a broken snapshot chain is how recoverable VMs become unrecoverable.
The video works through VMware problems step by step without panic deletions - watch it before you touch a VM folder in anger.
Watch Full VideoYes. The lock folders hold no user data at all - they are small flag folders Workstation creates while a VM runs. Your data lives in the .vmdk disk files, which you did not touch. The VM will create fresh locks next run and remove them on a clean shutdown.
Because the host keeps dying underneath the VM - power cuts, crashes, or the host being forced off while VMs run. Every unclean host shutdown risks stale locks. A small UPS for the host and clean shutdowns of VMs before the host stops will end the pattern.
No - that error points at the disk or snapshot chain itself, not at lock flags. Do not apply the lock fix repeatedly and do not delete snapshot files. Back up the VM folder as it stands and treat it as a recovery job, ideally from your last good backup.