Error: Package was not successfully downloaded. 403

[supersizeal]

I am having issues installing Apps from my Self Service Portal.
The log is reporting back with this "Error: Package was not successfully downloaded. 403"

When I install the pkg on my computer it installs fine.

This is what I have notice but I"m not sure where to start troubleshooting.
I copy the working pkg to my Jamf Admin and the replicate to my Jamf Cloud and it was able to replicate.

Test in Self Service I get the error message.

I go back into Jamf Admin and I replicate without adding or removing any files and it starts to replicate the previous file again.

Thanks in advance!

[Kaltsas]

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

[techmchs]

Any insight? seeing this as well.

[tomt]

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.

[tomt]

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

[supersizeal]

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

[tomt]

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"

[Kaltsas]

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.

[mschroder]

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.

[zrdean]

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.

[tomt]

@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.

[zrdean]

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

[tomt]

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

[ajc196]

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.

[tomt]

@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.

[ajc196]

@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.

[KISDCTE]

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.

[david_edgar]

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

[techmchs]

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.

[tomt]

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

[drhoten]

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

[nivast]

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

[ThierryD]

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 !!

[JayMac]

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.

[dng2000]

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.

[rsteffens]

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

[brayg]

Same issue here. Pkg's will work via Self Service for a couple weeks, then eventually fail to download with a "Error. Package was not successfully downloaded. 403". Some fail immediately after initial upload then work after re-uploading with a different name. Seems to be specific to Self Service based policies/pkgs.

[nivast]

If it helps, the basic thing you should check is whether your Activation code is not expired. In jamf nation account one can find this

[Majid]

How can i fixe the erreur 403 ?

[jp2019]

Has anyone found a resolution to this?
Error: package was not successfully downloaded. 403
Error: FalconSensor 6.12.12505.pkg is not available on HTTP server. I am using Jamf Cloud distribution point.

[Jawalker]

Did you ever resolve this issue? I am trying to push the latest version of CrowdStrike to my devices and keep getting an error 400 message saying the package was not successfully downloaded.

[elliottarrant]

I'm having this problem too. Jamf Cloud Distro. Trying to download a new pkg.
Error: Package was not successfully downloaded. 403
The network connection was interrupted while downloading

[tomt]

This has been happening constantly for many months. When users were in the office and pulling from our local DPs, we didn't see as much of it. But since everyone moved home and are now pulling from Jamf's cloud, we are seeing this multiple times daily.

[snowfox]

Ok after reading more through this thread I may be referencing a different download problem...

I sometimes have this problem with large packages downloaded from a resellers remote DP. To fix it I have to select Cache the package first in the packages section of the policy and then Install cached package as a second package step in the same policy.

This ensures the full package downloads first before the workstation tries to install it.
If a policy just has 'install' it can try to kick off the package installation before it has fully downloaded the package. Doesn't always happen but I have seen it.

It started doing it for our self service install of Catalina 10.15.7, which it wasn't doing before we upgraded to 10.25.2. So I change it to cache and then install cached and that fixed it.

I've also seen it happen when a large package is still syncing from our on prem DP to the resellers DP.
Jamf will download the unfinished package and try to extract it. You'll get an error 'saying the upgrade failed' the package may be corrupt. When you change it to cache instead of install, you'll find your 8Gb package is only downloading 3Gb to the waiting room folder on the workstation. That's how you know the package hasn't finished syncing to the cloud DP.

[robertojok]

I often run into this problem now and again but it seems to be only certain packages that create this issue. The quickest way around this is to use Packages.app.

You can drop the pkg into packages the Additional Resources of the Scripts tab and add a Post-installation script to install the pkg.

This is an example script I used to install a software called Melodyne which I could not install the pkg I downloaded from the site...

#!/bin/bash

# Program: Melodyne 5_1_1_003.pkg.sh

# Determine OS version

osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

# Determine working directory

install_dir=`dirname $0`

# Install Melodyne 5_1_1_003

/usr/sbin/installer -dumplog -verbose -pkg $install_dir/"Melodyne 5_1_1_003.pkg" -target "$3"

Upload the pkg and install... it always works for me when I get that error.

[DWilliams-cmsd]

Glad I found this thread.  Had the same issue with select Adobe CC packages.  Changed name, re-uploaded via JSS web interface, and re-deployed with complete success.  Thanks to all above for posting your experience.  Made solving the issue easy.

[Ignition]

Yep, same here with an Adobe CC package that I pre-zipped. I removed a space, and a + sign in the name and then the file came out of pending within a few minutes and now deploys properly.