High Sierra - Beta 4 - Parallels Does not Function

Installed Beta 4 this afternoon on a test machine. Parallels is not functioning.


Error message comes up stating:


To run virtual machines, please allow the Parallels components to load on your MAC.


Open the MacOS System Preferences, Security & Privacy, General and click Allow next to eh phrase about "Parallels, Inc.". Then restart Parallels desktop from the /Application folder.


What happens next?


No message appears in the General Tab to click. Closing and opening the application does not help. There is not update avialable to Parallels to fix.


Anyone else having this issue?

Replies

Same problem. Also, with a program named chirp. There is no option to allow.

I have the same problems. Says the components aren't allowed, but the Allow button is not there.


Does anyone know of a way to manually allow components via terminal?

I spoke to Apple support, it is a known issue/bug.

Same issue.


I've disabled Gatekeeper via Terminal - Same issue

I've manually added Gatekeeper rules to allow "Parallels Desktop.app" - Same issue

Fixed permissions on disk - Same issue

Paralles Support - useless

Everything worked fine in Beta 3


If Apple has it as a know issues is there a "known" work around?


Thanks

disable SIP for temporary work around. Obviously disabling SIP is not recommended

How do I disable SIP?

Start the machine using CMD R


When in the Recovery Mode go to Terminal


type csrutil disable


It does allow Paralles 12 to run. Not the best of all ideas, but it will work.

Parallels Desktop 11 - ok

A note of thanks for the post.

It worked for me, until there is the better fix.


Dennis

I would advice all developers to read the Apple TN2459 concerning KEXT Consent.

https://developer.apple.com/library/content/technotes/tn2459/_index.html#//apple_ref/doc/uid/DTS40017658


This will impact your work and your users, even if your app does not use KEXTs.


You can add to the trusted developer team list for KEXT-CONSENT by booting to Recovery and using spctl as described in the note. If the KEXT you are trying to load is not yours, you need to ascertain the TEAM ID of the kext by using codesign. It is not clear in the note, but the team ID is not the company string as reported in the dialog, but the HEX key in the certificate and also used for siging in Xcode.


I prefer to run with SIP enabled, but I think that the current apporach will have the effect that a lot do support people will advice their users to turn off sip, which is arguably and easier command then trying to have them type in a complex string like "spctl kext-consent allow XYZABCD3FT."


I have been working on this issue for several days to understand all the implications. We have a non-technical user base and require a KEXT, the impact will be horrific.


No more ease-of-use and plug-n-play on macOS... It is now a sad state that our app will be easier on Windows 10!

Many thanks akolbes... Your work around


When in the Recovery Mode go to Terminal

type csrutil disable


for Parallels 12 - WORKED - for me. Thanks a ton again..

HStriepe, thanks for the info. I would like to try to use the spctl kext command instead of disabling SIP. However, I am not sure what to put after "allow" since there is no "system extension blocked" message as the article states. Does anyone know what to allow for for parallels to work using this command: spctl kext-consent allow ******* ?

You need to find one of the Parallels KEXTS and then run:

codesign -dvvv <path-to-kext>

In the resultant listing you will see somthing like this (VMWare is my example)

Authority=Developer ID Application: VMware, Inc. (Fusion) (8J7TAMPT4P)


The last string in parens is the TEAM ID. For VMware, you would use the following in the Recovery shell

spctl kext-consent add 8J7TAMPT4P


Also do a

spctl kext-consent list

to make sure it took.


BTW, hopefully they signed all their KEXTs with the same TEAM ID.

Thanks, HStriepe. I was able to find the TeamID and follow the procedure. I was also able to confirm it was added using spctl kext-consent list. But unfortunately, the error is still there. I checked a few items and they all have the same Team ID. Maybe something remains unsigned somewhere? I am not sure, but I don't know what else to do since I do not want to disable SIP. I guess I will just wait until Parallels or Apple come up with a solution.

I finally found an easy solution. Someone in the Parallels forum suggested rolling back to 12.2.0. It worked like a charm.


Update: After installing High Sierra Beta 5, I upgraded to Parallels 12.2.1 (keeping my 12.2.0 dmg handy just in case) and it is working fine with the new beta.