Do you have any "Restricted Applications" in your casper environment? From a high level assessment, it seems as if DMGs are mounted to launch something and are being restricted.
The commonality is all your machines are in Casper.
If not a restriction, I would look for a permissions issue with a package that is common to all the machines. There must be a package that you pushed to all machines. It is possible that this package "broke" something. If not a package look for a policy.
Good luck hunting.
@ShakataGaNai if some of the end users installed Chrome themselves it's possible they didn't copy the Chrome application off the DMG into their Applications folder. They may have also created a dock shortcut or alias to the Chrome application on the DMG that is causing the DMG to mount when they launch the application. You're probably going to need to take a look at the machines this is happening on to make sure the Chrome app is in their applications folder and there are no aliases, dock shortcuts or login items that are pointing to the Chrome app on a DMG.
@pblake you are, of course, correct in that Casper is one of the more major common factors. I do have some restricted apps but they are all full name, ex: "Boot Camp Assistant.app". I've been hunting around for permission issues but I can't find anything that would affect ALL apps. I've even checked /tmp/ and /private/tmp/
@mpermann Yea. That would make sense. I don't think that many people made said mistake but it's possible. The strangest part is that the issue comes and goes.
Sounds like you have a couple of things going on here.
With this kind of repetition you are probably looking at something like a launchd item or a casper policy, but probably the later.
For example, if you have a policy to update Chrome if it is less than x the policy will run. If the policy is set to run periodically, then if an update failed, it will try and run the update again at next trigger time as Chrome is still less than x.
If a dmg is already mounted, it won't get mounted again. This would suggest that to have multiple mounts, each mount was mounted from a different dmg (a fresh downloaded version).
It sounds like there is a policy that is set to run periodically. The policy is downloading a copy of the Google and then possible running a script to do the install, including mounting/unmounting the dmg. As the update fails, it never gets to the unmounting part.
As to the fail, if there is a script to hunt down, this may give the clues as to why the updates aren't happening, e.g. permissions errors, file location, etc.
There should be logs that you can check. You could correlate the time of the logs against the time of the mounted volume (that would need to be the /dev/disks). The jamf binary has a whole bunch of options too, e.g. policy, so you could check what's going on there too.
After hunting high and low based on some of the suggestions here, I found the issue: A configuration profile set to restrict Disk Images to Read-only
Configuration policies
This was originally set up with the best of intentions and the belief that installs from Disk Images are always a simple "drag to Applications folder". While that use case works fine, it appears that the more complex cases it does not. Some auto-update mechanisms break at random (Such as Chrome). Whereas others self-updates are totally broken (Such as Adobe). Some installers (again, Adobe and Spotify) are also broken by DMG's being forced to read-only. I suspect this is because the installers/updaters use the Disk Image as temporary working space (no proof, just a suspicion).
So. Read-only disk images are bad.... m'kay?
Thanks for the post @ShakataGaNai. We have been having this issues as well with one department, as I block their dmg access to read only to protect them from themselves. I guess I will now need to decide if opening it up is worth it. Thanks!
These read-only disk images appear to cause a lot of problems. Here's another post
where unchecking that Read-Only box can solve a lot of problems.
