Skip to main content

We have Jamf Pro 10.34 hosted on-premises.  We have a single server and a single SMB share, running on Windows Server.

We have some files that cannot be downloaded.  In Self Service, it says the file cannot be found, but it is there when we check the share and check Jamf Admin.  Other files work fine.  If we open a browser and just simply put in the URL to files in the share, most work but some do not.  On ones that do not download via Self Service, we get this in the logs:  Error: Package was not successfully downloaded. -1005

Any help would be appreciated.   Thanks.

@gregbr Check the file permissions on the files uploaded to your SMB share. Jamf Admin doesn't set the permissions on the files uploaded via SMB, so you can end up with files lacking the necessary read permissions.

Also you should really, really, really enable HTTPS on your DP if possible. It will eliminate this problem, speed up downloads (no need to mount the SMB file system), and you get resumable download support so that a single network hiccup doesn't result in a failed download like when using SMB.

Checking the file permissions, they are the same for the files that work and the files that do not.

Checking the file permissions, they are the same for the files that work and the files that do not.


@gregbr Is there _any_ commonality with the files that fail? .pkg or .dmg? If .pkg did you create them in Composer, or are they from the software vendor? Are the file sizes over a common threshold?

@gregbr Is there _any_ commonality with the files that fail? .pkg or .dmg? If .pkg did you create them in Composer, or are they from the software vendor? Are the file sizes over a common threshold?


It seems to be just PKG files.  They are from a few different vendors and different file sizes (500 KB, 2 MB).

It seems to be just PKG files.  They are from a few different vendors and different file sizes (500 KB, 2 MB).


You really should take the suggestion offered by @sdagley  I used to host my distribution point on the server when I ran Jamf Pro on a Mac. This proved problematic since all of the managed Macs were remote. None were on the same network as the server. I started running Jamf Pro on Ubuntu in 2018. Initially I used https on a separate Ubuntu server, but I later switched this to use Amazon Web Services. AWS gives me sustained download speeds of 400-500Mb/s. I tested this on my home internet service which is gigabit. Since switching to AWS there have been no download issues.... that is unless I fudged up the policy.

I contributed to this threat three years ago. I work with Jamf Cloud now. About a year ago, I started seeing the "Package was not successfully downloaded. -1005" error. I opened a case with Jamf. Actually, I have opened many cases with Jamf about this. We could never get this solved. A couple weeks ago, I created a script that checks and reports the current active network interface in use by the Mac. It also checks if the Mac can access our internal company resources that are not available publicly. I found that all of my policy failures were on Macs that appear to be in a sleep state. Their active network interface was en0 or en*... Something that was not a VPN connection. They also could not access internal company resources. If they had been able to access company resources and there's no VPN connection, that means they're in the office. Looking at the last inventory sent by the Macs showed me that their LAN IPs were not a company LAN subnet. These are Macs somewhere out of the office. The application usage log showed that the last time apps were used was days ago. These Macs are not in use. They're in a sleep state but still connecting to the internet. The Jamf agent is still checking in and sending inventories. Some of the Macs also did not have the latest versions of profiles that we update often. The policies are NOT failing. The Macs are just not in use. I know that this policy error may not always be caused by a Mac not in active use, but this appears to be why my policies that have an installer package payload have been failing on about 10% of our Macs. A lot of our users also have Windows PCs. I noted a long time ago, that policies with package payloads never fail if we run them in Terminal or through Self Service. They also never fail during the zero touch provisioning process after enrollment. I'm happy to have figured this out but I'm also very annoyed about the massive amounts of my time WASTED 🤬 I hope this helps others trying to figure out why they see this error.

I contributed to this threat three years ago. I work with Jamf Cloud now. About a year ago, I started seeing the "Package was not successfully downloaded. -1005" error. I opened a case with Jamf. Actually, I have opened many cases with Jamf about this. We could never get this solved. A couple weeks ago, I created a script that checks and reports the current active network interface in use by the Mac. It also checks if the Mac can access our internal company resources that are not available publicly. I found that all of my policy failures were on Macs that appear to be in a sleep state. Their active network interface was en0 or en*... Something that was not a VPN connection. They also could not access internal company resources. If they had been able to access company resources and there's no VPN connection, that means they're in the office. Looking at the last inventory sent by the Macs showed me that their LAN IPs were not a company LAN subnet. These are Macs somewhere out of the office. The application usage log showed that the last time apps were used was days ago. These Macs are not in use. They're in a sleep state but still connecting to the internet. The Jamf agent is still checking in and sending inventories. Some of the Macs also did not have the latest versions of profiles that we update often. The policies are NOT failing. The Macs are just not in use. I know that this policy error may not always be caused by a Mac not in active use, but this appears to be why my policies that have an installer package payload have been failing on about 10% of our Macs. A lot of our users also have Windows PCs. I noted a long time ago, that policies with package payloads never fail if we run them in Terminal or through Self Service. They also never fail during the zero touch provisioning process after enrollment. I'm happy to have figured this out but I'm also very annoyed about the massive amounts of my time WASTED 🤬 I hope this helps others trying to figure out why they see this error.


