I have managed to get Fusion to stop working. how to cure?

[licensedtoquill]

I had been running out of space on my 2016 MBP running Mojave. Formerly Fusion was stable as a horse.

To save space, I switched my working 74GB XP VM for a (known to be working) 27GB Windows 7 or 8 VM.

Now no VM works.  Everything, including a Linux Tessa which was working now no longer works. Now XP and Windows 8.1 which were working both from an internal drive and from an external one no longer works from either drive. Not even Windows 98 works from the original VMWare directory in DOCUMENTS where it always worked from before!! 

Everything now gives the infernal "Could not open /dev/vmmon: No such file or directory" 

Does anyone have any idea what I can do to undo the problem I MYSELF HAVE CAUSED? It is nothing to do with security settings nor MacOS updates nor version nor, obviously, there being any problem with finding VMMON. 

How do I stop my Fusion from lying to me please?

[Technogeezer]

What did you do to "switch out" that VM? Have you rebooted?

What version of Fusion were you running? (should be one of the Fusion 11 releases as that's the only version that supports Mojave).

Did any other macOS update get installed on this system recently?

I wonder if a complete manual uninstall of Fusion given the information from https://kb.vmware.com/s/article/1017838 might help and reinstall might help. This won't touch your virtual machines, but make sure you have a backup copy of both your virtual machine(s) and have your Fusion license key handy before starting. Just in case something goes terribly wonky.

[licensedtoquill]

Thanks for that. It was working fine before I deleted the VMs and copied backup versions from an external drive. But the Tessa VM was and is still on my SSD, nothing has changed. But it no longer works, neither from the external drive not from the VM directory in my Documents folder

.(No, as I said, I Havent updated the OS or changed anything since these VMs last worked. I havent even re-booted the computer!)

[wila]

Hi,

This has nothing to do with you switching out those VM's.
The /dev/vmmon file is a kernel extension of VMware. What most likely happened is that you also ran a security update of macOS and that's what causing all this.

First thing I would try in your case is a removal of VMware Fusion and a re-install. I would probably reboot inbetween as well.

If that still doesn't work, then follow these steps:

The cure is to throw away your kernel extension staging folder & contents. It will be recreated on reboot.

This can most like be resolved by removing the /private/var/db/KernelExtensionManagement folder and reboot.

In the terminal run the following command:

sudo rm -rf /private/var/db/KernelExtensionManagement

Be careful not to add any additional spaces!

Then reboot your macOS host and start VMware again.

Either way, good luck!

--
Wil

[licensedtoquill]

Thanks for that Wil, I tried rebooting and that didnt work , so I tried uninstalling and re-installing didnt work.   I did try the terminal command both before and after the reinstall and got this error message:

rm: /private/var/db/KernelExtensionManagement/Staging: Operation not permitted

rm: /private/var/db/KernelExtensionManagement: Directory not empty

[wila]

Hi,

Ok, hmmm..

In that case, please check  VM's not working in Fusion and in particular the reply by jameslodberg

--
Wil

[licensedtoquill]

 Well I didnt understand most of that, nor what to do if the result of his various recommendations werent as he suggested they should have been.

But he does suggest running FirstAid from recovery (meaning Internet startup,  command-R?) and later it is suggested that reinstalling (from that internet startup?) might cure the problem?

Isnt there an easy way of throwing away the kernel extension staging folder & contents?

[Technogeezer]

---

 wrote:

But he does suggest running FirstAid from recovery (meaning Internet startup,  command-R?) and later it is suggested that reinstalling (from that internet startup?) might cure the problem?

Isn't there an easy way of throwing away the kernel extension staging folder & contents?

---

I agree that the thread can be hard to follow. Here’s what I get out of it. 

The commands

$ xattr -l /private/var/db/KernelExtensionManagement
com.apple.rootless: KernelExtensionManagement

And

ls -lO /private/var/db/KernelExtensionManagement/

are used to determine if the macOS folder required in the kernel extension loading process has the correct permissions. If not, the most successful advice to fix this is to boot to macOS Recovery. You should be able to boot to the on-disk macOS Recovery (Command-R) and not have to go to Internet Recovery (Option-Command-R or Shift-Option-Command-R). 

Once in macOS Recovery, use the menu to open a Terminal, and issue the command 

chflags restricted /Volumes/Macintosh\ HD/private/var/db/KernelExtensionManagement

Then reboot.

From the discussion in that thread and the posts it references, it appears that a macOS update has removed this flag from the specified folder, breaking the kernel extension loading process that Fusion and other third party products use.

Reinstallation might fix the problem, but that’s a drastic solution and might not guarantee that the problem will be fixed.

Someone else in the thread tried First Aid and it did not solve the issue. 

And no there is not a way to simply throw away the folder, especially from the running macOS. It’s not a problem of contents. It’s a problem of correct permissions.  There is no guarantee that it would be recreated or that it would be  recreated with the correct permissions.  

[licensedtoquill]

Well, thanks guys but I threw the app into the trash, deleted all of those  endless files, went into COMMAND-R,  ran firstaid, rebooted, reinstalled, and got the same 'cant find vmmon'  file, followed by 'cant initialise monitor device'.

Do you think that going back into COMMAND-R and entering

chflags restricted /Volumes/Macintosh\ HD/private/var/db/KernelExtensionManagement

 is likely to do anything now?

[Technogeezer]

None of what you did addresses the reported issue of improper permissions that macOS put on that folder. Nothing in the Fusion application install touches that folder - other than trying to load the kernel extensions, which improper permissions seems to prevent. .

I'd give booting to Recovery, opening a Terminal and issuing that command at this point.

[licensedtoquill]

Yes, well obviously you are some type of genius! Issuing that command completely cured the problem.

[Technogeezer]

Thanks go to  for suggesting this as a potential solution in the first place.  I just provided a little interpretation. 

[wila]

---

 wrote:

Thanks go to  for suggesting this as a potential solution in the first place.  I just provided a little interpretation. 

---

LOL, and I just pointed to another thread where someone else had figured it out, so it wasn't me who can take the credit either

Your interpretation is most welcome as I'm currently too busy on following up like you did.
In the end what counts is that the issue is resolved as that's why we're even talking about all this.

Next time this comes up I will point to this thread instead as it looks like the "just delete that folder" step no longer works.

--
Wil

[Cidenet]

This bit of troubleshooting resolved my issue, Although I had to do it a bit differently than discussed here. I disabled CSRUTIL and then removed the folder and allowed it to be recreated by the OS upon reboot, it was correct and VMWARE Fusion 11 (With latest Updates.) ran and launched correctly, however performance is terrible and the guest os's basically are unusable. So this solution is only part of the problem for me.