Catalina: policy running on login trigger can't find script

New Contributor III

Because of the pandemic we continued with our existing Mac installations the entire time. That means they are still High Sierra. I am in the process of working out how to get Catalina to work on them.

My JAMF is currently 10.21.0, just upgraded yesterday.

We have a policy that runs a script; we use this with the login trigger to create login script functionality. On High Sierra, this still works fine. On Catalina, though, JAMF can't find the script:

Executing Policy TEST Login Script
Mounting CasperDP
Running script
Script exit code: 127
Script result: /bin/sh: /Library/Application Support/JAMF/tmp/ No such file or directory
Error running script: return code was 127.
Relaunching dock(s)...
Unmounting file server...

If I run the same script from self-service, it doesn't have this problem. I.e. it finds the script, and does not exit with 127.

If I take a totally different policy and add the login trigger, it fails in the same way.

I can't find anything about changes I have to make to support login triggers for Catalina. Anyone have any ideas?



Valued Contributor

You might have to escape out the space in "Application Support". Either put the whole path in quotes or use a backslash to tell the interpreter to ignore the next character (the space). Without seeing your TEST Login Script, it's hard to say, but I've certainly been caught by spaces in path names that lead to the script not being able to follow the path.

Except that's not my path. That's JAMF doing that. Behind the scenes, when the policy is run, JAMF is presumably copying my script into that folder. I have no control over that, and it's not happening successfully.

Ah, I see. Is it possible that the CasperDP sharepoint didn't mount? Also, does this script live on the CasperDP sharepoint? At some point, Jamf allowed moving all scripts into the SQL database. Are you doing this, or are you still storing your scripts on your sharepoint(s). I do believe that Jamf Pro copies a script to this /tmp folder so it can run it locally. So, perhaps Jamf Pro is looking to the wrong place to execute the script? There is a long discussion about a similar error here:

Tom Larkin's post toward the end of this is super helpful.

Hope this helps.


It's possible, but of course I can't tell whether it successfully mounted and copied. In order to be able to tell, I would need to be able to run a script 🙂 it certainly claims that it's mounting the distribution point.

I have not moved my scripts into the database. (I can't imagine why I would want to. As files on disk, I can work on them in an editor with syntax coloring, not in a little text box.)

But in any event, I will reiterate that this problem only happens with scripts running on the login trigger. Any other trigger I have tried is fine. It's as if there is something further I need to do for Catalina, to allow scripts to run on the login trigger, but I have not found any documentation of any such thing anywhere.

Whoops, forgot to say that I had already read through that thread, and while there are similarities, it's not the same problem. Mine works fine under any circumstances as long as it's not the login trigger. It's not unreliable or variable. ANY policy that consists of a script will have this problem on the login trigger. That same policy will NEVER have the problem on any other trigger. And it's all fine under High Sierra.

Any way you can change the trigger, even just to test to see if it's actually unique to the login trigger? Even as a test?

That's what I'm saying, I have done precisely that. I am able to run my login script from self-service with no problem; I can also run it from the command line using the JAMF binary. I took another, completely unrelated policy that had only a script and gave it a login trigger, and it failed in exactly the same way.

I *really* don't want to try importing them into the database, because my understanding is that that is all-or-nothing: i.e. I can't import just this one script without importing all of them, in a one-way operation forever. I really don't want to have to work on scripts in the JSS interface.

Any chance you don't have Login/Logout Hooks enabled on your JSS?

Or maybe they were disabled from the recent update to Jamf Pro 10.21 that you ran?

Note that this functionality is being deprecated. I would not rely on Login/Logout Hooks for a long-term solution.

Hooks are definitely enabled. I mean, we've been using this JAMF since 2013, and even now, if I log in on a High Sierra computer, the login script will work fine. (And I have been in and looked and all the hook stuff is enabled.) The difference isn't JAMF, it's Catalina.

I realize it's being deprecated, but I intend to use it to the last possible minute. We have no idea how we are going to function without it, and we have enough trouble trying to solve all the actual technical problems of Catalina without having to redesign our entire student service at the same time. As far as I know, they have deprecated it without providing any sort of replacement functionality.

So I'm hoping to deal with the move to Catalina as one problem, and then once term starts, looking at redesigning the service as a separate problem.

...I have just been and looked and discovered that I have the same exact problem with the logout trigger.

Can you tell that I'm not a natural Mac person?

Okay, this is moderately interesting. Having a look at the logs when the policy succeeds vs. failing:

Here's what the JSS shows for the script results when it FAILS, i.e. for the login trigger:
Executing Policy TEST Login Script
Mounting CasperDP
Running script
Script exit code: 127
Script result: /bin/sh: /Library/Application Support/JAMF/tmp/ No such file or directory
Error running script: return code was 127.
Relaunching dock(s)...
Unmounting file server...

...And here's what the JSS shows for the script results when it SUCCEEDS, e.g. if I run it from Self Service:
[STEP 1 of 5]
Executing Policy TEST Login Script
[STEP 2 of 5]
Mounting CasperDP
Running script
Script exit code: 0
Script result:
15:30:50: Beginning TEST login script stub.

15:31:02: Login script stub complete.
[STEP 3 of 5]
[STEP 4 of 5]
[STEP 5 of 5]
Relaunching dock(s)...

As you can see, they are completely and totally different. Clearly an entirely different process is being invoked.