I fixed this on an Apple-silicon Mac running Parallels Desktop with a Windows 11 VM.
The root cause was that the VM’s TPM state file, NVRAM.tnvs, was owned by root, while the VM was being started by my macOS user. After correcting the ownership, Parallels reported that the file had an invalid signature. Renaming the damaged TPM file allowed Parallels to create a new TPM state and the VM started normally.
Steps:
- Make sure the Windows VM is completely stopped.
- Open Terminal and list the VMs:
prlctl list -a -o name,status,uuid
Copy the UUID of the affected VM and define the paths:
VM_ID="{paste-the-VM-UUID-here}"
VM_PATH="/Users/YOUR_MAC_USERNAME/Parallels/Windows 11.pvm"
Replace YOUR_MAC_USERNAME with your macOS username and adjust the VM path if necessary.
- Check the TPM file ownership:
ls -ldeO@ "$VM_PATH/NVRAM.tnvs"
If the file is owned by <span>root</span>, change only this file back to the logged-in macOS user:
sudo chown "$(id -un):$(id -gn)" "$VM_PATH/NVRAM.tnvs"
Do not change or delete the virtual hard disk, and do not use a recursive permission change unless you have verified that the whole VM bundle is affected.
- Try starting the VM:
prlctl start "$VM_ID"
If the VM starts successfully, verify its state:
prlctl list -a -o name,status,uuid
- If the start still fails with <span>Operation canceled</span>, check the latest Parallels log entries:
tail -n 250 "$VM_PATH/parallels.log" \<br> | grep -a -E 'TPM NVS|PRL_WARN_TPM|invalid signature|VM state|VM successfully'
If the log contains:
TPM NVS ... invalid signature
rename the invalid TPM file instead of deleting it:
STAMP=$(date +%Y%m%d-%H%M%S)<br>mv "$VM_PATH/NVRAM.tnvs" "$VM_PATH/NVRAM.tnvs.invalid-$STAMP"
Then start the VM again:
prlctl start "$VM_ID"
In my case, Parallels created a new NVRAM.tnvs file automatically, and the Windows 11 VM reached the desktop.
Verify that the VM is running and that the new TPM file exists:
prlctl list -a -o name,status,uuid<br>ls -l "$VM_PATH"/NVRAM.tnvs*
Important warning: renaming the TPM file causes Parallels to create a new virtual TPM state. This can affect Windows Hello, the Windows PIN, and other TPM-bound credentials. If BitLocker is enabled, make sure you have the BitLocker recovery key before doing this. Keep the renamed file until Windows has been fully tested.
I did not replace NVRAM.tnvs with NVRAM.tnvs.old, because the old file may belong to a different TPM encryption key.