Error: Package not successfully downloaded: 33

ItsMe_Sean
Contributor

Hi guys

Getting this error when trying to install a certain package from the self service application.

This is the part of the log where the error occurs;

/usr/sbin/jamf is version 8.63 Executing Policy Install PolicyName... [STEP 1 of 4] Downloading http://casper.mycompany.com:80/CasperShare/Packages//PackageName.dmg... Error: Package not successfully downloaded: 33

I have browsed the forums and cannot find any posts with any helpful information. The rest of the policy downloads fine and executes properly. Other packages execute fine over http. This install policy also works fine when running on my dev machine.

Anyone offer any help?
Thanks in advance

3 ACCEPTED SOLUTIONS

jarednichols
Honored Contributor

Well, curl refers error 33 (not sure if that's what's being returned here) as a server that doesn't support byte ranges. I think this has something to do with resumable downloads. You may want to have a look in the /Library/Application Support/JAMF/Downloads folder and see if there's a partial download there that you can clear out.

View solution in original post

ItsMe_Sean
Contributor
Posted Today at 3:11 PM by andyparkernz We're seeing similar errors with HTTP downloads, and if we look at that Downloads folder we find partial downloads. Clearing them out solves the problem. Is there a jamf verb to delete these out? We though that jamf flushCaches might do the trick, but it seems not.

Hi Andy

I've found that just running the following from terminal or write it into a shell script file and bundle it into a casper policy works wonders.

This will delete everything in the JAMF Downloads folder, but leave the folder intact.

#!/bin/sh rm -rf /Library/Application Support/JAMF/Downloads/*.* exit 0

Edit; updated script command.

View solution in original post

matambanadzo
New Contributor II

Thanks Sean for the script.
We were also getting the 33 error and found there were temp files in JAMF folder.

One small typo about the script as it didn't work when I ran it.

rm -rf /Library/Application Support/JAMF/Downloads/.*
(changed on the end, should be *.
)

View solution in original post

5 REPLIES 5

jarednichols
Honored Contributor

Well, curl refers error 33 (not sure if that's what's being returned here) as a server that doesn't support byte ranges. I think this has something to do with resumable downloads. You may want to have a look in the /Library/Application Support/JAMF/Downloads folder and see if there's a partial download there that you can clear out.

ItsMe_Sean
Contributor

Thanks Jared

I managed to, finally, get around to getting access to the clients machine and to no surprise sitting there was the incomplete download for the policy. Deleted and it's now working!

andyparkernz
New Contributor III

We're seeing similar errors with HTTP downloads, and if we look at that Downloads folder we find partial downloads. Clearing them out solves the problem.

Is there a jamf verb to delete these out? We though that jamf flushCaches might do the trick, but it seems not.

ItsMe_Sean
Contributor
Posted Today at 3:11 PM by andyparkernz We're seeing similar errors with HTTP downloads, and if we look at that Downloads folder we find partial downloads. Clearing them out solves the problem. Is there a jamf verb to delete these out? We though that jamf flushCaches might do the trick, but it seems not.

Hi Andy

I've found that just running the following from terminal or write it into a shell script file and bundle it into a casper policy works wonders.

This will delete everything in the JAMF Downloads folder, but leave the folder intact.

#!/bin/sh rm -rf /Library/Application Support/JAMF/Downloads/*.* exit 0

Edit; updated script command.

matambanadzo
New Contributor II

Thanks Sean for the script.
We were also getting the 33 error and found there were temp files in JAMF folder.

One small typo about the script as it didn't work when I ran it.

rm -rf /Library/Application Support/JAMF/Downloads/.*
(changed on the end, should be *.
)