Skip to main content

For the past week we've seen an increased frequency of "Could not mount distribution point" errors in our Jamf Pro policy log notifications.

We tried reaching out to Jamf support but this was unsuccessful as they are in the middle of migrating support to a new platform and no human response is available for my query at this time.

Can anyone suggest where we might find more details about why the distribution point could not be mounted? The policy log on the Jamf Pro web interface does not have any further detail.

Our Jamf Pro instance is version 10.35.0, on-premise. Our client Macs are on macOS 10.15.7 Catalina. Our distribution point is an SMB share on a Windows Server, we checked it was still shared and that the file and folder permissions were still set correctly. We checked that the service accounts used to read and write the distribution point are still correct and not expired or disabled. The computers raising the error are not off-site (they are mostly fixed desktop iMacs).

@DanJ_LRSFC You could try to see if manually running a policy with the -verbose flag offers any more info (e.g. sudo jamf policy -verbose -event <PolicyTriggerHere>)

I'd also highly recommend, if it's at all possible, that you adopt HTTPS for your DP because it's a much more performant mechanism - no mounting the file system before downloading packages as with SMB, and interrupted downloads can be resumed unlike with SMB.

@sdagley is there a guide anywhere how to set up HTTPS for a distribution point on Windows Server? I'm assuming it would use IIS but I'd need to know some details like what needs to be mapped to what virtual directory or whatever.

@sdagley is there a guide anywhere how to set up HTTPS for a distribution point on Windows Server? I'm assuming it would use IIS but I'd need to know some details like what needs to be mapped to what virtual directory or whatever.


@DanJ_LRSFC I've only used RHEL for https DPs, so no personal recommendations for setup guidance on Windows Server, but this looks like it covers it: https://docs.jamf.com/technical-articles/Using_IIS_to_Enable_HTTPS_Downloads_on_a_Windows_Server_2016_or_2019_File_Share_Distribution_Point.html

(And kudos to the Jamf documentation department for publishing that guide, and many new ones now available on https://docs.jamf.com/technical-articles/Welcome.html )

@DanJ_LRSFC I've only used RHEL for https DPs, so no personal recommendations for setup guidance on Windows Server, but this looks like it covers it: https://docs.jamf.com/technical-articles/Using_IIS_to_Enable_HTTPS_Downloads_on_a_Windows_Server_2016_or_2019_File_Share_Distribution_Point.html

(And kudos to the Jamf documentation department for publishing that guide, and many new ones now available on https://docs.jamf.com/technical-articles/Welcome.html )


Jamf Support finally got in touch and this was indeed the guide they recommended.

I guess SMB shares are no longer supported, then?

Jamf Support finally got in touch and this was indeed the guide they recommended.

I guess SMB shares are no longer supported, then?


@DanJ_LRSFC AFAIK SMB shares are still supported, but my opinion is they should be avoided whenever possible. HTTPS offers much faster download start because it doesn't incur the overhead of mounting a file system, supports resumable downloads, and if you were running an on-prem install and wanted an externally facing DP your Security group wouldn't laugh you out of the room if you told them you wanted to use an SMB server for that DP. There used to be a really annoying behavior with SMB DPs that Jamf did not fix until early 2017 where a package would be downloaded twice - once to calculate the checksum, then again for the install. HTTPS downloads never had that problem.

Terms & ConditionsCookie settings