Error: Package was not successfully downloaded. 403

I just opened a ticket. I am seeing a lot of Package was not successfully downloaded. 403 today on known working packages and policies.

Any insight? seeing this as well.

Are both of you using the Jamf Cloud Distribution Server? If so, please reference this ticket number when you open your own support incident. JAMF-1272714

It's been an ongoing thing since last week.

@techmchs @supersizeal @Kaltsas Are all of you also on US-East?

I'm in Boston, Ma.
I already have an open ticket but no resolution yet. They're prob neck deep in this.

I don't think so at all. My incident was moved to a "success" case and linked to an OLD PI. Then today's email said they are going to schedule a meeting with Engineering "some time this week" to figure out next steps.

This sounds like corporate gibberish for "nobody in Engineering will listen to support and they don't really care that things are broken for customers"

We are on east. Looking at deployment logs the problems started the same time the jamf cloud upgrade was supposed to take place (but was then canceled). The last I heard it was with "the cloud team". I think something happened when they emergency canceled the upgrade.

The way the downloads immediately fail, it's like whatever bit in the jamf database that ties your package with a file in the AWS bucket is messed up so when the client asks for pkg it's wrong.

Isn't it horrible that tickets are closed with 'Success' as soon as the issue is believed to understood, while the users still suffer from this issue because it is not yet fixed? Issue tracking at JAMF needs a major overhaul.

I just started seeing this in the last 30 minutes. I am on east in the US. I am testing a simple DMG file and it worked. I made a modification and re-uploaded it and now I'm getting that 403 error. It allows says "the network connection was interrupted while downloading the package." But that doesn't seem to be the case.

@zrdean Definitely open a ticket with Jamf. We need as many of them opened as possible to keep the pressure on. Hopefully they will finally (after 2 years) come up with a real solution.

@tomt Is this not a new thing? I did open a ticket. Does this usually just 'go away' or what?

The issue had been sporadic for the past couple of years but last week it seemed to explode into a major thing.

Started noticing this same symptom back around the 11th or 12th, and it was due to recently-uploaded new packages seemingly uploading fine to our cloud distribution point, but upon checking back on them they actually failed uploading.

Had a week-long, escalated ticket with Jamf where they had me reupload packages over and over on different network/machines/methods (web vs. Jamf Admin) with no success. They then literally told me "nothing else you can do other than keep trying", while also suggesting potential database issues with duplicate names... even though I cleared stated several times that I was uploading new packages with display names and file names that our deployment had never seen before.

They only acknowledged an issue on their end when I finally asked around on Reddit, got others to confirm this has been a recent issue for many others, and then got a functioning workaround in like 5 minutes that I never would have otherwise tried. (Changing categories at time of upload-- this made a package actually upload & then successful download via a policy in JSS again)

Based on the recent rash of similar complaints in several places now, I feel like this has to be somewhat widespread.

@ajc196 When you say "change categories" did you let the initial upload fail and then re-upload the same file under a different category? I ask because I aways choose a category before uploading new packages.

@tomt To illustrate what I saw:

• never_before_seen_packagename1.pkg + [no category assigned] = Upload failed.

• never_before_seen_packagename2.pkg + [assigning any category] = Upload immediately worked, and package later downloaded via JSS without error.

Never-before used display names were also used for each example above.

I've not really used categories for app packages because I tend to categorize my computer policies, which is why this never dawned on me to try initially. But that said, this has not been an incorrect thing to do in Jamf (as far as I'm aware?) in the years I've been using it.

I was having this same issue this week and submitted a ticket. They got back with me and said this is a known problem on their end beginning last week. They said you have to delete the offending packages and re-upload them with a different file name. They also attached a list of packages that had this issue. Some of them were up to two years old. Hope this helps someone.

US East, also having this issue at this time. It seems to only be specific items though.

On the west coast the same issue... the pretty frustrating and bad time of year to have this happening. If I upload in GUI the Availability pending takes forever to even see if the package was a success.. this needs to be fixed asap.

I was working last week and this was an issue.. a week later and still a problem.

@drhoten Please add this thread to your background information surrounding the JCDS issue.

Thanks for calling this out @tomt, I've added it to my list.

In my case, this issue started once I reset a device. All packages are showing this error. whereas configuration profiles are getting applied i guess

I have the same error. It started last week with errors when uploading packages via Jamf Admin or directly JSS.
Now, some of my packages cannot be downloaded AND many manual policies are not running anymore ...
Our Jamf cloud distribution is on European server.

Something interesting I noticed that is:
I tried to install a package on 24/07/2020 and it failed with the Error: Package was not successfully downloaded. -1005 or 1202
But on the device logs, it says that I tried to install it on 26/06/2020 !!

I've seen it come and go, like it'll work great for a week or two, then get plagued again. Today and yesterday are plague days. Makes us look really bad when we need to clear the failures, then the users get the popup notification AGAIN for the same software that they thought they already updated.

I got the same error too while testing a macOS upgrade on my cloud sandbox, also hosted on US-east. I honestly though it was just me and I ended up re-syncing in Jamf Admin but I haven't tested that again to see if it's resolved.

I'm having the same issue. It's only occurring for new packages uploaded since yesterday noon. "Error: Package was not successfully downloaded. 400".