Jamf pro 10.47.0 Policies failing from self service unable to mount smb distro share

[N2KHL]

Hi

We have upgraded our on prem Jamf from 10.42.1 to 10.47.0

On testing policies all download as they should to devices but when using self service suddenly the machines cannot mount the smb distribution point.  

We have also enabled HSTS as per the upgrade docs and incrementally upgraded to 10.46.1 first before 10.46.0

This was all working fine in 10.42.1 and now not working on 10.47.0

Has anyone else had this issue?

Nik

[sdagley]

@N2KHL We're no longer on-prem, and don't use SMB for DP connectivity, so I can't confirm the behavior you describe in 10.47.0, but as a possible workaround do you have the option to enable HTTPS for your DP? You'll find that HTTPS provides a much more robust performance than SMB for a DP (e.g. faster downloads because the Mac doesn't have to mount the DP file system to initiate a download, and resumable downloads)

[dlondon]

Not at 10.47.0 yet for another week.  However, here's the way I would test.

1) Can you mount the smb share from the machine with the same credentials that jamf uses?
2) If you can't, can you mount the share with other credentials?
3) If the answer is no for both, then is there a firewall in the way?  Maybe it's had a config change. 
4) Can you mount the share from anywhere?  If not, then maybe the share is the issue.
5) On the machine you can look at the jamf log in /var/log/jamf.log  during or after the policy run.  I see more info there than on the server in the policy log.  I feel like I had a lot of failover to cloud DP last week but that's because of a firewall issue.
6) If there's nothing of use in Jamf Nation ... put a ticket in and tell them what you tested and what you see

[jules1987]

Same issue here, on-prem install. I am working on getting HTTPS to run instead.

[pardoed]

Yeah we have the same issue on our on-prem server since upgrading to 10.47, installs work fine when the policy is triggered manually via the terminal, but not via the Self Service app, just flat out refuses to mount the on site DP's. Tried re-installing Self Service, giving Self Service full disk access via system settings and even attempted to re-enroll our test mac, but still no luck. Other scripts work fine though, its literally just when its attempting to mount the SMB DP's.

[N2KHL]

What version of Jamf were you upgrading from?  I am interested to find out as to what version was still working as I am planning to roll back while we find time to test.

[pardoed]

We were on 10.46.1 and it worked fine, so looks like its just isolated to the new version at the moment.

[jules1987]

I just finished setting up HTTPS with the guide below. JamfSelfService worked like charm right after setting our firewall up to allow tcp443.

https://learn.jamf.com/bundle/technical-articles/page/Using_IIS_to_Enable_HTTPS_Downloads_on_a_Windo...

JamfAdmin still seems to work fine using SMB.

Good luck getting yours fixed soon!

[charliwest]

Maybe or maybe not related, but if you went straight from 42 to 47 you missed some steps, https://learn.jamf.com/bundle/technical-articles/page/Incremental_Upgrade_Scenarios_for_Jamf_Pro_10-...

[pardoed]

Just a heads up everyone, just notice this is also affecting the Patch Management system, just gone to push out this weeks Outlook update and it has comeback with the same error, unable to mount DP. Manual policies via terminal and recurring check-in are working fine though.

[c_kay]

So Jamf Support have told me this issue won't be fixed in 10.48 now in beta and we'll have to wait for 10.49.

I find that totally unacceptable! To have to wait 2 further releases for a bug Jamf introduced.

[def]

Same problem here, updated to 10.47 from 10.46.1... also upgraded mysql from 8.0.30 to 8.0.33. So sad this wont be fixed until 10.49 !!!! Any expereince with AFP shares in conjunction with this bug? 

[sdagley]

