Skip to main content

Hello all you friendly Jamf admins! I've got a problem that's stumping me and my colleague, hoping somebody here can shed some light.

Recently (starting last week), I have begun encountering an issue where running sudo jamf policy produces unexpected results. When run locally, policies will fail. They attempt to run, and produce the following output, using Firefox as an example:

Installing Firefox ESR 115.4.0...

Installation failed. The installer reported: installer: Package name is Firefox

installer: Upgrading at base path /

installer: The upgrade failed. (The Installer encountered an error that caused the installation of fail. Contact the software manufacturer for assistance. An unexpected error occurred while moving files to the final destination.)

This occurs with both Chrome and Firefox, both of which I recently packaged. This occurs with both Patch Management Policies and regular Policies. I created the packages in Composer from my Applications folder, with 755 root:wheel permissions, the same way I have for all previous packages I've made. These just recently started to fail. Older packages still successfully install. I haven't changed any settings in Jamf Pro or Composer.

What's really throwing us for a loop is that if I SSH into these machines and run a policy update, the packages install with no problem. It's just running the command locally that it fails. I'm logged in with the same account in both places, a local admin.

The install.log mentions that the failing packages aren't signed:

trust evaluation failed: Error Domain=PKInstallErrorDomain Code =101 "The package "Firefox _ESR_115.4.0.pkg" is not signed."

but I've never signed these packages before and they worked just fine.

If this rings a bell for anyone that's encountered this before and could point me in the right direction, I would be very grateful. Thanks!

 

Are there any scripts (postinstall, postinstall, etc) included in these packages? Or are they just dropping the .app into Applications?

Are there any scripts (postinstall, postinstall, etc) included in these packages? Or are they just dropping the .app into Applications?


Just dropping the .app into Applications, no scripts at all.

Any odd characters in the package name? It doesn't look like it from what you posted, but I'm just spitballing.

What about if you run the package locally? Like double click the pkg in the Finder and install it that way? Anything to note in any messages from Installer.app? I can't think of what would cause a pkg to fail to install in one of those scenarios, but not the other. Sounds like its the same account, same privileges. They should work the same way. Odd.

Any odd characters in the package name? It doesn't look like it from what you posted, but I'm just spitballing.

What about if you run the package locally? Like double click the pkg in the Finder and install it that way? Anything to note in any messages from Installer.app? I can't think of what would cause a pkg to fail to install in one of those scenarios, but not the other. Sounds like its the same account, same privileges. They should work the same way. Odd.


Negative, shouldn't be anything strange. I've also redownloaded this from Google/Mozilla and repackaged it 3 different times, even tried it as a .DMG, thinking maybe it got corrupted or something. No joy.

What Applications directory are you dumping the source files in to? Any random chance its ~/Applications?

What Applications directory are you dumping the source files in to? Any random chance its ~/Applications?


I'm not 100% sure I understand the question - I'm pulling the .app from my /Applications folder into Composer, packaging, and dumping the package into ~/Desktop/Packages. Not sure if that's what you're asking; if not, please let me know and I can provide more details. Thanks!

I'm not 100% sure I understand the question - I'm pulling the .app from my /Applications folder into Composer, packaging, and dumping the package into ~/Desktop/Packages. Not sure if that's what you're asking; if not, please let me know and I can provide more details. Thanks!


MacOS has more than one Applications directory. You have the typical one that most people use which is /Applications. However, macOS also has a /user/{profile}/Applications directory. 

 

For science: What happens if you put Chrome or Firefox into a different directory? 

I assume you're repackaging because you're in a field that requires the application be verified first before deploying? I would download Suspicious Package and see what's truly inside the package

 

FYI the error you're running into when running locally is Gatekeeper because the package isn't signed. If repackaging is necessary then I'd either sign it Jamf Pro or get an Apple Developer account and create an installer cert. 

I assume you're repackaging because you're in a field that requires the application be verified first before deploying? I would download Suspicious Package and see what's truly inside the package

 

FYI the error you're running into when running locally is Gatekeeper because the package isn't signed. If repackaging is necessary then I'd either sign it Jamf Pro or get an Apple Developer account and create an installer cert. 


That's correct - our Security team has specified all packages must be downloaded, verified, and repackaged. Not ideal, but that's the directive.

What's odd is we've never had to sign these packages before, and we've been doing this process since we stood up our Jamf Pro environment 3 years ago. Not sure why that would have changed since I haven't installed any updates to Jamf Pro (on prem).

That's correct - our Security team has specified all packages must be downloaded, verified, and repackaged. Not ideal, but that's the directive.

What's odd is we've never had to sign these packages before, and we've been doing this process since we stood up our Jamf Pro environment 3 years ago. Not sure why that would have changed since I haven't installed any updates to Jamf Pro (on prem).


I only sign the packages that I have attached to my prestage enrollment profiles but otherwise you shouldn't really need to if it's being installed by a policy.

MacOS has more than one Applications directory. You have the typical one that most people use which is /Applications. However, macOS also has a /user/{profile}/Applications directory. 

 

For science: What happens if you put Chrome or Firefox into a different directory? 


I am able to successfully deploy Chrome to ~/Applications by packaging as a .dmg and selecting the Fill Existing User Home Directories option. So it's objecting to writing these packages to /Applications.

I only sign the packages that I have attached to my prestage enrollment profiles but otherwise you shouldn't really need to if it's being installed by a policy.


That's what I was thinking - we've never had to sign these before, and old packages that aren't signed still successfully install.

That's what I was thinking - we've never had to sign these before, and old packages that aren't signed still successfully install.


Same here. I had briefly signed packages I was building at one point, but stopped doing it because it requires that the packages be updated (rebuilt) once the certificate expires, which if you're using a basic dev account I believe is once a year. Otherwise packages with expired certificates fail to install.

I can understand why it's done in some environments, but for us, Jamf Pro is already our trusted source, so we trust the packages that we've vetted and added to our distribution point. Signing them seems like an extra unnecessary step.

I still can't quite understand what's going on for you here though. The installs should be working in both instances. It's puzzling that they are failing one way but not the other. Have you opened a ticket with Jamf on this to see if they might be able to help you track down the cause?

Same here. I had briefly signed packages I was building at one point, but stopped doing it because it requires that the packages be updated (rebuilt) once the certificate expires, which if you're using a basic dev account I believe is once a year. Otherwise packages with expired certificates fail to install.

I can understand why it's done in some environments, but for us, Jamf Pro is already our trusted source, so we trust the packages that we've vetted and added to our distribution point. Signing them seems like an extra unnecessary step.

I still can't quite understand what's going on for you here though. The installs should be working in both instances. It's puzzling that they are failing one way but not the other. Have you opened a ticket with Jamf on this to see if they might be able to help you track down the cause?


I hadn't when I opened this thread, but I have now. If they're able to track this down, I'll let everyone know!

Okay, I've figured out what this was. Wasn't Jamf at all, was my stupid mistake.

System Settings > Privacy & Security > App Management > Terminal was toggled off. Once I turned that on, all those packages started to work.

I wasn't aware of this setting until one of my colleagues pointed it out to me. Leaving this here as a monument to my own silliness, and in case any future folks run into this.

Thanks everyone for your ideas and help tracking this down!

Reply


Terms & ConditionsCookie settings