Chrome may not be able to keep itself updated

Contributor II

I have a similar issue to this yet decided to create a new post to hopefully get some assistance.
I'm new to provisioning Chrome and don't know the components. Keystone?
Basically I created a Composer snapshot on a machine that never had Chrome. I then packaged it with only the Google related settings/folders and I get the error Chrome may not be able to keep itself updated. When I try to manually change the setting on client testing machine after install, I get update errors.
I need help to get the Chrome may not be able to keep itself updated banner removed and allow Chrome to auto update for all users, and then provision latest Chrome to all JAMF clients with or without Chrome. I'm hoping to just change a setting file and push that file with the Chrome app.
Any help is greatly appreciated.


New Contributor III

Not sure if this will help but here goes. In Composer add a postinstall script to your .pkg with the following:

--------- BEGIN ---------




currentUser=ls -l /dev/console | awk '{ print $3 }'
chown -R $currentUser "/Applications/Google"

exit 0 ## Success
exit 1 ## Failure
--------- END ---------

Then package and redeploy. Let me know if it worked.

Contributor III

I use This and it works really well.

Contributor II

Thanks for the replies.
@AmigoDeluxe the problem is my package is flawed, so I'll likely ditch it for now. I may try your solution yet after some testing I'm looking more for best practices in packaging Chrome.
I tested with @Asnyder 's suggestion and it works great yet users without Chrome get all the first run crap which I would like to avoid if possible. I don't want our users to switch browsers, etc.
So if anyone has a process for new and existing Chrome installs that works for them it would be really helpful for me to see them.
Thanks again.

New Contributor

I've tried both using Patch Management and the script posted by Asnyder above. Both ways get me the same banner 'Chrome may not be able to keep itself updated'. Are you all experiencing this or is there a workaround to prevent that banner?

Contributor II

I second that @Asnyder .. It works well for us as well. @llitz123 take a look at that workflow. We are looking for something for firefox currently.


I believe it's just a permissions thing. When you deploy Chrome with Jamf it's owned by root, so the user doesn't have permissions to modify the app bundle.

Contributor II

I havent tested in a while.
I had the same assumption as @isaacnelson - that its a permissions thing. I decided it was ok to work with any users who had issues directly, yet after the initial banner, Lewis Lebentz's process (posted by @Asnyder above) has worked flawlessly to keep Chrome up to date.

New Contributor

Google has created better support documents for "enterprise" clients recently. You shouldn't need to do a capture on the dmg in the enterprise downloads but you will need/consider using a managed preference for deploying your settings. Auto Update is enabled by default.

New Contributor II

I've created configuration profile successfully as outlined in and have it successfully deploying extensions however the policy to enable auto-updates does nothing for the "Chrome may not be able to keep itself updated" message. What blows my mind is that an old package we have of v54 works just fine. I've gone as far replicating folder/file rights of the entire package to the latest version- that got rid of the pesky message but Chrome was not checking for updates (configuration policy also had no effect). I'm at a complete loss here...I'd like to use, I've got it successfully installing but can't get around that darn update error.

New Contributor III

Have you tried running this script yet? In my process, I install chrome and then run this script that's in one of the comments from GitHub.

I also run this script to create the global settings plist:


# Create plist for default Chrome settings, homepage, etc...
# This script should be ran in Jamf when Chrome is deployed
/bin/cat <<EOM >/Library/Preferences/
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

Valued Contributor

I ran into a problem with Chrome, from a composer snapshot. It turned out that I was using the fill existing users and fill user templates on install. What then happened was the users accounts were populated with a plist that was attempting to access the Admin accounts Chrome updater. When I edited it all and changed the plist to use ~ rather than /Users/Administrator/ it all fixed and worked better.

I rarely use composer for snapshots now, I find it can get me into all sorts of trouble. I install Chrome via script, and then keep it updated via script. And for a lot of applications, I tend to put the installer pkg in a folder on the build Mac and then .tar.gz the folder, then the .tar.gz archive gets put in composer, and I add a post install script to it to expand the archive and then run any .pkg files it finds in there and finally clean up after its self. This method comes in particularly handy when it comes to things like Logic's samples, there are about 800 of them. You can put 40 or 50 installers in the folder, and they will all be installed one after the other - a perfect vanilla install of them on each Mac, with no extras or bits missing.

New Contributor III

@PaulHazelden Can you share an example of your install and update scripts for Chrome?

Valued Contributor

Chrome update script


volname="Google Chrome"


/bin/echo "--" >> ${logfile}
/bin/echo "`date`: Downloading latest version." >> ${logfile}
/usr/bin/curl -s -o /tmp/${dmgfile} ${url}
/bin/echo "`date`: Mounting installer disk image." >> ${logfile}
/usr/bin/hdiutil attach /tmp/${dmgfile} -nobrowse -quiet
/bin/echo "`date`: Installing..." >> ${logfile}
ditto -rsrc "/Volumes/${volname}/Google" "/Applications/Google"
/bin/sleep 10
/bin/echo "`date`: Unmounting installer disk image." >> ${logfile}
/usr/bin/hdiutil detach $(/bin/df | /usr/bin/grep "${volname}" | awk '{print $1}') -quiet
/bin/sleep 10
/bin/echo "`date`: Deleting disk image." >> ${logfile}
/bin/rm /tmp/"${dmgfile}"

exit 0

Can' see my installer one, I think it is buried in the middle of another script. It is similar to the one above, it gets the installer, opens the dmg and copies the file to Applications and sets permissions. There are a few versions out there, they work for most apps that are basically a dmg containing an application that needs to copy to the Applications folder.

Contributor III

We have a Chrome install script too...


