Skip to main content

Hey all,

For awhile now we have had an issue with Google Chrome in which the icon just bounces up and down a few times and does not open when a user tries to open Chrome after it installs via enrollment/check-in.  We build the policy ourselves which may be the problem, but I believe the person who builds it just scans the package and uploads it directly to Jamf...

Anyway, we came up with a solution that uses a script to give the login user access to the folder $HOME/Library/Application Support/Google/Chrome, and that seems to work.

The only problem is, this has to be run for every user that's logged in, and what's worse we can only seem to get it to run from Self Service, which I think may have something to do with it running from root rather than as the user.  We have hundreds of shared machines that are logged into by multiple users, and it's not feasible to have every user run this.  

Here is the current command we are using:

#!/bin/sh

loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name 😕 && ! /loginwindow/ { print $3 }' )
echo $loggedInUser
mkdir $HOME/Library/Application\\ Support/Google/Chrome
chown -R $loggedInUser $HOME/Library/Application\\ Support/Google/Chrome

 

Anyone have any experience with this, or has anyone seen this in their environment?

 

Thanks.

 

Are you manually building the install package or are you using the official Chrome pkg installer?

https://chromeenterprise.google/browser/download/#mac-tab 

The former can lead to the issue you're describing if the person building the installer forgot a couple permission changing steps.  The latter is the much better route to take.

Are you manually building the install package or are you using the official Chrome pkg installer?

https://chromeenterprise.google/browser/download/#mac-tab 

The former can lead to the issue you're describing if the person building the installer forgot a couple permission changing steps.  The latter is the much better route to take.


I believe we are using the Chrome pkg installer, uploading it to Jamf and pushing it out to devices.  I don't think we are making any other changes to the installer.

Since this is affecting user home directory folders I suspect the FUT (fill user template) or FEU settings in the package settings were used. Worth a look just to be sure.

 

Since this is affecting user home directory folders I suspect the FUT (fill user template) or FEU settings in the package settings were used. Worth a look just to be sure.

 


Checked this out, and this is not selected for the package.

Checked this out, and this is not selected for the package.


It could be a number of things, but I guess the first thing is to verify 100% that the Chrome installer is Google sourced and wasn't built using Composer for instance. You used the word scan in your first post so that makes me slightly suspect a DMG was downloaded and Composer was used to get it into pkg form, but I could be way off base.

There are other instances of this on JN and it appears most solved the problem by using a script in a policy. 

It could be a number of things, but I guess the first thing is to verify 100% that the Chrome installer is Google sourced and wasn't built using Composer for instance. You used the word scan in your first post so that makes me slightly suspect a DMG was downloaded and Composer was used to get it into pkg form, but I could be way off base.

There are other instances of this on JN and it appears most solved the problem by using a script in a policy. 


So I went ahead and downloaded the installer, uploaded directly to Jamf using Jamf Admin, deployed to a device with the issue after deleting Chrome and I still experienced the same issue.  

I used the word scanned because we have our packages scanned by InfoSec and scan ourselves on VirusTotal before uploading to Jamf.  

My next steps are to upload the installer directly to the cloud through a browser, to test this on a VM, exclude a device from our Chrome install and also try the same installer on an unenrolled device.  I am pretty sure this must be specific to our Jamf environment and management settings, somehow.

I solved it by using a script, but not in the policy itself.  I suppose I could try that.  Do you have a link to those threads by any chance?  I can't seem to find them.

So I went ahead and downloaded the installer, uploaded directly to Jamf using Jamf Admin, deployed to a device with the issue after deleting Chrome and I still experienced the same issue.  

I used the word scanned because we have our packages scanned by InfoSec and scan ourselves on VirusTotal before uploading to Jamf.  

My next steps are to upload the installer directly to the cloud through a browser, to test this on a VM, exclude a device from our Chrome install and also try the same installer on an unenrolled device.  I am pretty sure this must be specific to our Jamf environment and management settings, somehow.

I solved it by using a script, but not in the policy itself.  I suppose I could try that.  Do you have a link to those threads by any chance?  I can't seem to find them.


If this continues to happen in a VM or another freshly enrolled client then yeah, I'd suspect another policy or package may be the culprit. Are you just deploying the browser itself or do you have any sort of management applied to it?

Here is a more recent thread and then the next one is a bit older however the OP wasn't using a Google sourced installer, but it's a very similar problem. 

Thank you all for your help, I figured this one out.  We had a script running to skip the First Time Setup on Chrome that was deprecated, but still running on our machines.  It would create the directory and use a touch command on the First Step file and this would break things.  We just turned it off and things are working now.

Reply


Terms & ConditionsCookie settings