+7Started noticing this on machines for my enrollment script using jamfhelper.
Doesnt seem to have any real bearing on outcome as the text prompts still show up, but in the logs, most, if not all, jamfhelper prompts are followed by com.apple.fonts not accessible.
Excerpt from log with macOS Monterey with M1 pro
Log from M1 with macOS Big Sur
Any ideas why this is a thing?
+1I'm not sure of what exactly caused this but am seeing the same behaviour with Monterey endpoints.
getting same error on Intel/Monterey : can anyone help pls !
2392022-02-14 08:01:29.272 softwareupdate[6024:19909] XType: com.apple.fonts is not accessible.
2022-02-14 08:01:29.272 softwareupdate[6024:19909] XType: XTFontStaticRegistry is enabled.
+2I'm also seeing this output when i run the"softwareupdate --list" command:
Software Update Tool
Finding available software
2392022-02-14 08:01:29.272 softwareupdate[6024:19909] XType: com.apple.fonts is not accessible.
2022-02-14 08:01:29.272 softwareupdate[6024:19909] XType: XTFontStaticRegistry is enabled.
No new software available.
The weird thing is that i'm on Monterey 12.1 (Intel) so there are definitely software updates available but they are not being discovered.
Anyone else got any suggestions?
+1Im seeing this same errors with jamfHelper running after enrollment, not sure if the problem is because I'm running it in a VM, never had this problem before with other macOS so not sure what the problem is. If anyone has an idea please share.
+3@OrlandoS Based on a thread from the Munki GitHub, I don't think this issue is related to you working in a vm. Recent posts here: https://github.com/munki/munki/issues/1124, suggest that there's an issue with softwareupdate where it's hanging waiting for a response it never receives. As a result updates aren't being downloaded or devices that have updates are showing up as clean until an admin or technician actually goes to an endpoint and invokes softwareupdate manually. Like Jamf, Munki simply tries to use the softwareupdate binary to run OS updates, so it doesn't appear to be something specific to Munki deployments. The most recent posts in that thread indicate the bug is being worked out in the 12.3 release so we may see a fix here soon. Might also suggest updating to that beta on a test device and seeing if this behavior persists. I'm likely going to try the same.
(As a note I work with both Intel and Silicon based endpoints in my environment. Seeing issues across both platforms on macOS 12 releases. macOS 11 appears to behave as expected when using softwareupdate)
+2I've been continuing to test this on other 12.1 and 12.2 and the behaviour is the same. When I do a fresh build but don't enrol it in Jamf I don't get this error when I run the "softwareupdate --list" command but as soon as it's enrolled in Jamf the errors start.
I also tried excluding all of the build policies from my Mac and enrolling it manually to see if it was one of our policies that was causing it but even with no policies running the error persists. Also, un-enrolling the device from Jamf doesn't fix the issue which is odd.
The one good bit of news is that our users are still able to install software updates from system preferences even though the "softwareupdate --download -all" command doesn't work when you get this error. So if there is a fix in a later version on Monterey users should be able to manually upgrade to get it. It means we most likely won't be able to push/enforce it which won't be ideal though.
Anyone else made any progress with this?
+3I've been continuing to test this on other 12.1 and 12.2 and the behaviour is the same. When I do a fresh build but don't enrol it in Jamf I don't get this error when I run the "softwareupdate --list" command but as soon as it's enrolled in Jamf the errors start.
I also tried excluding all of the build policies from my Mac and enrolling it manually to see if it was one of our policies that was causing it but even with no policies running the error persists. Also, un-enrolling the device from Jamf doesn't fix the issue which is odd.
The one good bit of news is that our users are still able to install software updates from system preferences even though the "softwareupdate --download -all" command doesn't work when you get this error. So if there is a fix in a later version on Monterey users should be able to manually upgrade to get it. It means we most likely won't be able to push/enforce it which won't be ideal though.
Anyone else made any progress with this?
I've only started looking today, but I've found several open threads concerning this problem:
What I'm noticing is some discussion about secure tokens from the Apple Developer Forum threads. In one example someone was trying to load a Launch Daemon to have software updates install, but it also encountered a hung state that reads (to me) similarly to the symptoms mentioned in the MunkiTools thread. It seems like the connection between com.apple.fonts and Software Updates are the notifications presented to the user when the sequence is started and/or ready to restart. There are a lot of mentions of Secure Tokens being an issue, and while I didn't think of that at first, that seems as good a place as any to start. If I come up with anything on that front I'll share it here.
Hi all,
I am also seeing this problem on an AWS Mac EC2. I am currently using it as a build agent for GitHub Actions for CI/CD for iOS Mobile Apps, but running a build via xcodebuild CLI I get this issue (com.apple.fonts is not accessible). The Mac agent there is not enrolled in JAMF, but it is under a VM via AWS. Not entirely sure what's going on here.
+2Hi all,
I am also seeing this problem on an AWS Mac EC2. I am currently using it as a build agent for GitHub Actions for CI/CD for iOS Mobile Apps, but running a build via xcodebuild CLI I get this issue (com.apple.fonts is not accessible). The Mac agent there is not enrolled in JAMF, but it is under a VM via AWS. Not entirely sure what's going on here.
It looks like upgrading to macOS 12.3 didn't fix the issue unfortunately.
+2I did another test today where I excluded all policies from my computer so that all that happens during the DEP stage is that Jamf connect is installed and then no other policies are applied.
If I log in as a local administrator first and then run the “softwareupdate --list” command in terminal as a local administrator I don’t see the errors.
If I then log out as a local admin, log into the mac as a standard user, open terminal and change user to a localadmin and then run the “softwareupdate --list” command in terminal, the errors do appear.
If I then log out as the standard user and back in as a local admin and run the command again there are no errors. So it seems like the issue is triggered when the command/script runs as a local admin or root when a standard user is the logged in user.
The error lines in the output of “softwareupdate --list” don’t actually cause us an issue. The main issue is the command in the script which follows this which is run in a Jamf script: “softwareupdate --download --all”
When a standard user is logged into the Mac and this command is run by jamf, root or a localadmin in terminal the command doesn’t download anything and also never ends and this is what is breaking out workflow.
But just like the “softwareupdate --list” command, if I log into the mac as a local administrator and run “softwareupdate --download --all” in terminal it immediately starts the download of the available updates.
So it seems like the issue only occurs when a standard user is logged in even though the script is running from Jamf as root.
This test was done on an intel Mac with FileVault turned off so there shouldn't be any conflicts with secure tokens or ownership etc. I've got an apple care enterprise support ticket open for this so I'll keep you updated if I get a fix.
+2We are testing a workaround where the script in Jamf runs as root but the software update commands are actually run as the logged in user instead and we are having some success with this. It uses the "/bin/launchctl asuser" command to change users. It comes in handy for a few things.
Here is an example of the script we are using:
#!/bin/bash
# Get logged in username
LOGGEDINUSER=$(ls -l /dev/console | awk '/ / { print $3 }')
echo "$DATE LOGGEDINUSER = $LOGGEDINUSER"
# Get UID for LOGGEDINUSER
LoggedInUserUID=$(id -u "$LOGGEDINUSER")
echo "LoggedInUserUID = $LoggedInUserUID"
SoftwareUpdateList=$(/bin/launchctl asuser $LoggedInUserUID sudo -iu "$LOGGEDINUSER" softwareupdate --list)
echo "SoftwareUpdateList = $SoftwareUpdateList"
We also used jamfHelper in this workflow to display a splash screen before the Mac restarts to install the updates but as other people have mentioned, this issue seems to affect jamfHelper in Monterey Intel as well. If I run just the jamfHelper script in terminal it works but displays the 2 error lines related to fonts but if I run it in a jamf script it now fails so we're now using DEPNotify for the splash screen instead.
One other thing that people might run into it that the following command will fail if it is run by root and then executed by the logged in user because the "--restart" part requires root permissions. If you just remove the "--restart" part the updates stilll install and the Mac does actually restart anyway if a restart is required which is handy:
/bin/launchctl asuser $LoggedInUserUID sudo -iu "$LOGGEDINUSER" softwareupdate --install --all --restartIt definitely seems like something is still broken though, all of these commands should be able so successfully execute as root without throwing up the errors. We have done this for years in our environment without any issues. The good news is that if you make similar changes to this in your script, the script should still work even if they fix this issue.
If anyone else has any more info on this feel free to share.
+1Does anyone have these error messages on Monterey machines WITHOUT Xcode installed? So far, on all the Monterey machines without Xcode installed that I've tested do not have this error. Everyone tested with Xcode installed do have the error messages. I'm running out of computers to test.
+2I'm getting these errors on Macs with or without Xcode installed:
2392022-02-14 08:01:29.272 softwareupdate[6024:19909] XType: com.apple.fonts is not accessible.
2022-02-14 08:01:29.272 softwareupdate[6024:19909] XType: XTFontStaticRegistry is enabled.
+1I'm getting these errors on Macs with or without Xcode installed:
2392022-02-14 08:01:29.272 softwareupdate[6024:19909] XType: com.apple.fonts is not accessible.
2022-02-14 08:01:29.272 softwareupdate[6024:19909] XType: XTFontStaticRegistry is enabled.
Bummer. I thought I was onto something.
+9any update on this? I am starting to see it on Intel and M1 machines when trying to display a pop-up message via JAMF Helper
+1any update on this? I am starting to see it on Intel and M1 machines when trying to display a pop-up message via JAMF Helper
This is the problem I've been having and nothing has changed, waiting for an update from apple or jamf.
+2We've moved to using DEPNotify instead of jamfHelper for now for any full screen notifications and AppleScript dialog Jamf displayMessage popups for smaller popups. I still have my apple care enterprise incident opened and it has been escalated and they are doing an internal investigation. I suspect this might get fixed in a later version of macOS but I haven't heard anything back from them for a while. This usually means that they know there is a problem and don't have a fix yet in my experience but I might be wrong.
+4Hi all,
I am also seeing this problem on an AWS Mac EC2. I am currently using it as a build agent for GitHub Actions for CI/CD for iOS Mobile Apps, but running a build via xcodebuild CLI I get this issue (com.apple.fonts is not accessible). The Mac agent there is not enrolled in JAMF, but it is under a VM via AWS. Not entirely sure what's going on here.
Seeing this as well for us in our MacStadium box. Well one of the errors with our distributions workflows... does that cause the entire step to fail for you?
+6We're seeing the same issue when running the FV2 Key reissue script (https://github.com/jamf/FileVault2_Scripts)
I also believe it stops the users from actually changing the key. Has anybody else seen this behavior?
+1I was seeing this behavior, tried a few things, and I think this is what solved it: https://stackoverflow.com/questions/69986582/the-connection-to-service-named-com-apple-fonts-was-invalidated-on-xcodebuild-r/72116013#72116013
+6I was seeing this behavior, tried a few things, and I think this is what solved it: https://stackoverflow.com/questions/69986582/the-connection-to-service-named-com-apple-fonts-was-invalidated-on-xcodebuild-r/72116013#72116013
How did you scale it to deployed macs? pushed the new cert to all macs?
+5I was seeing this behavior, tried a few things, and I think this is what solved it: https://stackoverflow.com/questions/69986582/the-connection-to-service-named-com-apple-fonts-was-invalidated-on-xcodebuild-r/72116013#72116013
This worked for me too!!! Thank you for the suggestion.
The thing that I think finally solved it was installing the correct "Apple Worldwide Developer Relations Certification Authority" in Keychain. The one I had had an expiration date of February 2023. I deleted that one and went here: https://www.apple.com/certificateauthority/, downloaded the one called "Worldwide Developer Relations - G3 (Expiring 02/20/2030 00:00:00 UTC)", then retried the build and it worked.
+4How did you scale it to deployed macs? pushed the new cert to all macs?
Did you find a solution to the FV2 Key reissue script?
+1We're seeing the same issue when running the FV2 Key reissue script (https://github.com/jamf/FileVault2_Scripts)
I also believe it stops the users from actually changing the key. Has anybody else seen this behavior?
I am also seeing this behavior. I haven't been able to verify if the affected users have the Apple Worldwide Developer Relations Certification Authority" certificate in Keychain. It's not ideal, but I was able to fix a handful of users by excluding them from our forced FileVault Configuration Profile, then have them disable FileVault. I add the Configuration Profile back to their computer in Jamf and have them restart. FileVault is enabled and Jamf recognizes the personal recovery key. I will report back if replacing the cert fixes the issue.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.