Dear Munki Project Support Team,
We are experiencing a critical issue with the Munki client (version 6.6.5.4711) on macOS where it consistently fails to create or update its InstalledProductInfo.plist file, located at /Library/Managed Installs/InstalledProductInfo.plist. This issue occurs even on freshly installed macOS systems, indicating a potential deeper problem beyond typical configuration errors or local system corruption.
Problem Description:
The core of the problem is that InstalledProductInfo.plist is always absent or empty, which prevents Managed Software Center (MSC) from displaying accurate application statuses ("Installed" vs. "Available"). Consequently:
Incorrect Status Display: Applications (e.g., Figma, YubiKey Manager) that are installed either via Munki or manually, consistently show incorrect statuses in MSC.
Manual GUI Interaction Required: After manually uninstalling an application, its status in MSC only updates if we manually initiate a "Check for Updates" in MSC and then cancel the subsequent download/install process. This suggests that the core check logic functions, but the final inventory save fails during automatic or --checkonly runs.
Repetitive Downloads: Munki repeatedly downloads installer packages because it cannot correctly track their installed state.
Detailed Diagnostics and Observations (Performed on freshly installed macOS test devices):
Munki Client Installation: Munki client (v6.6.5.4711) is installed via JumpCloud MDM's "Software Management" feature. The installation appears successful; Managed Software Center.app and managedsoftwareupdate binaries are present.
Munki Component Verification:
Observation: All Munki components exist, managedsoftwareupdate is a valid universal Mach-O binary, and permissions/ownership for essential directories (/Library/Managed Installs/) are standard (root:admin or root:wheel and drwxr-xr-x).
Python Environment Check:
Observation: Python 3 is present and functioning.
Munki Repository Accessibility & Configuration:
Munki repo URL in /Library/Preferences/ManagedInstalls.plist is http://10.%correct IP%/munki_repo (verified correct).
The Munki server is fully accessible from the client, and the production catalog (http://10.%correct IP%/munki_repo/catalogs/production) is successfully retrieved by curl:
Observation: Network access, server configuration, and catalog validity are confirmed working.
Test for Write Permissions in /Library/Managed Installs/:
Observation: root user can successfully create files within /Library/Managed Installs/. This rules out fundamental directory permission issues.
managedsoftwareupdate Execution & Logging:
Running sudo /usr/local/munki/managedsoftwareupdate --installonly --verbose > ~/Desktop/munki_install_attempt_log.txt 2>&1 completes without visible errors and creates ~/Desktop/munki_install_attempt_log.txt with content:
CRITICAL OBSERVATION: Despite a successful run of managedsoftwareupdate and the "Finishing... Done." message (which typically implies Saving application inventory... occurred), the file /Library/Managed Installs/InstalledProductInfo.plist is NEVER created or updated.
Similarly, /Library/Managed Installs/Logs/ManagedSoftwareUpdate.log also remains empty, indicating that Munki's internal logging mechanism for its detailed process, including the inventory save, is not functioning or is silently failing.
Request for Assistance:
The core problem appears to be a silent failure of managedsoftwareupdate to create/write to InstalledProductInfo.plist, despite all superficial checks passing. This occurs on a freshly installed macOS, ruling out many common local conflicts.
Is there any known bug or specific interaction in Munki v6.6.5.4711 (or related Python/macOS frameworks) that would cause InstalledProductInfo.plist not to be created, even when managedsoftwareupdate reports a successful run?
Are there any extremely low-level debugging techniques or defaults write settings we can enable to force more verbose output during the Saving application inventory... phase, even if it's before standard log initiation?
Could there be a subtle permission or ACL issue that affects only plist-writing by specific system processes, even when sudo touch works? (e.g., related to App Sandbox, TCC, or other macOS security features that interact uniquely with system plists).
We are seeking guidance on this persistent inventory saving failure, as it prevents Munki from functioning correctly.
Thank you,
--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/munki-discuss/230ac49d-b077-4dd6-8f31-60a78e99bba5n%40googlegroups.com.