Another indicator of a policy running while a Mac is asleep is an inordinately long execution time. What makes this extra annoying is that Apple has removed the option to disable Power Nap and it is _always_ active for Apple Silicon Macs. One would hope that Jamf would have their agent detect when a Mac is in the sleep state, and prevent it (or provide the option to prevent it) from attempting to run a policy since the Mac will very likely return to sleep state before the policy can complete.

Another indicator of a policy running while a Mac is asleep is an inordinately long execution time. What makes this extra annoying is that Apple has removed the option to disable Power Nap and it is _always_ active for Apple Silicon Macs. One would hope that Jamf would have their agent detect when a Mac is in the sleep state, and prevent it (or provide the option to prevent it) from attempting to run a policy since the Mac will very likely return to sleep state before the policy can complete.


Someone suggested to me yesterday that I disable Power Nap. If we can’t do that on Apple Silicon then I won’t be doing that. You’re right that the Jamf agent should detect a Mac in a sleep state and not run the policy. No one at Jamf mentioned this to me.

Someone suggested to me yesterday that I disable Power Nap. If we can’t do that on Apple Silicon then I won’t be doing that. You’re right that the Jamf agent should detect a Mac in a sleep state and not run the policy. No one at Jamf mentioned this to me.


Anybody else annoyed by this behavior please upvote https://ideas.jamf.com/ideas/JPRO-I-1288

Anybody else annoyed by this behavior please upvote https://ideas.jamf.com/ideas/JPRO-I-1288


Thanks for posting the feature request. I voted it up. I was just about to submit a request about this. I meet up with a group of other Apple admins every month. We all vote on each other's feature requests. I will ask everyone to vote for this.

For the purpose of detecting Macs that are what I call "inactive", I created this extension attribute and used it to make a smart group of Macs to exclude from my install policies. We use Global Protect. If a Mac is in the office, Global Protect will not be active. An active Mac in our office will report that its current active network interface is "en"* and that it can access our internal servers. An active Mac located outside our office will report that its active network interface is "utun"* and that it can access our internal servers. An inactive Mac outside the office will always report that its current active interface is "en"* and that it cannot access our internal servers. These are the Macs that I want to exclude from my install policies. I have not yet accounted for inactive Macs that are in the office, but it's very unlikely that there will be any. My "checkAccess" variable uses awk and sed as if you are specifying the host name of a server. The parsing options may need to be modified if you use an IP address. I haven't tested this using one yet.


#!/bin/bash

:<<EXTENSION_ATTRIBUTE
-----------------------------------
Checks if a Mac is on the corporate LAN (onsite) or offsite based on which network interface is the
active interface and if the Mac has access to company internal resources. Network interfaces starting
with "en" indicate that a Mac is not connected to VPN (utun). To be considered onsite and active a
Mac must report an "en" interface and be able to access company internal resources. To be considered
offsite and active, the Mac must have an active VPN connection and be able to access company internal
resources. All other conditions are considered inactive. Replace "your.internal.server" in line 19 with
the hostname or IP of one your own servers or other internal resource.

4/29/2025 | Howie Canterbury
-----------------------------------
EXTENSION_ATTRIBUTE

checkIfActive() {
activeInterface=$(scutil --nwi | grep "Network interfaces:" | awk '{print $3}')
checkAccess=$(ping -c 1 your.internal.server | head -n 1 | awk '{print $3}' | sed 's/[():]//g')

if [[ "$activeInterface" == *"utun"* ]] && [[ -n "$checkAccess" ]]; then
status="Offsite-Active"
elif [[ "$activeInterface" == *"en"* ]] && [[ -n "$checkAccess" ]]; then
status="Onsite-Active"
else
status="Inactive"
fi
}

# Run network interface check
checkIfActive

# Report result
echo "<result>"$status"</result>"

  

I am happy to report that using a smart group that uses criteria from the above extension attribute to exclude Macs that are in an inactive state, I have had zero policy failures while rolling out the latest versions of CrowdStrike and Global Preotect. As these Macs become active and leave the smart group, they get the installs.

Reply


Terms & ConditionsCookie settings