@def (and anyone else who hasn't switched to https delivery for on-prem DPs) You really should take a look at enabling https for your DPs. It will improve the speed of installs because there is no longer a need to mount the file system of the DP to begin downloading an installer, and for larger installers the resumable download capability will help insure that installs successfully complete on the first try.

[jules1987]

Yup, I 2nd that. I wish I would have done it years ago 🤔

[dcappelle]

I use a share drive on our local SAN that uses SMB. This completely broke self service for me, as any on prem devices will prefer to use it instead of the Cloud Distribution point.

I would like to avoid spinning up a server for this...

[sdagley]

@dcappelle Disabling your on-prem SMB DP and relying on the Cloud DP until Jamf releases a fix for SMB DPs is your only option other than enabling https access for your on-prem DP. I'd _really_ recommend the latter, but the former will at least restore Self Service install functionality.

[dcappelle]

The only issue with that is uploading large files to the Cloud DP.. 
That's why I use the local SAN, because it can handle 100 computer downloading a 40GB package. 

[sdagley]

Then you most definitely should enable https on your local DP because it will support resumable downloads if there's a hiccup on that 40GB package download. And what in the blazes is in that package?

[dcappelle]

The entire Adobe Creative Cloud with Language Packages and Maxon.

[sdagley]

Not that I have a clue why you would want to install the entire CC suite at once, but is there any possibility you could go with a more modular approach instead of a monolithic install? For CC deployments for my org we just install CC Desktop and allow users to install the tools they're licensed for as needed. (yes, I do consider myself lucky on that)

[dcappelle]

Because, these machines are used in Labs, Can't have a class of students trying to download the apps they need to use the Suite. Just doesn't make sense for that.
I do have self service packages with Adobe CCDA for our Employees and remote students, but on campus ones are more generally used.

[sdagley]

Yep, definitely see why you'd want a monolithic install in that situation. Not to keep beating the same horse, but given that @c_kay reports they were told the fix won't come until JSS 10.49 which is probably 2-3 months away at best, you're kind of forced to set up https on your DP.

[dcappelle]

Yeah, I got an emergency change in place, got the server created, created the HTTPS share, however the Distribution page within Jamf Pro is broken and I can't save a new distribution or edit an existing one. Anyone else have this issue?

[sdagley]

Are you using SSO for access to your Jamf Pro console? I believe there was a post indicating problems accessing the DP configuration page when using SSO. I'm not sure if there's an "in case of emergency" mechanism to access your JSS console and bypass SSO (we're not using it) but if there is try that to access the DP configuration page.

[sdagley]

@dcappelle Out of curiosity if you set up a policy to install Adobe CC that's triggered only by a Custom Event, and then have a Self Service policy that triggers that install policy by doing a "jamf policy -event CustomEventName" via a Files & Processes payload does that work?

If that doesn't work you could have your Self Service policy create a hidden flag file on a Mac, use an Extension Attribute to put Macs with that hidden file into a Smart Group, and then use that Smart Group as the scope of a policy to install Adobe CC on checkin. That _should_ work around the problem of Self Service installs not working although the actual install start will be deferred until the Mac does it's next checkin.

[martyuiop1]

FYI this is PI111961 "Jamf Self Service fails to install packages over SMB."
Another workaround as this doesn't affect using the jamf binary to call policies is to give your policy a custom trigger  then create a second policy with a one liner "Execute Command" in files and processes payload of "jamf policy -event YOURTRIGGERWORD" and that will then execute. I appreciate for large amounts of policies thats not ideal, but for jamfcloud i would suggest use cloudDP for the bulk and then just use the above workaround for the ones > 20GB
Hope this helps someone

[angryant]

We have this issue PI111961. We are now trying to setup HTTPS but now we can't edit the file share distribution points, we get an access denied anyone else seen that?

[glpi-ios]

We have the same issue. We can't edit or delete anymore, "Access Denied"

Jamf Pro (Cloud) 10.46.1

[angryant]

This is a seperate issue confirmed by JAMF.  We are waiting for it to be fixed.

PI111439 If single sign-on is enabled in Jamf Pro, the File share distribution points setting is incorrectly inaccessible. Workaround: Temporarily disable single sign-on to access the file share distribution points setting.

[glpi-ios]

Thank you for your help

[James_von]

Just upgraded my dev enviroment (im glade I have been holding off) and SMB shares are broke, i went to delete it. It wouldnt let me. I did an API command to delete it. And now whenever i try to add the SMB/HTTP share, it just spins and spins and spins..

It's a little disappointing to still see issues still and it not being fixed... Is this an attempt to convert some of us over to Jamf Cloud? Com'on Jamf, lets get this solved.

[dcappelle]

With the spinning and not loading, like others have said, temporarily disable SSO.

[Maclife]

this is still not fixed with mounting smb share for example in patch management when will this be fixed. It was said it will be in 10.49 now with 10.50 still not fixed