Skip to main content
Question

Ended up with a "/bin/echo/" glued to the Jamf server address for one client

  • May 2, 2019
  • 1 reply
  • 11 views
C
Forum|alt.badge.img+4

We remotely enrolled a Mid-2012 Macbook on 10.14.4 today via Recon, and while the initial enrollment went fine, it could now no longer check into the JSS after a reboot (which is on 10.9.0).

When running a "jamf checkJSSConnection" test on this client, it returns the following:

I was able to fix this by updating the Jamf server address in the client's com.jamfsoftware.jamf.plist file using defaults write, but has anyone else encountered this before? Any idea what might have caused it? This is the first time I've seen a machine do this across 300+ enrollments (granted we very rarely use Recon to do so).

    1 reply

    C
    Forum|alt.badge.img+4
    • cornwella
    • Author
    • Contributor
    • May 2, 2019

    Got this case to reproduce. This isn't caused by Recon, it's caused by Jamf Remote trying to verify the com.jamfsoftware.jamf.plist file on this machine when trying to send a script or package to it:

    This step never ends up finishing and glues the "/bin/echo/" onto the server's address. Looks like a Jamf Remote bug (albeit an obscure but potentially hazardous one). If this was mentioned in the known issues list for 10.9, I couldn't find a reference to it.

    Terms & ConditionsCookie settingsAccessibility statement