How to Fix VMware’s “Could not open /dev/vmmon” Error on Ubuntu

You’ve recently installed VMware Workstation on your Ubuntu system and encountered the frustrating “Could not open /dev/vmmon: No such file or directory” error ?

This common issue affects many users, particularly after Ubuntu updates or when using newer kernel versions with Secure Boot enabled. In this comprehensive guide, I’ll walk you through the underlying cause and provide a step-by-step solution that has worked consistently for me and thousands of other users.

As someone who’s faced this issue multiple times across different Ubuntu versions (from 18.04 through 22.04), I’ve refined this process to be as straightforward as possible. Let’s dive in and get your VMware installation working properly!

Sponsored

Understanding the Root Cause

Before jumping into the solution, it’s worth understanding why this error occurs in the first place. The issue stems from Ubuntu’s implementation of Secure Boot, a security feature that prevents unauthorized code from loading during the boot process.

When you install VMware, it needs to load kernel modules (vmmon and vmnet) to function properly. However, with Secure Boot enabled, these modules must be digitally signed with a trusted certificate before they can be loaded into the kernel. Without proper signing, the system rejects them, resulting in the “Could not open /dev/vmmon” error.

Read: How to install Linux on Windows With a VMware Virtual Machine

Prerequisites

Before we begin, ensure you have:

• Ubuntu 18.04 or newer installed
• VMware Workstation/Player installed (these steps work for versions 15 and above)
• Administrator (sudo) privileges
• Terminal access

Step-by-Step Solution

1. Attempt Basic Module Configuration

Let’s start with the simplest approach, which sometimes resolves the issue without further intervention:

sudo vmware-modconfig –console –install-all

This command attempts to compile and install all necessary VMware kernel modules. If you’re lucky, this might be all you need. However, if you still encounter the error, proceed to the next steps.

2. Create a Signing Key

We need to create a cryptographic key that will be used to sign the VMware kernel modules:

openssl req -new -x509 -newkey rsa:2048 -keyout VMWARE15.priv -outform DER -out VMWARE15.der -nodes -days 36500 -subj “/CN=VMWARE/”

This command creates two files:

• VMWARE15.priv: The private key used for signing
• VMWARE15.der: The public key that will be enrolled in your system’s MOK (Machine Owner Key) store

I’ve found that using a unique name for these keys (like VMWARE15 instead of just VMWARE) often helps avoid conflicts with existing keys.

3. Sign the VMware Kernel Modules

Now, we’ll use our newly created key to sign the VMware kernel modules:

sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./VMWARE15.priv ./VMWARE15.der $(modinfo -n vmmon)

sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./VMWARE15.priv ./VMWARE15.der $(modinfo -n vmnet)

These commands don’t provide any output if successful. To verify that the signatures were properly applied, run:

tail $(modinfo -n vmmon) | grep “Module signature appended”

If successful, you should see the output: Binary file (standard input) matches

4. Register the Key with the MOK System

For our signed modules to be recognized, we need to register our key with the MOK (Machine Owner Key) management system:

sudo mokutil –import VMWARE15.der

You’ll be prompted to create a one-time password. Make sure to use something memorable but secure (like VMware2023!) as you’ll need to enter it during the next boot.

Read: How to Fix the VMware , Sound Device ID Out of Range ,Error on Linux

5. Reboot and Enroll the Key

Now comes the important part:

sudo reboot

During the reboot process, you’ll be presented with a blue MOK management screen. Here’s what to do:

1. Select “Enroll MOK”
2. Choose “Continue”
3. Select “Yes” when asked if you want to enroll the key
4. Enter the password you created in the previous step
5. Select “OK” to complete the process and reboot

If you miss this screen, you’ll need to reboot again and watch carefully for the MOK management screen. Sometimes you need to press any key repeatedly during boot to access it.

6. Verify the Key Enrollment

After your system boots back up, verify that your key was successfully enrolled:

mokutil –test-key VMWARE15.der

