Skip to main content

This has been happening off and on and I'm not entirely sure why... a perfectly good script, meaning it will run locally from the command line, will not run as a policy. This is a script that worked fine prior to 9.8 upgrade (we are running 9.8.1). Note, the script continues no reference to the jamf binary.



The error I get is:



Running script RebootNotification_v1.0.sh...
Script exit code: 127
Script result: /bin/sh: /Library/Application Support/JAMF/tmp/RebootNotification_v1.0.sh: No such file or directory



Running it via Casper Remote gives me:



Sending Wake On LAN command...
Opening SSH Connection to xx.xx.xx.xx..
Authenticating...
Successfully authenticated.
Verifying Computer's Identity...
The MAC Address has been verified.
Checking Operating System Version...
Running Mac OS X 10.10.5 (14F27)
Verifying /usr/local/jamf/bin/jamf...
/usr/local/jamf/bin/jamf is current (9.81)
Verifying /usr/sbin/jamf...
/usr/sbin/jamf does not exist.
Verifying /Library/Preferences/com.jamfsoftware.jamf.plist...
Preparing Policy...
Executing Policy 2015-10-09 at 1:18 PM | yellow | 1 Computer...
Mounting Casper to /Volumes/CasperShare...
Running script RebootNotification_v1.0.sh...
Script exit code: 127
Script result: /bin/sh: /Library/Application Support/JAMF/tmp/RebootNotification_v1.0.sh: No such file or directory
Submitting log to https://casper.domain.com:8443/
Finished.


Set up as a ongoing policy.
Running it as a policy fails.
Running it from command line as a -trigger worked ONCE. After that, always fails.



Run as a trigger:



ThisMac:Source yellow$ sudo jamf policy -trigger "runRebootNotification"
Password:
Checking for policies triggered by "runRebootNotification"...
Executing Policy [beta] Reboot Notification [beta]...
Mounting Casper to /Volumes/CasperShare...
Running script RebootNotification_v1.0.sh...
Script exit code: 127
Script result: /bin/sh: /Library/Application Support/JAMF/tmp/RebootNotification_v1.0.sh: No such file or directory


And I do have a tmp folder in my JAMF Application Support folder.



I'm seeing this more and more and it's becoming a problem.



Anyone else seeing this?



(I'd pay no attention to the obvious bug in Casper Remote, in checking for a binary that is no longer there).

@powellbc I haven't heard of npm before, so I looked it up (https://docs.npmjs.com/getting-started/what-is-npm)
It looks like a custom binary or something to work with javascript. So the question that comes to mind for me is, does it exist on the Mac the script is trying to run on? When we see 'command not found' in script error output, it usually means exactly what its saying. The shell can't locate the command you're calling. I think in this case including the full path to npm may resolve the issue. Remember, using shortened forms of calling binaries, like cp, jamf, awk, etc usually work OK, but in some cases you need to use full paths - /bin/cp, /usr/local/bin/jamf, /usr/bin/awk, etc.
If you can pull it up on the Mac in question with which npm, then use the full path that the command returns in your script and see if that helps fix it.


@mm2270 As soon as I saw this email come in I was looking at where it was running from. I ended up trying the wrong path but the "which" command got the correct one. The script is now working correctly. Thanks!


Are people still seeing this issue? I am on some of mine with the simple script we use to pull the logged in username.



#!/bin/sh

/usr/local/bin/jamf recon -endUsername $3


Works fine on most - running as an actual script. On maybe 8% though, we get:



/usr/local/bin/jamf: No such file or directory
Error running script: return code was 127.


When I get that, it's universally on devices that are super-old... e.g., running 10.6.8 or before. On those devices, the jamf binary still lives at /usr/sbin/jamf.



You could create a symlink to the old binary in the new location on those old devices. While this is not the best idea in the world, these versions of the OS are unsupported by Apple and according to our policy unsupported by us (at least that's what we tell ourselves).



sudo ln -s /usr/sbin/jamf /usr/local/bin/jamf



But the Error 127... I never did figure out what the root of that was. It wasn't the script. It wasn't the device. It just seemed to be a busted script/package on the DP. TestA would fail. TestB would succeed. TestA and TestB were exactly the same.


Thanks @yellow. I don't care about those old Macs either and we have the same "don't support" thing here LOL.
I'm pretty sure that the failures were not on those old Macs only though, and like you, the fail/success seemed to make no sense...


You could run this to see where scripts are running. It will output into the system.log file



#!/bin/bash

logger -t "com.jamf.test" $0

exit 0

It's happening again on a script that had previously worked. Grr...


Reply