Trouble with pkg running post-install script

New Contributor

I'm not sure where the best place to post this question is, so any help or guidance would be appreciated.

My problem is simple. I want to set the user dock on a lab of iMacs. I already have dockutil 2.0 installed on all the machines. So I'm thinking a simple two step process, first ...write a script for dockutil to customize the dock, and second ... build a payload free package to deploy and run the script.

This is my test script.


#Set Dock Applications
/usr/local/bin/dockutil --remove all --allhomes --no-restart
/usr/local/bin/dockutil --add "/Applications/" --allhomes --no-restart
/usr/local/bin/dockutil --add "/Applications/" --allhomes --no-restart
/usr/local/bin/dockutil --add "/Applications/" --allhomes --no-restart
/usr/local/bin/dockutil --add "/Applications/Google" --allhomes

exit 0

When I run the script manually everything looks great. So on too step two.

I'm using Packages to build a payload free pkg, that runs my script as the postinstall script. The package gets built without any errors and when I run the pkg, the installer finishes with a "Installation was completed successfully", but my dock doesn't change.

Thinking maybe it was something with Packages. I also built a payload free pkg with pkgbuild, following Der Flounder's instructions:

sudo pkgbuild --identifier --nopayload --scripts /pathtoscriptsfolder /pathtodestination.pkg

But I get the same result. The pkg runs with a successful installation, but nothing changes. I have to assume it's something with my packages since I can run shell script without any issues. I've spent a lot of time trying to troubleshoot and rebuild the pkg but I'm stumped.

Any Ideas?


Valued Contributor III

Problem you've got is that Casper does all it's work as the root user so you're effectively setting the dock for that user. Dockutil has some extra switches to affect all users I think. I'd give that a try.

New Contributor

The more I play around with this, the more I think the issue is related to something with dockutil running inside a post install script. Just to troubleshoot the issue, I threw a couple commands at the start and end of my script to see if they would run.

- make folder "testing" on desktop
- run dockutil commands
- delete folder "testing"

The folder gets, created, then deleted, and the dock never changes, and there's no errors in the logs because the package installed successfully. I'm going to post on kcrawfords github page as well, just on the off chance he has an idea.

Is anyone else using dockutil inside a payload free package?

Contributor III

@scottnl - Did you try it as a post flight script instead of post install? I have found they work much better.

New Contributor

I posted on dockutil's github and Kyle was kind enough to responded. He suggested I use an older version, and sure enough v1.1.4 worked the first time around.

Legendary Contributor III

If I'm not mistaken I believe he removed the kill cfprefsd function in the newer release because he felt it wasn't necessary anymore, but in my experience, Mavericks hangs on to cached preferences like its virtual life depended on it, so killing Core Foundation Prefs Daemon is still required it seems. Otherwise the new settings just don't get read in. The 1.1.4 release still included the function built in that restarted the prefsd to get the new Dock settings read in, which is likely why its working with the older version, and probably also why he recommended it.

If you wanted to use the new version, you should be able to simply add a few lines at the very end like-

killall cfprefsd
killall Dock

THat should get the new settings read and then restart the Dock so the icons gets displayed. That's just a guess since I haven't actually done that yet to verify it.