Google Chrome Auto Update

New Contributor III

Has anyone actually been able to disable auto updates in a chrome package? - I was Able to create a new mdm configuration profile and upload an edited file with a few policy settings. this worked great. I followed the instructions here:

but I am still able to update chrome. as a matter of fact, - I even went as far as changing and even deleting the GoogleSoftwareUpdate folder under user/library/google - and it just builds a new one

I know in windows, it's one reg key and you get "Updates are disabled by the administrator"

can it really be this difficult?


New Contributor III

@CasperSally you were right on target!

I actually added a script to create the folders right after the Chrome package is installed. if launched, it can't access these folders and does not update - Thanks2379cb6c15ea4a6e8bfbb43468aa8644


mkdir -p ~/Library/Google/GoogleSoftwareUpdate
chown root ~/Library/Google/GoogleSoftwareUpdate
chmod 644 ~/Library/Google/GoogleSoftwareUpdate

View solution in original post


Contributor III

@AVmcclint 's solution just worked for me:

#!/bin/sh rm -rf /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle mkdir -p /Users/$3/Library/Google/GoogleSoftwareUpdate/ touch /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle chown root /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle chmod 644 /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle

Had been having an issue where every time Chrome was opened got a popup window saying "macOS wants to update," when admin credentials entered in it just flashed Chrome or filled the desktop with Chrome images. After doing above it doesn't happen and if I go to About Chrome the autoupdate immediately fails.

New Contributor III

How we can achieve this for every newly logged in user. need a script help.


Honored Contributor

Disabling the auto update is almost imperative. Today I manually updated to Chrome 58 on my Mac and then discovered that I couldn't establish a secure connection to many of our internal servers. These servers aren't using self-signed certs, but they are issued from our internal CA. It also affects Chrome 58 on Windows machines too. This page kinda explains the problem but I dont know where the solution lies.

Meanwhile I made sure to not push the Chrome 58 update to the Macs until this is resolved. If I had autoupdate enabled, things could get really nasty.

Esteemed Contributor III

@AVmcclint pretty sure you found this already but just in case...


Honored Contributor

oh yeah. The workaround that was offered up back then really was a temporary band-aid because Google said that it would only work through version 65 (I think) after that, all certs would need to be properly built. We had to scramble to get all our server certs updated.

Esteemed Contributor III

@AVmcclint yep, the real solution is to red internal PKI certs to include SAN.


Valued Contributor II

I had trouble with Google Backup and Sync overriding even with above script in place, so I modified it to not allow write permissions on the whole software update folder. So far so good. I also disabled the launchagent runatload.


rm -rf /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle
mkdir -p /Users/$3/Library/Google/GoogleSoftwareUpdate/
touch /Users/$3/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle
chown -R root /Users/$3/Library/Google/GoogleSoftwareUpdate
chmod -R 644 /Users/$3/Library/Google/GoogleSoftwareUpdate

Edit: I removed the LaunchAgent part of the script since it was causing issues in our environment.

Contributor II

I use the Jamf Pro Restricted software option to nuke Chrome from updating and it seems to work across the board till Google renames a process. So under Restricted Software create like this;

Display Name: Google Software Update Agent
Process Name:
Restrict exact process name: checked
Delete Application: Not checked
Send email notification on violation: Not checked

Kill process: checked

Scope: All managed clients

End users will get an error when they try to update, they can still manually download a Chrome installer but never update it as long as they are managed by the JSS.

Valued Contributor II

All, looks like as of Chrome 62, keystone.plist can be managed via a profile (this had been deprecated, I think, but is now back it appears). I'm working on testing this now. Great news if it works, I'd love to get away from these scripts to stop the tool from running!

Relevant post

Google reference

Valued Contributor II

Edit: in my testing, the profile stops the ksadmin prompts but not the GoogleSoftwareUpdate prompts :(

Please let me know if anyone has a different experience? Thanks!

Edit: I posted this in the wrong thread. These prompts apply if you restrict where apps can launch from. We don't allow apps to launch out of /Users and hence the prompts. It's possible the profile works fine if you're wiling to let GoogleSoftwareUpdateAgent bundle launch.

More info (star if you'd like to see Chrome stop launching app out of /Users):