# Get current stable build version number of Chrome from the web, do this in a single line to keep it encapsulated
chrome_latest_stable="$(curl | grep "mac,stable" | sed "s/,/ /g" | awk '{print $3}')"

# Get version number on currently installed Chrome app
installed_version="$(/Applications/Google Chrome --version   | grep -iE "[0-9.]{10,20}" | tr -d " <>-:;/,&"=#[a-z][A-Z]")"


install_Chrome() {
  # Create a temporary directory in which to mount the .dmg
  tmp_mount=`/usr/bin/mktemp -d /tmp/chrome.XXXX`

  # Attach the install DMG directly from Google's servers (ensuring HTTPS)
  hdiutil attach "$( eval echo "${DOWNLOAD_URL}" )" -nobrowse -quiet -mountpoint "${tmp_mount}"

  rm -fR "/Applications/Google"

  ditto "${tmp_mount}/Google" "/Applications/Google"

  # Let things settle down
  sleep 1

  # Detach the dmg and remove the temporary mountpoint
  hdiutil detach "${tmp_mount}" && /bin/rm -rf "${tmp_mount}"

  if [ -e "/Applications/Google" ]; then
    echo "******Latest version of Chrome is installed on target Mac.******"

check_Running ()
# To find if the app is running, use:
ps -A | grep "Google" | grep -v "grep" > /tmp/RunningApps.txt

if grep -q "Google" /tmp/RunningApps.txt;
    echo "******Application is currently running on target Mac. Installation of Chrome cannot proceed.******"
    exit 1;
    echo "******Application is not running on target Mac. Proceeding...******"
    exit 0

# If the version installed differs at all from the available version
# then we want to update
case "${installed_version}" in
    echo "****** Chrome version checked OK (${latest_stable}) ******"
    echo "****** Chrome version differs - installed: ${installed_version}, available: ${latest_stable} ******"

exit 0;

Valued Contributor

@dsavageED Yours looks a bit nicer than my script, you check for it running first before updating. I normally only allow my script to run first thing in the morning, before everyone gets in. I have the Macs all boot early in the morning to allow me time to run some maintenance tasks when there are no users around to upset.

New Contributor II

The problem has to do with GoogleSoftrwareUpdate. In newer versions of Google Chrome, GoogleSoftwareUpdate is not downloaded until Chrome has been launched once. On first launch, Chrome will install GoogleSoftwareUpdate in the current user's Library. This causes the prompt if the app is not owned by that user. Changing ownership of Google Chrome to the user will only fix the problem for that user. If anyone else logs in, the prompt will appear again.
When you click "Set up automatic updates" from that prompt. The system will move GoogleSoftwareUpdate to the /Library/Google folder and remove it from the current user's Library, it will also update and create all relevant LaunchAgents and Daemons to point to GoogleSoftwareUpdate in /Library/Google.
The only way to have that all automatically happen is to use a Composer SnapShot to capture Google Chrome, the Launch Agents, Daemons, and GoogleSoftwareUpdate in /Library (you run Compsoer from when you install Chrome until after automatic updates are setup for all users.)
The exact step by step method from Google is here
After running Composer you will need to remove some of the stuff that Composer captures and limit it to the files in the picture below. 897f04c9e94347ef93c2bf4616e07045

This installation will fix the problem on both new installs and updates to previous installations.
Optimally you would want to remove GoogleSoftwareUpdate and the LaunchAgent on previous installs that still have them in the user's Library but in my testing that is not required.
You will have to go through this process EVERY TIME you create a new Google Chrome because GoogleChromeUpdate is also periodically updated.
This is REALLY annoying and hopefully Google will fix this in a future version. It should be smart enough to know if the app is owned by root it should automaticaly put Googel SoftwareUpdate in /Library/Google on first run and not the user's Library.
I have tested all versions of disabling software update with a configuration profile( both and and no luck as of yet.


I also advise to use the curl scripts that are posted above. We have one similar and we started doing this over making packages using composer for two big reasons.

  1. Google Chrome (and Firefox and most freeware) is updated regularly. It saves time for making packages that can have permissions issues.
  2. You can custom configure it along with a redeploy options by doing something such as removing the ~/Library/Applications Support/Google/Chrome folder (or whichever part you need) using a policy.

Contributor III

I posted this in conjunction with another user asking about Google Chrome updates, but if you intend to make use of Google's auto-updating, execute Hannes Juutilainen's script as a post-install task after installing Chrome. That script will do all the work needed to enable the auto-updater to operate properly.

New Contributor II

I agree that using Composer is usually not the best option but in this scenario for first installation or to repair machines still having the prompt it is the only option to resolve the issue. I used autopkg, which performs a curl to create its packages but the problem is not at installation but after first run. Chrome changed the way it deploys GoogleSoftwareUpdate. It is actively downloaded from the web on first run and putting it in the user's Library which is the cause of the issue. Completely deleting GoogleSoftwareUpdate will remove the ability of the app to ever update on its own, which does not seem to be what he is asking to solve. I will be testing subsequent upgrades from autopkg after GoogleSoftwareUpdate has been moved to to /Library/Google see if you no longer have to use Compoer to package Google Chrome.
I also do not like performing a curl through a script run from a policy . Jamf runs all scripts as root, so the curl is run as root. If someone hijacks the webpage it can become a security risk. autopkg has some built-in checks and additional verification can be added to make sure the packages it builds are safe. The package building takes a matter of seconds and can be verified in a secure environment before deployment.

New Contributor II

I responded before seeing the python script was posted. It works GREAT. It is a very ingenious method of correcting Google's issue with installation of GoogleSoftwareUpdate. This also gives me a script I can deploy to machines I have it already installed Chrome on.Thanks!