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