Unapproved Caller on software update policy

[jwolf]

Running 9.52 I have a policy to update macs via our SUS server. The policy is set as a "On recurring check-in" with a 1 week interval.

If there is an update that requires a restart, the users get the dialog asking them to log out. When they do, many (most so far) get a dialog "Unapproved Caller - SecurityAgent may only be invoked by Apple Software." If you click on the dialog, it spins for a second, and then comes right back.

I can usually resolve it by SSH into the machine and doing a: sudo rm -Rf /var/folders/*

There are hundreds of posts that suggest using variations of the above to fix the unapproved caller error, but I have yet to find one that explains why it happens.

Sometimes it may require emptying that folder a few times, or restarting and trying again before it finally succeeds with the updates. I am also not convinced that the same thing won't happen the next time an update is installed that requires a restart.

Why is this happening? Is there a permanent fix that I can deploy to our machines that haven't been added to the policy yet? I only have test machines in the policy because I don't trust this to not leave someone stranded after hours.

This is highly frustrating as it should be the most bulletproof task that Casper can do.

Other trivia:
If the policy installs an update that doesn't require a restart, I have found that Apple Software Update is broken until after a restart. Opening the AppStore and clicking on the Update tab gives an error.
Is there an easy way to trigger the installation of an Apple software update that needs a restart to continue testing a machine that is fully patched?

[joecurrin]

The only reasoning we can find behind it, is due to an update that should have restarted the computer. Whenever we see the issue we just instruct the user to restart and the issue is resolved.

[JPDyson]

I don't know that I ever got a good answer to this question when I ran into it. FWIW, Apple includes a launch daemon that's supposed to clear this cache periodically anyway (/System/Library/LaunchDaemons/com.apple.bd.dirhelper.plist).

[bentoms]

@joecurrin, same here.

We generally cache updates 1st, then install @ logout & restart.. so don't see it in prod.. but have seen it when installing OS updates on dev boxes & not immediately restarting.

[jwolf]

@joecurrin

In our case, that would require that the user forcibly shut down the machine. (It has already logged out, and there is no option to shutdown/restart)

[joecurrin]

@jwolf Under restart options do you have "restart if a package or update requires it" for both no user logged in and user logged in?

[Sandy]

Hi,
I have seen this error: Unapproved Caller - SecurityAgent may only be invoked by Apple Software
usually after an update in place from 10.7.x to 10.9.x. from the app store

In previous instances of this error I had come across the advice to clear out the /private/var/folders/*
which had worked.

I am seeing it again now on some computers where I am trying to update them to 10.9.5.
I am caching the combo updater, and then I have a standing "install cached packages" running policy at startup.

When watching a machine's logs where this error came up but I was able to boot:
It appears that the installer that was downloaded to the JAMF/waiting room copies files to /private/var/folders/ as part of the installation process....and if not allowed enough time to complete before someone reboots, the whole process starts again at next restart... and maybe that error is coming up because the computer is in the middle of the install? the "About this Mac" shows 10.9.5, but the installer was not finished yet.
I also noticed that it never forced a restart using this method (cache and then install cached) despite the combo update requiring a reboot form Apple, and also reboot box checked on the package in JSS...

The error went away when the installer truly finished and I have removed the policy that dumps the whole folder

We still have a startup policy on student carts (10.9.x, w/ network accounts) to run find /var/folders -name "*.iscachebmp" -type f -exec rm -v "{}" ;
and a script that runs weekly to remove student home folders....stupid 64 GB HDs

more here:
http://blog.magnusviri.com/what-is-var-folders.html

[Sandy]

/System/Library/LaunchDaemons/com.apple.bsd.dirhelper.plist
oh, I see it now

[jwolf]

@joecurrin Yes, I do have "Restart if package requires it" for both no user and logged in user.

@Sandy Many of my machines were also in-place upgrades from 10.7 or 10.8 to 10.9.5. I'll check out the link you posted.

[RobertHammen]

You'll get that error message if an Apple Software Update requiring a restart runs while the system is in use.

If workable in your environment, run these type of policies at logout. Should install and restart without this dialog appearing on the display, at least in my experience. Don't believe I have configured Restart options to "Restart Immediately"...

[Sandy]

Thanks Robert, that makes perfect sense.

In our environment it is very difficult to run anything at logout, student laptops in carts by the hundreds....we do what we can :)

[RobertHammen]

Yeah, I completely understand. Can you try installing at login, with Restart Immediately as part of the policy? Might be inconvenient, but so would be forcing Restart Immediately after running the policy at Recurring Check-in.

[Sandy]

Currently I am caching the 10.9.5 combo, then running install Cached packages at startup.
The Install Cached packages is set to "Restart if the package requires it" and is a standing policy
For the most part and in testing it works as expected.
There are always some that get closed or rebooted at the perfectly wrong moment.
These babies have 64 gb HDs and so that is a constant challenge, complicated by the use of /var/folders/ as the tmp location during os installation.

[May]

Just been testing the same issue, one thing i've noticed is that if you don't log out before the reboot then error "Unapproved Caller on software update policy" does not appear

[Look]

In general for us at least it seems to occur if the machine has been up for a very long time and someone tries to update without restarting first.
You could try checking for available updates first and the restarting before applying.
In general for classroom machines though, I just force a restart every 30 days in the middle of the night, seems to have reduced the incidents significantly in those areas, staff machines are still an occasional issue though.