Could not mount a distribution point

[brobertson]

We have been noticing lately in our environment that when trying to deploy packages via policies to systems, that for random systems the policy push will fail with the following error:

Error: Could not mount a distribution point.

Yet there will be systems that will get pushed the policy without error (again this seems to pop up randomly for systems).

This has occurred for updates we were trying to push out for the following:

- Office 2011 (such as update 14.3.7)
- Adobe Reader (such as update 11.0.04)

I looked at the logs for the systems that failed the push and it will do the following:

- Executing Policy (Name of Policy)
- Mounting (Mounting path)
- Error: Could not mount a distribution point

We are using JSS 8.62
The systems we are trying to deploy to are using the following:

Mac OS X 10.6.8 - Snow Leopard
Its a mixture of Mac Pro Desktops and MacBook Pro's with the latest system and java updates.
All systems are on our corporate network.

Please let me know if anyone has any ideas.

[nkalister]

I've seen 2 things cause this pretty commonly- network interruptions, like wifi dropping in the middle of the policy run. That'll often be coupled with the policy log being uploaded to the JSS after the fact- check the log for the line "The results of this Policy where not logged at the time of execution." And that's not my typo- the jamf binary does use the word 'where' in the log instead of 'were'! Or, if you're using afp or smb for your distribution points, the mac may already have the shares mounted from a previously interrupted policy run. Ssh onto a machine that failed and check the /Volumes directory to see if your DP's are sitting there mounted for no reason. If they are, unmount 'em and you should get a successful run.

[brobertson]

Currently we do not use Wi-Fi in this environment, just a standard wired connection.

We are not using AFP or SMB for distribution points (as far as I can tell since the option is not enabled under the policy that is being affected). I have noticed that a "CasperShare" is still mounted on a few of these machines, to which I will unmount them, then via the CASPER management site I will Flush the History for this Policy/Computer. The policy will run again but fail.

[bentoms]

We had this & "side stepped" it by moving to HTTPS.

[ImAMacGuy]

@bentoms - isn't that a lot slower?

[bentoms]

Yep. Well if you're counting, but is resumable.

Builds are via AFP/SMB, & we cache our updates including CS6 locally... So we don't see it really.