Munki Client (v6.6.5.4711) Failing to Create/Update InstalledProductInfo.plist on macOS - No Inventory Sync

20 views
Skip to first unread message

Vladyslav Semenov

unread,
Jul 16, 2025, 6:02:36 AMJul 16
to munki-discuss

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:

  1. Incorrect Status Display: Applications (e.g., Figma, YubiKey Manager) that are installed either via Munki or manually, consistently show incorrect statuses in MSC.

  2. 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.

  3. 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):

  1. 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.

  2. Munki Component Verification:

    VladyslavSemenov@vsemenov-MacBook-Pro ~ % ls -l /Applications/Managed\ Software\ Center.app ls -l /usr/local/munki/managedsoftwareupdate ls -ld /Library/Managed\ Installs/ total 0 drwxr-xr-x@ 10 root admin 320 Feb 11 17:48 Contents -rwxr-xr-x 1 root wheel 138896 Feb 11 17:48 /usr/local/munki/managedsoftwareupdate drwxr-xr-x@ 14 root admin 448 Jul 15 18:22 /Library/Managed Installs/
    • 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).

  3. Python Environment Check:

    VladyslavSemenov@vsemenov-MacBook-Pro ~ % /usr/bin/python3 --version Python 3.9.6
    • Observation: Python 3 is present and functioning.

  4. 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:

      VladyslavSemenov@vsemenov-MacBook-Pro /Library % curl -v http://10.%correct IP%/munki_repo/catalogs/production * Trying 10.%correct IP%:80... * Connected to 10.%correct IP% (10.%correct IP%) port 80 > GET /munki_repo/catalogs/production HTTP/1.1 ... (HTTP/1.1 200 OK, full XML content) ...
    • Observation: Network access, server configuration, and catalog validity are confirmed working.

  5. Test for Write Permissions in /Library/Managed Installs/:

    VladyslavSemenov@vsemenov-MacBook-Pro /Library % sudo touch /Library/Managed\ Installs/TEST_FILE_FOR_MUNKI_PERMS.plist VladyslavSemenov@vsemenov-MacBook-Pro /Library % ls -l /Library/Managed\ Installs/TEST_FILE_FOR_MUNKI_PERMS.plist -rw-r--r-- 1 root admin 0 Jul 15 21:07 /Library/Managed Installs/TEST_FILE_FOR_MUNKI_PERMS.plist
    • Observation: root user can successfully create files within /Library/Managed Installs/. This rules out fundamental directory permission issues.

  6. 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:

      Managed Software Update Tool Version 6.6.5.4711 Copyright 2010-2025 The Munki Project https://github.com/munki/munki Starting... Nothing to install or remove. Finishing... Done.
    • 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.

      VladyslavSemenov@vsemenov-MacBook-Pro /Library % sudo cat /Library/Managed\ Installs/InstalledProductInfo.plist | less cat: /Library/Managed Installs/InstalledProductInfo.plist: No such file or directory (END)
    • 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.

  1. 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?

  2. 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?

  3. 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,

Gregory Neagle

unread,
Jul 16, 2025, 11:36:27 AMJul 16
to munki-...@googlegroups.com
Hi!  There is no “Munki Project Support Team”. This is an open source project and all “support” is just developers and admins helping each other out the best we can.

It’s clear you are experiencing a problem, and it looks like you’ve done a fair amount of investigation around it, but I’m a bit confused.

Munki does not generate or use a "/Library/Managed Installs/InstalledProductInfo.plist” file at all. I’m not sure where you got the impression that it did.
It does generate a "/Library/Managed Installs/ApplicationInventory.plist” file — but that is not actually consulted by Munki at all: it’s more of a report that can be used elsewhere.

Munki does not rely on saving the results of an application inventory scan to determine or display the installation status of software. Remember that “software” doesn’t have to be an _app_.

Munki does not use the Python at /usr/bin/python3. It has its own Python, called from /usr/local/munki/munki-python

To better figure out what’s actually happening on your machines, I’d start with reading https://github.com/munki/munki/wiki/How-Munki-Decides-What-Needs-To-Be-Installed and start looking at the output of a `sudo managedsoftwareupdate -vvv` run.

If you can share relevant parts of such a run, we may be able to offer additional help.

-Greg

--
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.

Reply all
Reply to author
Forward
0 new messages