So we currently deploy the Google Drive File Stream client to our workstations. According to the October changelog the application "supports Big Sur," but in testing our previous policies to preapprove the kernel extension for the app obviously no longer works. The app prompts to install a system extension which must be done by an admin user and then prompts for a reboot as expected with the new behavior but when you log back in and run "systemextensionsctrl list" it still says no system extensions found so we can't get the proper app/team IDs to pre-approve with a JAMF payload.
Anyone else run into this, or just happen to have the proper IDs? Are they the same as the old kernel extension?
This is actually happening to us as well, there is some glitch causing this and there is still no KEXT-less version in sight. So GDFS will not work with any M1 macs. The last I heard recently that a fix would not be seen until end of Q2.
My guess is that this issue would get addressed with that release of the KEXT-less GDFS
Google Drive Help ... Installed MacOS Big Sur beta, Backup and Sync crashes after login. . If the extension is not enabled, obviously it doesn't start at all. Added by suggestion that also Drive File Stream doesn't work either. Meantime, I've transferred my drive to another system and am using that for aces etm
@JustDeWon Yeah, that's what we're trying to do. Unfortunately when I install the GDFS app to try to pull the proper system extension IDs instead of what we used for the kext it reports that there arent any system extensions installed on the system at all so I can't get the proper IDs to put in the policy.
To clarify these are intel devices running Big Sur, we haven't deployed any M1 macs yet.
There appears to be a lot of misleading comments in this thread. Here's where I'm at with my testing...
Curious what others are seeing as the test. Either way, support is limited right now. Please consider upvoting my feature request for Jamf to add RebuildKernelCache to the MDM restart command. That's the only way to install kernel extensions currently without user interaction.
@nstrauss That's unfortunately not the behavior we're seeing. Even when installing the app on an intel macbook with Big Sur without JAMF, users are being prompted to approve a system extension for GDFS, not a kernel extension (unless the apple dialogue box is a liar which is very possible). But after approval no system extension is actually registered with the system (but the app works). Our existing Kernel Extension config profile as well as the System Extension policy we're testing for GDFS have "allow users to approve kernel extensions" enabled but in both cases it does not work on Big Sur, an admin still must manually provide credentials to approve installation.
I've reached out to our Google support rep to see if there's something more to it than the vague "supports Big Sur" in the GDFS changelog from October's version update, they probably have better avenues for support than anything we'd get as the customer but odds are it just doesn't actually support System Extensions yet like a lot of other apps we're encountering during testing.
@quip_MDavison Yes, the dialog box lies. Apple refers to kernel extensions as system extensions in approval dialog. GDFS contains no system extension. The system is prompting to allow the kernel extension. Yes, this is confusing. No, Apple has not been receptive to that feedback.
Make sure the box for "Allow standard users to approve legacy kernel extensions (macOS 11 or later)" is checked. That feature is only available in Jamf Pro 10.26 I believe and is different than only "Allow users to approve kernel extensions." Also keep in mind that profile must be installed after a Mac is on Big Sur. It can't be preinstalled on Catalina for instance.
Standard users can then allow/approve the kernel extension themselves and restart when prompted. Be sure they restart through prompt in System Preferences > Security & Privacy and not Apple > Restart... as my experience has been the kernel cache is not updated that way.
What a mess. Finally heard back from Google on this and the official response is that they're working on a version of Drive File Stream that either uses a System Extension or utilizes the new file system API in a way that it doesn't need any type of extension, but don't expect it before the end of 2021. They wanted more info on how/why MDM controls couldn't manage the legacy kext in the meantime, so anyone having similar problems may want to reach out and hopefully this puts a little more fire under their engineering team to not wait a whole year for an update.
Allowing standard users to approve extensions isn't really something we're looking to let them do, and a kludgy "restart the right way or it wont work" situation isn't ideal either as we're already dealing with that when enabling Filevault on enrollment (which still isn't fixed in Big Sur). Guess it's just gonna be a long year of Teamviewer sessions and manually pre-installing affected apps when deploying new workstations.
This has been on the DFS deployment page for a little while:
Update on November 25, 2020: Drive File Stream does not yet support Apple M1 devices.
The team identifier to my knowledge is EQHXZ8M8AV
Our newer devices are going to have this issue, but for right now we are staying far away from Big Sur.
Google Drive File Stream release notes updated today: https://support.google.com/a/answer/7577057
Upcoming - April 2021 - Apple M1 Support Windows and macOS: Version 47.0 Google Drive for desktop version 47.0 will support Apple M1 devices Additional bug fixes and performance improvements.
You cannot completely pre-approve a KEXT on Big Sur as you could on Catalina and older versions. You can only approve it so that the user can then themselves approve it (and then reboot to rebuild the kernel cache). The KEXT pre-approve Config Profile does do something, it just does not provide the same function like it did in Catalina.
This is just my observation, but I think the issue with GDFS or GDfD or whatever the hell Google names it now is an issue with the dfsfuse version (a fork of the osxfuse project). In Google Drive for desktop 18.104.22.168 dfsfuse version is 3.7.8 I believe, which as per the osxfuse release logs does not support Big Sur or even M1 macs. However, osxfuse is update to 4.0.5 which supports both Big Sur and M1 macs, but with a caveat,
The license has changed. Starting with the 4.0.0 release, redistributions bundled with commercial software are not allowed without specific prior written permission. This includes the automated download or installation in the context of commercial software. Please contact Benjamin Fleischer.
source: osxfuse GitHub
So I am guessing that there is some legal stuff needing to be worked out, and Benjamin Fleischer is probably (rightfully) looking to get PAAaaaiiiiID, being that osxfuse has picked up a lot of steam lately with all the file streaming apps on the market now.
Box Drive suffers from the exact same issue.
So until both the above update their osxfuse to 4.0 or later, we still need to suffer.
Hope this helps shed some light on the issue.
Throwing an update here to anyone who finds it since we just got an update from Google engineering- There's currently a beta version of Google Drive (formerly Google Drive File Stream) that supposedly addresses some of the Big Sur permissions issues, but still requires a lot of kludgy workarounds and privilege escalation. They're still trying to find a way to re-engineer the entire product to not need a kext at all. It's gonna be a while for a true solution.
Oddly enough I have Google Drive Working in Big Sur with M1, however this does not seem to take for intel Macs on Big Sur, so Odd.
Screenshots below, we also had a separate package that installs the root cert for our org, and a defaults write script to point it to the cert if that helps anyone.
Going to keep working on this for the Intel machines, all works except the bit where only on intel it states "System Extension Blocked" and prompts to "Open Security & Privacy Settings" to approve.
Again, seriously perplexed at why this does not happen on the M1 machines!
Any luck at getting Google Drive for Desktop to install on Intel machines without the ""System Extension Blocked" and "Open Security & Privacy Settings" to approve" window?
I have added the appropriate lines to the System Extensions profile as outlined in this thread and have Google Drive installing without user prompt on M1 machines. I just can't get around the admin user prompt on Intel Machines (running Big Sur).
Negative, we're deploying the latest version of Google Drive (50.0.something) and on Intel machines running Big Sur it ignores the above and requires you to manually approve. Whatever they did for the M1s it doesn't seem to require this at all anymore and "just works", its just our Intel machines.
Guess we just have to hope Google backports whatever they did for the M1s to the Intel version of the app sometime before we end up replacing them all lol. Their engineers were totally dumbfounded when I originally reported this issue when Big Sur launched so I'm not holding my breath.
If you're getting a prompt, it's probably a Kernel Extension and not a System Extension (assuming you properly configured the System Extension Config Profile).
If Google Drive is actually using a KEXT on Big Sir, you cannot completely pre-approve the KEXT on Big Sur as you could on Catalina and older versions. This is an APPLE limitation. You can only approve it so that the user can then themselves approve it (and then reboot to rebuild the kernel cache). The KEXT pre-approve Config Profile does do something, it just does not provide the same function like it did in Catalina and older OS versions.
I assume then, that the ARM version does not utilize a KEXT, if you are not seeing the same behavior. (Or the KEXT isn't complied for ARM and thus it's not supported period, no matter what -- I haven't tested this behavior to see if it prompts anything or not.)
I got it to work - mostly! I was able to get Google Drive to install on Intel machines with some interaction from a standard user. One of my main issues was that Google Drive requires a Kernel extension on Intel machines. Admin approval through System Preferences is needed for this. However, our users are only standard (non-admin) users. I was able, through a profile, to allow non-admin users to approve kernel extensions.
The key is the AllowNonAdminUserApprovals key in the Kernel Extension profile. While Jamf Pro exposes this setting as a checkbox titled, "Allow standard users to approve legacy kernel extensions", Jamf School does not have this setting. I did put a ticket in requesting that this setting be added. In the meantime, I created my own custom profile using the free tool iMazing Profile Editor and it worked!
Users still have to go to System Preferences to approve the kernel extension, but at least now they are able to do so without being an admin user.
Yes, they are all on Big Sur.
So what's a bit messy is that Google Drive seems to have both kexts and system extensions and it uses either depending on the architecture. So our config for G Drive on Intel and Big Sur has got a PPPC, Kernel and system extension. The M1 config only has the system extension approved.
actually my Google drive for desktop system ext config profile doesn't work. The installation of google drive for desktop went fine, i did not see any popups, but when google drive for desktop gets accessed by the user that's when the popups starting appearing. That's when i realized the system extension profile doesn't work.
@tjhall why do you have Approved Kernel Extension section in your config profile? doesn't Big Sur not use them?