Error mounting the file share distribution point via xpc.

[dlondon]

I'm seeing an issue with our managed mac's accessing the SMB Distribution Point on premises

In the testing, if I watch the local /var/log/jamf.log file on the Mac's I get a sequence like this

Fri Jun 27 11:27:23 dep54592 jamf[96991]: Checking for policy ID 4687...
Fri Jun 27 11:27:24 dep54592 jamf[96991]: Executing Policy SPSS 29.0.2
Fri Jun 27 11:27:35 dep54592 jamf[96991]: Error Domain=com.jamfsoftware.core.errors Code=1 "Error mounting the file share distribution point via xpc." UserInfo={NSLocalizedDescription=Error mounting the file share distribution point via xpc.}
Fri Jun 27 11:27:35 dep54592 jamf[96991]: Retrying using distribution point Cloud Distribution Point...
Fri Jun 27 11:27:36 dep54592 jamf[97095]: Mounted file server
Fri Jun 27 11:27:47 dep54592 jamf[96991]: Verifying package integrity...
Fri Jun 27 11:29:04 dep54592 jamf[96991]: Installing SPSSSC_29.0.2_Mac.pkg...
Fri Jun 27 11:29:55 dep54592 jamf[96991]: Successfully installed SPSSSC_29.0.2_Mac.pkg.

However I can manually mount the share using the service account via Finder and also the Jamf client itself i.e. jamf mount ....

Has anyone seen this sort of thing before? It was working as late as last Thursday which is a clue if only I could understand what has been changed that allows Finder and Jamf Client to work but not Jamf when it does the mount to install

[sdagley]

I don't have anything to suggest regarding the XPC error, but I did want to ask if there's a reason that you're not using HTTPS for the DP? Since downloading from a DP via HTTPS doesn't involve mounting the file system as with SMB it imposes less overhead, and while it's not necessarily an issue for you since you have a Cloud DP for failover using HTTPS for an on-prem DP supports automatic re-try on download errors unlike a straight fail with SMB DPs that don't have a failover DP. It used to be that downloading from SMB DPs resulted in all packages being downloaded twice unless using the Cache option, but Jamf fixed that in 2017.

[dlondon]

Hi @sdagley I did think about a https DP - maybe a good thing to take to the boss seeing as how the DP is not altogether reliable.  The SMB DP does get mounted but is already considered to have failed by Jamf and so it does the install from cloud

[howie_isaacks]

I had a similar issue back before I switched to using AWS for distribution points. Switching to HTTPS worked much better. At the time I was running two on-prem Jamf Pro servers. By the time I was running 8 servers I had switched to AWS. The download speeds were always 400-600Mb/s or above and very reliable. One other point to make about using SMB is that it will have issues with computers not on the same local network. Many ISPs block SMB.

[dlondon]

Thanks @howie_isaacks  When we moved to Cloud, the nearest AWS was about 3000km away which created problems.  When we moved to cloud I tried just using the Cloud DP but it didn't work well enough with us so far.  So, I left the original SMB DP in place and for machines on site, I have them use that.  Anyone off site uses the Cloud DP.  It looks like these days there is an AWS presence here.  I would prefer to use the on premises storage to reduce traffic if at all possible.

[sdagley]

I could have sworn that once upon a time I'd read something which mentioned JCDS utilized, or could utilize, AWS CloudFront as a CDN but darn if I can find anything mentioning that now...

[howie_isaacks]

They do use AWS. I saw this while I was troubleshooting package download failures during policy runs. My packet traces showed the URLs being accessed. It turns out there was no issue. The policy failures were the result of the Macs being in a sleep state so the packages weren't downloading when the policies ran at check-in. I have since excluded Macs in this "inactive" state from running policies at check-in.