I should have indicated the symptoms of the problem
Unable to use jamf commands in terminal -- Jamf command not found
Jamf Remote indicated
Failed to symlink JAMF The file "jamf" couldn't be saved in the folder "bin".
Failed to symlink JAMFAgent The file "jamfAgent" couldn't be saved in the folder "bin".
Thanks KAD, solved my problem (one of many!)
Seems like it didn't solve my problem after all, I'm still getting 'Jamf command not found' and I've double checked the package and the script. The file and folder structure of /usr is correct.
I have the same issue after enrollment, the Jamf command does not function and I need to run the binary directly. It does not matter if I use the QuickAdd package or just install the MDM profile, same issue. I did notice that this issue does not exist when using Casper Imaging.
This issue was noticed in our environment following upgrade to 10.4.1 exactly as noted above by the original poster. Systems were enrolling correctly to Jamf PRO but had no access to utilize the Jamf binary afterward. All commands would fail. Upon comparing the newly generated QuickAdd package to our prior version QuickAdd package, we found that the mkdir command for /usr/local/bin was simply not present in the default postflight script included in the QuickAdd package by Recon 10.4.1. Adding that single line into the script resolved the issue for us. Had to removeFramework and delete the botched symlink on test units in order to get a clean test with the new, modified package. The resulting QuickAdd has worked for us consistently and provided a Jamf binary that is correctly accessible and functional for the end-user. Great catch @KAD! Thank you for posting your experience. You pointed us to exactly the right spot to quickly resolve this.
Same Problem here. I've added the line to the post install script, but I still get the same error and can't remove framework.
We've also ran into this issue. Did a quick chat with JAMF and they are aware. Under PI-005852.
Anyone else seeing:
jamf[1120:8794] CFNetwork SSLHandshake failed (-9807)
When running a jamf recon on a workstation with a modified quickadd.pkg as noted above?
I imaged three machines, one with the original quickadd, one with a modified quickadd and one enrolled via DEP. Only the modified quickadd.pkg is giving the noted error on a recon.
Just checking with JAMF supported about this.
Thanks for this thread! Updated to 10.4.1 today and was having this issue. Adding the line to the quickadd package fixed it. I also created a policy that runs on the machines that had the faulty quickadd done on them that removes the bad /usr/local/bin symlink, then installs the working quickadd, all is golden
Thanks!
MK
For anyone seeing this,
You need to remove the already in place folders in /usr/local/jamf then re-run the quick-add package. If you dont then it wont be able to re-add the folders etc. You should also probably remove the /Library/Application Support/Jamf folder. Though this will re-appear immediately
I also removed the computer from the JSS just to make sure.
I've just created script to fix this on enrollment instead of modifying each quickadd.pkg. This seems to be working for me.
#!/bin/bash
# check for symlink
if [ -L "/usr/local/bin" ] ; then
rm "/usr/local/bin"
mkdir "/usr/local/bin"
ln -s "/usr/local/jamf/bin/jamf" "/usr/local/bin/jamf"
ln -s "/usr/local/jamf/bin/jamfAgent" "/usr/local/bin/jamfAgent"
chown -R root:wheel "/usr/local/bin"
fi
I'm still seeing this behaviour with 10.5.0.
Is there a ticket I can follow for this bug?
We've also ran into this issue. Did a quick chat with JAMF and they are aware. Under PI-005852.
This is all they gave me.
So, if we indeed go and "fix" this with one of the methods listed, what happens when Jamf actually fixes it? Will the fixed dir just continue to work?
Don't want to have to track down all this mess if we make a work-around...
BTW, thanks @ubcoit - this little script running after enrollment did the trick.
This is one of the reasons we stopped making QuickAdd packages years ago, and we restrict the ability to do so as well.
We send techs to the https://server.domain.com:8443/enroll page instead.
We have deferred the MDM User Allowed Enrollment workflow (*) to macOS 10.14 and might defer it further (Jamf can provide the MySQL steps).
So new enrollments do not show the PI-005852 issue in our environment.
# ls -lF /usr/local | grep bin
drwxr-xr-x 6 root wheel 192 Jul 23 11:48 bin/
and
# ls -lF /usr/local/bin/ | grep jamf
lrwxr-xr-x 1 root wheel 24 Jul 20 10:49 jamf@ -> /usr/local/jamf/bin/jamf
lrwxr-xr-x 1 root wheel 29 Jul 20 10:53 jamfAgent@ -> /usr/local/jamf/bin/jamfAgent
(*) Ask your Jamf rep, deferring MDM User Allowed Enrollment workflow to a later macOS version is fully supported.
Don
Sadly, 10.6.0 doesn't address this one...
After today's <redacted> testing, we are definitely going to defer the MDM User Allowed Enrollment workflow to macOS 10.15.
As mentioned earlier, ask your Jamf rep, deferring MDM User Allowed Enrollment workflow to a later macOS version is fully supported.
Hello everyone, PI-005852 was fixed for 10.6.0. If you are finding a QuickAdd package from Recon.app still does not create the /usr/local/bin directory please reach out to support.
I believe 10.6.0 has addressed it but didnt make it into release notes (as of today at least). See my post here https://www.jamf.com/jamf-nation/discussions/28764/jamf-quickadd-symlinks-usr-local-bin-causing-install-problems-for-other-apps#responseChild169545
@donmontalvo when you said you just send techs to the enroll page, do you create new users for them or have them enroll with a generic user account?
@drhoten - I just looked again, and PI-005852 is not shown as a fixed issue. Just want to make sure before I move forward.
@drhoten agreed - updated a ticket for them to revise release notes - hasnt happen, if it'll happen at all yet
I can confirm creating a new quickadd package on 10.6 resolved this issue for me.
Also confirmed that enrolling via URL or new QuickAdd works as expected. Thanks!
