Recovering a VMware Workstation VM Encryption Password on Linux (Moving a VM Between Machines)

IT & Systems
, , , ,
1

Moved an encrypted VMware Workstation VM to another Linux machine and hit a password prompt you never set? Here is why it happens and how to get back in.

This walks through recovering a VMware Workstation VM encryption password on Linux when you copy a virtual machine between machines. It covers how to confirm the problem, pull the saved password off the original machine, and seed it into the new machine’s keyring so the VM unlocks silently.

A note on scope: This is for VMware Workstation’s own VM-level encryption on Linux, using the desktop Secret Service (GNOME Keyring or KWallet). Exact package names and menu wording can differ a little between distributions and VMware versions, but the method is the same. This is not for a guest OS login password or a BIOS password.

The symptom

You copy a VMware Workstation virtual machine from one Linux machine to another. On the original machine it powers on fine, with no password prompt. On the new machine, VMware Workstation says the VM is encrypted and asks for a password you do not remember ever setting.

Why this happens

VMware Workstation VM encryption is used for full VM encryption, and it is switched on automatically when you add a virtual TPM, which Windows 11 guests require. It is passphrase-protected at the file level. The .vmx file contains:

encryptedVM.guid = "{...a GUID...}"
encryption.keySafe = "vmware:key/list/(pair/(phrase/...
encryption.data = "..."

The keySafe line is your disk encryption key, wrapped (“safed”) by a passphrase using PBKDF2. To actually decrypt the VM, VMware needs that passphrase.

The part that is easy to miss: when you check “remember this password” in VMware Workstation, or it is remembered by default, the passphrase itself is not stored in the .vmx. It is stored in your operating system’s credential store, keyed to the exact file path and GUID of that VM on that specific machine:

  • Windows: Windows Credential Manager. A public method to extract it exists, a PowerShell script using the CredReadW Win32 API. Search GitHub for “VMware encrypted VM password recovery PowerShell”.
  • Linux: the desktop Secret Service (GNOME Keyring or KWallet via libsecret), under schema com.vmware.password.encryptedVM.

Because that credential store is per-machine, copying the VM’s files does not copy the saved password. The original machine still has it cached in its keyring. The new machine does not, which is why you get the prompt.

Step 1: Confirm this is what is going on

On the new (locked) machine, find the copied VM’s .vmx and check for encryption metadata:

grep -iE "encrypt" "/path/to/Your VM/Your VM.vmx"

If you see encryptedVM.guid and encryption.keySafe, this is genuine VM-level encryption, not a guest-OS password and not a BIOS password. This is VMware’s own file encryption.

Step 2: Retrieve the saved password from the original machine

On the original machine, the one that opens the VM without prompting, get the GUID from its copy of the .vmx:

grep "encryptedVM.guid" "/path/to/Your VM/Your VM.vmx"
# encryptedVM.guid = "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"

Then search the Secret Service keyring for it:

secret-tool search encryptedVM.guid "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"

If the password was ever saved, this prints something like:

label = VMware Encrypted VM: /path/to/Your VM/Your VM.vmx
secret = <the actual password>
schema = com.vmware.password.encryptedVM
attribute.path = /path/to/Your VM/Your VM.vmx
attribute.encryptedVM.guid = {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}

secret-tool needs libsecret-tools on Debian and Ubuntu, or libsecret on Fedora, where it is usually already present. If it is not installed:

sudo apt install libsecret-tools   # Debian / Ubuntu
sudo dnf install libsecret         # Fedora

If nothing is found here, the password was never saved to the keyring on this machine either, which means it is genuinely not recoverable this way. There is no VMware backdoor for a truly forgotten encryption password. You would need an unencrypted backup, or to accept that the data is inaccessible.

Step 3: Seed the password into the new machine’s keyring

You have two options at this point.

Option A: Just type the password when prompted

Simplest. Paste the recovered password into the VMware Workstation prompt on the new machine. This decrypts and boots the VM, but VMware will likely ask again next time unless it re-saves it for you.

Option B: Pre-seed the new machine’s keyring

This makes it never prompt, matching the original machine’s behavior.

Find the VM’s local path on the new machine and confirm the GUID matches. It will, because it is the same file, copied:

find / -maxdepth 8 -iname "Your VM.vmx" 2>/dev/null
grep "encryptedVM.guid" "/local/path/to/Your VM/Your VM.vmx"

Store the password with the same schema and attributes VMware itself uses, so its lookup finds it:

printf '%s' 'THE_RECOVERED_PASSWORD' | secret-tool store \
  --label="VMware Encrypted VM: /local/path/to/Your VM/Your VM.vmx" \
  xdg:schema "com.vmware.password.encryptedVM" \
  encryptedVM.guid "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}" \
  path "/local/path/to/Your VM/Your VM.vmx"

Details that are easy to get wrong:

  • Attribute names must match exactly: path and encryptedVM.guid, plus the xdg:schema attribute set to com.vmware.password.encryptedVM. Without xdg:schema, the entry still gets created, but under a generic default schema that VMware’s lookup may not match against.

  • The path must be the local file path on the machine you are storing it on, not the original machine’s path. Each machine’s keyring entry is scoped to its own filesystem path for that VM.

  • If you experiment and end up with duplicate or incomplete entries, clear them first so there is only one clean entry:

    secret-tool clear encryptedVM.guid "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}" path "/local/path/to/Your VM/Your VM.vmx"

    then re-run the store command above.

Verify it landed correctly:

secret-tool search encryptedVM.guid "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"

You should see the same schema = com.vmware.password.encryptedVM line as the original machine’s entry.

Step 4: Relaunch VMware Workstation

If VMware Workstation was already running while you did this, fully quit it, not just the VM tab, and reopen it so it re-queries the keyring. Then power on the VM. It should unlock silently, just like on the original machine.

Longer-term fix

If you plan to keep copying this VM around, consider removing VM-level encryption entirely once you are unlocked, via VM, Settings, Options, Access Control (uncheck encryption). This avoids the whole keyring dance on future copies.

Keep in mind that if the VM has a virtual TPM, which is common for Windows 11 guests, VMware may re-require encryption automatically. In that case, this keyring-seeding trick is the practical workaround for moving it between your own machines.

Security note

The recovered password is plaintext-recoverable by anyone with access to either machine’s user account or keyring. This is not a weakness specific to this trick. It is inherent to how “remember password” works for VM encryption on both Windows and Linux. Treat access to either machine’s login and keyring with the same care you would give the VM’s contents.

Did this get you back into your VM, or did you hit a step that behaved differently on your setup? Let me know below.