Skip to main content

I have this issue that I cannot seem to get a handle on. I have had at least 3 support requests with JAMF on this issue over the last year or two. They don't seem to have an answer. I have also scoured jamfnation for others with this issue.

Problem:
1. During a policy running, i sometimes get an error "The network connection was interrupted while downloading the package from https://<Path to package> Attempting to reconnect..."

  1. This is followed by another attempt, or two, or six.

  2. Finally Error: Deploy VMware Fusion(11.1.0).mpkg.zip is not available on the HTTP server.

I get this error on both my Master (internal NAS) and a Cloud Distro point. (see attachment)
I am on jamfPro 10.13 running on Windows Server 2012. The Cloud is Amazon S3

This does not happen:
- Consistently by client OS
- Consistently by package
- by distro point
- Packages are small, medium and large. (3M --> 2.5G)

Sometimes they work (on some clients) other times they fail. Same policy, same scope same OS, same type of computer.
The packages are there on the distro. I have verified on both distro points, by jamf Admin and logging into S3.
Packages have been rebuilt. no difference.

The last support ticket ended with the suggestion that I turn off Package validation. It seemed to stop... but now it is back.
Network guys say that they see no additional interaction with the client computer after the initial fail.
In order to get an accurate policy start time and end time i have added a PrePolicy and Post Policy script. (see #4 for the result of the Pre script)

I am about to open another service request but wanted to throw this out to the 'nation to see if anyone else has this problem.

I usually see this when the certificate that jamf uses to authenticate/authorize the Mac is not in the keychain any more. Result: the storage server refuses the connection.

Easiest solution is to re-enroll the Mac in question.

I don't know why jamf comes up with such a useless error message, after all it knows what is wrong, so it should provide a proper error message!

is this issue resolved now ? I have the same messages The network connection was interrupted while downloading the package from... for one of the network segments, and cant trace the root case yet. If you change network connections - applications deploy normally...

I also have the same issue anyone have an update?

we are also randomly seeing this.

I will see this occasionally. I will look at the computer throwing the error>Policy logs, and will notice that policies have succeeded just prior to and just after the failed policy, and also using the same DP. I just flush the fails and let them run again. I think if a device has a few policies queued up, they occasionally step on each other, possibly mounting and dismounting the DP awkwardly. Since the failure rate is extremely low I am not getting worked up over a few fails, and especially since I cannot control what a student might be doing at the other end (like closing lid). I am at JP 10.17 but have seen these errors throughout versions. Since other polices are succeeding, and other devices successfully complete that failed policy I don't believe any action (re-enrolling for example) is needed.

I'm occasionally seeing this behavior and we're running hosted JP 10.17.1

I haven't been able to point the blame to any one thing specifically. The behavior seems to randomly resolve itself without any interaction from us aside from flushing the policy and letting it run again. It is incredibly annoying and I wish there were some way to pinpoint why this is occurring.

It's because you have spaces in the filenames (noted by the %20 in the url). This always causes issues for me, so I use underscores or dashes in filenames, no spaces.

@McLeanSchool - Thats a great point. Something we consider as standard operating procedures when naming scripts and packages... 【ツ】

A few things to check:

  1. DNS can cause this (it is always DNS, amirite?)
  2. When the jamf database doesn't have matching hashes of the packages, this has happened post jamf upgrade to me in the past
  3. The binary is probably using something like NSURL, can you curl the package down manually?
  4. Then of course there are just plain old network bandwidth issues. We are cloud and I have seen this with remote users, who are trying to download large packages over slow internet connections
  5. If you salt/hash your URLs with an expiry, and that URL has expired

We see these errors on HTTP distribution points when the 5 minute grace period is exceeded on resumable downloads.

I am seeing this issue with our DMZ instance (we are onprem cluster). I have an ongoing case raised with Jamf support.
We are now running JSS 10.27 on our 2 instances.

"Error: Package was not successfully downloaded. -1004"

The package filename does not contain any spaces in its name.
I am able to download and install the same package via the OnPrem/LAN instance.
I have verified permissions of the required casper accounts to the caspershare.

Terms & ConditionsCookie settingsAccessibility statement