LaunchAgent help

Do you need a full path to dockutil? Often you don't have full environment variables when running a LaunchA. /usr/local/bin/dockutil. Type 'which dockutil' to see where it is.

Also, put a little debug line in the top of your script - like 'touch /tmp/itStarted.$$' then you can login and look in /tmp/ to see if that file exists. Then you know your script is running, but dockutil line isn't doing what you expect. if you dont' have 'itStarted' file, then you know the script isn't executing.

What about the permissions and ownership on the LaunchAgent plist? That's actually more important than permissions on the script. All launchd jobs should have an owner and group of root and wheel respectively and the POSIX permissions should be 644. That's owner read and write, group and other/world read only.

Outside of that, regarding the script, make sure it has the executable flag set on it, since you're calling the script by path only, not by putting a sh in front, not that it should need it mind you. It just needs to be executable and the correct owner/group/permissions on the LaunchAgent plist. Also, I would consider putting the full path to the dockutil utility in your script. I'm finding more and more with launchd jobs that they work better if you're explicit about paths to binaries and such.

A few things.
1: as @mm2270 said, the permissions and ownership have to be exactly right for it to work do a

ls -l /Library/LaunchAgents

and make sure it matches the rest of them.

2: I found dock modifications sometimes happen to early when called with a LaunchAgent and putting a small delay at the start might help.

3: I am not sure why but for some reason I have always done my LaunchAgents like this in the part where it calls the actual script.

    <key>ProgramArguments</key>
    <array>
        <string>/Library/Scripts/DockItems/popDock.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>

To be honest though this probably just stems from the fact I will have looked at an existing one the first time I created one and it has always worked so thats how I have continued to do it.

@Look Both <key>Program</key> and <key>ProgramArguments</key> and the associated <array> tags are valid syntax. "Program" can be used when you only have a single command to run, like the path to a script. "ProgramArguments" must be used if you syntax with multiple arguments, which each going on it's own line. For example:

<key>ProgramArguments</key>
<array>
       <string>/usr/local/bin/jamf</string>
       <string>policy</string>
</array>

I'll ask the bigger question, Is there a reason you "have to" manage the users dock? I would guess that there are security related setting that are many times more important .. like

https://www.jamf.com/jamf-nation/feature-requests/4240/cis-benchmark-control-guide

While I do understand that it's "nice" and possible that a manager asked you too, managing any setting with a third party utility is risky. Is the 3rd party utility secure, will it alway be available and what are the chances Apple updates breaks the utility?

IMO

C

@arpierson We manage our lab docks using dockutil. I have a script attached to a policy (scoped to a "Labs" smart group) that runs at login. The policy is also made available offline, so if for some reason the Mac drops its network connection, the script will still run.

Doing it this way gives me the ability to change the script to add/remove apps when necessary!

Hope this helps.