Failed policy: Package could not be verified

How are you sharing out your caspershare? AFP works well with pkg, but if someone is connecting via SMB or HTTP, I can see pkg failing.

using SMB, because our JSS is on a Windows Server 2008 VM. But like I said it doesn't fail all the time, just sometimes. Is it failing because the verification process doesn't work well over SMB? I didn't want to just disable verification for testing without at least asking here first.

This happened to me today with a generated CS6 package. We too are using Windows Server/SMB and have not had this problem in the past. The package looks valid on the server, but I do notice it increased in size slightly after uploading.

@The.Tiger, Yeah, first 9.31 then 9.32, same issue on both. I was hoping to solve it without disabling verification, but I disabled verification the other day and it did seem to fix the issue so I'll just make sure all my packages are checksummed in Casper Admin and leave it at that.

@znilsson

In Casper Admin, if we highlight the packages without checksums and right click, is there an option to calculate checksums?

If so, we can try that and those packages should get a valid checksum so we can leave package validation on.

Amanda Wulff
JAMF Software Support

@amanda.wulff - That's the problem, I was getting verify errors on fully checksummed packages. See the original post in this thread.

@znilsson

I saw that, and it made me wonder if having Admin recalculate the checksums, then saving would fix it and allow package validation to remain on, or whether the problem would remain after recalculation.
If that's something you've already tried, I apologize for missing that!

I'm guessing the checksum looks normal and doesn't look like the local path from which the file was uploaded as well (that's a defect, which is why I mention it), correct?

There are some current issues with SMB share points and Mavericks, but as far as I've found they don't relate specifically to checksums and tend to manifest more in failure to mount the distribution point entirely, so I don't think we're hitting any of those.

Amanda Wulff
JAMF Software Support

Oh, no I actually did try that and it didn't work, I don't think I mentioned that though. And the confusing part is how it was working for some installs but not others, seemingly at random.

@znilsson

I suppose it's remotely possible that it has to do with the share point being a Windows SMB share, but I'd call that a long shot; for all of the issues between Mavericks' SMB2 and Windows SMB1 (link is to a JN thread about that issue), randomly invalidating checksums hasn't been something I've seen come up, though if it's being 'caused' by connections being extremely slow or dropping, it's possible that could be the underlying cause.

Still pretty unlikely though as, if that were the case, we'd likely see the packages continue to seemingly randomly fail (with different errors) with package validation set to never, as well as see issues involving errors stating that the distribution point could not be mounted.

I did a quick check and see that there's not a case open on this topic; if you'd like to dig into it a bit further to see what's going on, your Technical Account Manager should be able to help with that. I'll also let him know about this thread so he can take a look at it and either weigh in or reach out to you directly.

Thanks!

Amanda Wulff
JAMF Software Support

Any chance the verification is failing because it was trying to checksum R/W disk images?
https://jamfnation.jamfsoftware.com/discussion.html?id=10049

A few things on this. 1) Casper 9.32 has a known defect when calculating checksums in some circumstances which can cause replication errors. (defect ID D-007153). In my case the DPs aren't agreeing on each packages checksum so I've had to replicate based on modification date (AFP and SMB differ on block sizing so be careful there).

That said, I had these errors until I went through user migration for some reason. I can't seem to remember why. Amanda is 1,000 x smarter than I so...

I have a few .mpkgs that fail checksum verification when installing from AFP distribution point, but install perfectly when cached and then installed from the cached version. Not a huge deal for me, anyway.

I am trying to find an explanation of what happens during package installation via policy/remote in relation to package verification?

I have very large packages and I have experienced up to an hour and a half wait during which time the machine is downloading and then it moves from "verifying package integrity" to "installing <packagename.pkg>" and continues to download for an extended period.

Tell me it isn't downloading the whole package to do the initial verification then downloading again afterwards?

Would turning off verification be advisable just to get larger installs out faster?

Are you caching then having another policy to install the cached package? Or just installing?

I am not caching them. Not because I don't want to but because I haven't had a need to (or haven't been able to find the benefits at this time). All my machines are cabled and the network is reliable but if the traffic is being increased due to the way its doing the verification, I can change my workflow.

edit:::::

Right, I can see it myself. Its reading the entire file to check the integrity then downloading the entire file. So my 55GB file is a 110GB file.

@nigelg
Wow, That is a massive file size and yeah you are right I guess it does two things on the file size(check the integrity which it need to verify the checksum and download the file).
For me anytime I have a package over 6 GB, I tend to cache it before I push another policy to Install the cached file.
What JSS version do you have at your environment? I updated our JSS to v9.51 I just turned the package validation on to see if that still an issue.

This thread solution appears to have helped with our Self Service package for a Yosemite manual upgrade that worked for central office testing but was failing in one of our buildings with the message "Package could not be verified". Many thanks!

I know this is a super old post. I came across it when searching for reasons on why a particular package failed to install due to it could not be verified. Hoping my observations might help others. First, I'll let you know that I have an OnPrem DP and a Cloud DP setup. I'm in the middle of migrating devices from my OnPrem JSS to my Cloud JSS. I found that packages installed fine without any issues to Macs that were enrolled in my OnPrem JSS and downloaded from the OnPrem DP. However devices enrolled into my Cloud JSS failed to download from the OnPrem DP due to it could verify the package. I have the Cloud DP setup as a failover but it failed to download from there with an error code 403. I suspect the reason for that is because it fails to replicate that package to the Cloud DP when I do the replication via Jamf Admin.

What is causing the issues? It appeared the reason the Cloud enrolled Mac couldn't download from the OnPrem DP because the checksum didn't match. When I opened Jamf Admin to my OnPrem DP the checksum was one number. When I opened Jamf Admin to my Cloud DP it was a different checksum. I reran the checksum and now I was able to install the package on the Cloud enrolled Mac from the OnPrem DP. 

I reran the replication after I made the change with the checksum however it didn't resolve that issue - it still failed the checksum. Good news is I can at least get it from the OnPrem DP for now.

Did you ever get this working?

We are having the exact same issue and its driving me crazy.

For me I've changed how I'm uploading packages. I'm now uploading it directly into Jamf Pro Cloud console via Settings>Computer Management>Packages. Note: You have to make sure to set your Cloud DP as the primary in order to upload the package.

• Once that is uploaded I login to Jamf Admin (pointed to my Cloud instance) I replicate from the Cloud to my OnPrem DP.
• Once that's done I logout of Jamf Admin and relaunch it holding down the Option key so I can point it to my OnPrem instance.
• I then change the Category and you can run the checksum then Save it before you quite Jamf Admin. 
• Then you can go back to Jamf Pro Cloud and change your primary back to your OnPrem DP if you wish. 

That's it! Things have been working so far.

I was seeing this issue as well over the last couple of days, and I was wondering if you where using package signing on the files you where having issues with?

We've recently moved to Jamf Cloud, and use the Cloud DP for production, but have a number of OnPrem DP's that we use for testing, caching, and the previous instance had verification turned off.

When we looked, we were only seeing this issue with un-signed packages, once the dev's started signing them with a valid certificate the issue went away, I'm assuming this is because its easier to check that than what ever hashing Jamf is doing?

Does this match with your experiences?

"never" is not an option for me. its either "when checksum is present" or "always". What should i do?