If successful, you should see the message: VMWARE15.der is already enrolled

7. Launch VMware

Now try launching VMware again. The error should be resolved, and you should be able to create and run virtual machines without issue.

Alternative Solutions

Disable Secure Boot

If you’re still encountering issues or prefer a simpler solution, you can disable Secure Boot in your BIOS/UEFI settings. This approach eliminates the need for signing kernel modules but reduces system security.

To disable Secure Boot:

1. Restart your computer and enter BIOS/UEFI settings (usually by pressing F2, Del, or Esc during boot)
2. Navigate to the Security or Boot section
3. Find the Secure Boot option and disable it
4. Save changes and exit

Read: How to Troubleshoot and Optimize Ubuntu Startup: Manage Systemd Services for Faster Boot Time

Automated Script Solution

For those who prefer an automated approach, or if you need to perform this process frequently (after kernel updates), you can use a helpful script:

cd /tmp

wget https://raw.githubusercontent.com/rune1979/ubuntu-vmmon-vmware-bash/master/wm_autoupdate_key.sh

chmod +x wm_autoupdate_key.sh

./wm_autoupdate_key.sh

This script automates the key creation, signing, and registration process. After running it, you’ll still need to reboot and enroll the key as described in step 5.

Common Issues and Troubleshooting

“Failed to enroll MOK” Error

If you encounter a “Failed to enroll MOK” error, it’s often because:

1. The password you entered during enrollment doesn’t match the one you created
2. The MOK management screen timed out

Solution: Rerun the mokutil –import command with a simpler password (5-8 characters, without special characters) and try again.

Error After Kernel Updates

The VMware module signing process needs to be repeated after kernel updates. If you suddenly encounter the error again after an update, simply follow the steps above again.

Read: Master Linux Kernel Administration: The Ultimate Guide to Recompiling, Tuning, and Managing Kernel Modules

No MOK Management Screen During Boot

If you don’t see the MOK management screen during boot, your system might be:

1. Using a different bootloader configuration
2. Booting directly from GRUB without shim

Solution: Ensure your system is configured to boot using shimx64.efi rather than directly from grubx64.efi. This might require adjusting your boot settings.

Why This Solution Works

This solution works because it addresses the core issue: the need for signed kernel modules when Secure Boot is enabled. By creating our own key, signing the modules, and enrolling the key in the MOK store, we’re essentially telling the system, “These modules are trustworthy and can be loaded during boot.”

The beauty of this approach is that it maintains the security benefits of Secure Boot while allowing VMware to function properly. It’s a much better solution than disabling Secure Boot entirely.

Frequently Asked Questions

Do I need to repeat this process after every Ubuntu update?

You only need to repeat this process after kernel updates, not after every Ubuntu update. If you notice the error returning after an update, it’s likely because the kernel was updated.

Will this solution work for VMware Player as well?

Yes, this solution works for both VMware Workstation and VMware Player, as they use the same kernel modules.

Can I use this method on other Linux distributions?

This method works on any Linux distribution that uses Secure Boot and requires module signing. However, the exact paths and commands might vary slightly.

What if I don’t want to use Secure Boot?

If you don’t need Secure Boot, disabling it in your BIOS/UEFI settings is the simplest solution. However, this reduces your system’s security.

Why doesn’t VMware sign their modules properly?

VMware does provide signed modules for some distributions, but keeping up with all Linux kernel versions and distributions is challenging. This solution bridges that gap.

Conclusion

The “Could not open /dev/vmmon” error in VMware on Ubuntu is a common frustration, but with this guide, you now have a robust solution. By understanding the underlying cause and following these systematic steps, you can resolve the issue and get back to using your virtual machines.

Remember that kernel updates might require repeating this process, so bookmark this guide for future reference. If you found this helpful, consider sharing it with other VMware users in the Ubuntu community

The post How to Fix VMware’s “Could not open /dev/vmmon” Error on Ubuntu appeared first on net2.