All clients fail to mount distribution point; must destroy Kerberos ticket after any successful install

[powellbc]

This morning I was alerted to an issue where the first install from Self Service works fine, but all ensuing attempts t install software are met with the "Unable to mount distribution point" error. The only workaround I have found is to manually force an unmount (umount -f /Volumes/Share) followed by destroying the Kerberos ticket (kdestroy -a).

Other details
- DP Server is Windows Server 2012 R2 with an SMB share.
- JSS is 9.81
- All affected clients are 10.11, though other version may be affected (I am in the process of verifying this)

Anyone else see this occurring? It seems to have started today, and no reports of issues with El Cap clients have appeared before today.

[rlandgraf]

Had a similar issue here, where we could install one package and then all subsequent installs would fail. The original fix was to have users reboot between installs and this seemed to clear whatever was stuck. Of course this was not a good answer so what we ended up doing was changing the the Server setting in our JSS for distribution points to the ip address instead of the host name and for some reason this fixed the problem for us. Still not sure why it worked but for now it was the only thing we could do to get it to work.

[were_wulff]

Hey all,

We’re aware of this issue, and have it filed under D-009351.

The workaround we have is a variant of what you’ve been doing: add a sleep 10; kdestroy -a to policies so it happens automatically instead of you having to run it manually after each policy.

We haven’t fully tested changing the distribution point’s hostname to the IP address, but if that is working, great! Keep it in place if it’s been working as expected with the IP.

If you haven’t already got a case going and would like to get one going and attached to D-009351, please get in touch with your Technical Account Manager by giving them a call, sending an e-mail to support@jamfsoftware.com, or by using the My Support section of JAMF Nation.

Thanks!
Amanda Wulff
JAMF Software Support

[powellbc]

@amanda.wulff Is this issue 10.11.x specific as it appears? It is unexpected that it appeared out of the blue as we have had 10.11 machines in our environment since release and the issue only seems to have cropped up now.

The script based workaround for us is probably untenable as we have north of 1000 policies; not all require mounting the DP but you get the idea.

@rlandgraf Did you change the FQDN to the IP for this specific 10.11 issue?

[were_wulff]

Hey @powellbc,

This particular issue has been around for a couple of versions of the JSS that predate 10.11.x, so it may just be coincidental that you're noticing it now on your 10.11.x devices.

It's one of those issues that we don't always see in an environment and, when we do, it doesn't necessarily affect every machine (regardless of the OS version). I know, the most fun and best kind to try and nail down. :)

Sometimes we've even found that it has been going on, but users who encountered it via Self Service haven't reported anything and just tried again later, and when 'later' happened to be after the kerberos ticket was destroyed, it worked.

Have you had a chance to check and see if any other devices are running into it?

The sleep 10; kdestroy -a wouldn't need to be added to every single policy, just to the policies that need to mount the SMB share to run; we have had reports that it Self Service will still report a false failure with that in place, even if the policy runs successfully, but it does seem to work.
It can be added in the Files and Processes payload of a policy under Execute Command.

That may be worth testing out on a small handful of policies to see if it helps with the issue.

If you haven't yet got a case open with your TAM, I'd recommend doing so just so we can get everything logged and documented.

Thanks!
Amanda Wulff
JAMF Software Support

[Josh_Smith]

@powellbc We've stayed at 9.63 because we've seen this bug in every version since then (although the defect number has changed).

I believe switching from a domain service account to a local account will work around it...but that wasn't an option for me. I've been setting up HTTP DPs to get around having to mount the DP. I've been told there is a fix in for this bug in the next release but we'll have to wait and see.

[powellbc]

@amanda.wulff I am logging a ticket momentarily.

I was not able to replicate the issue on 10.10, but could consistently on 10.11 initially. A recently imaged 10.11 machine is not exhibiting the issue. So, as you said, it's a fun one.

[Matt_Ellis]

@amanda.wulff Would this issue also appear if the shares where running off AFP and not smb? Im getting a ton of unable to mount distribution point" error's. but all my stuff running using AFP connections.

[were_wulff]

@Matt.Ellis

I haven't seen that personally, but there is a note on D-009351 that mentions it has been seen at least once with AFP shares.

However, since that seems to be an uncommon cause, it would be best to get a case opened with your Technical Account Manager to rule out anything else that might be causing the behavior you're seeing with the AFP shares.

"Could not mount distribution point" is a pretty generalized error and can have numerous underlying causes, so it'd be best to dig into it a bit further and find out what the underlying error/cause is; it's very possible it's something entirely different from D-009351.

Thanks!
Amanda Wulff
JAMF Software Support

[bentoms]

@powellbc Tried HTTP DP's?

[AVmcclint]

I, for one, would love to switch to http distribution to solve this problem but doing so would require setting up IIS and an act of congress.

[powellbc]

@bentoms It is in the cards, on an accelerated timetable now.

[mark_mahabir]

Sorry to regurgitate an old thread, but we still run an SMB DP and first saw this issue in JSS v9.73, so added 'sleep 10; kdestroy -a' to all our policies as a workaround as recommended by our TAM.

We're now running JSS v9.93, can anyone confirm this issue went away? We have 10.10, 10.11 and 10.12 systems enrolled.

[powellbc]

@mark.mahabir We never migrated to an HTTP DP. FWIW we have not encountered this issue in a while. Not sure that counts as "fixed" though.