kDrive installer fails in Munki deployments when previous version is present

[loicpipoz]

Note: Please write your issue only in english

Description
When deploying kDrive via Munki (managed macOS software deployment), the official kDrive-3.7.9.1.pkg fails to install if a previous kDrive installation is present.
The package expects the user to manually run /Applications/kDrive/kDrive Uninstaller.app before reinstalling, which is not possible in an unattended, non-admin managed environment. As a result, the pkg install fails with exit code 1.

Steps to reproduce
Steps to reproduce the behavior:

1. Install any existing version of kDrive on a macOS machine.
2. Deploy kDrive-3.7.9.1.pkg via Munki (or run installer -pkg kDrive-3.7.9.1.pkg -target / as root) while kDrive is still installed.
3. Let Munki/macOS installer run non-interactively (no user session / standard user, no admin rights to run the GUI uninstaller).
4. See the installation fail.

Expected behavior
The official kDrive pkg should be able to upgrade an existing installation in a non-interactive way, without requiring a manual GUI uninstall by the end-user.

Ideally, the pkg should:

• Either support installing over an existing kDrive installation, or
• Include a preinstall script that silently uninstalls the previous kDrive installation before the new version is installed in postinstall.

This would make kDrive compatible with standard macOS software deployment tools (Munki, Jamf, etc.) in managed environments.

Screenshots
Not applicable; the issue is visible in the installer/Munki logs.

Logs
Example Munki / installer output:

Dec 05 2025 09:17:48 +0100     Install of kDrive-3.7.9.1.pkg failed with return code 1
Dec 05 2025 09:17:48 +0100 ERROR: ------------------------------------------------------------------------------
Dec 05 2025 09:17:48 +0100 ERROR: installer: Error - Veuillez le désinstaller avant de l'installer de nouveau
Dec 05 2025 09:17:48 +0100 ERROR: ------------------------------------------------------------------------------

[loicpipoz]

In the meantime, here is a Munki-friendly Bash script that adapts the official macOS uninstaller logic from DialogController.swift. It can be used as both a preinstall_script and uninstall_script (via the REMOVE_CONFIG flag) to reliably remove kDrive in managed environments until an official fix is provided.

kdrive_munki_uninstall_common.sh

[ChristopheLarchier]

Is your goal to deploy the kDrive app across a fleet of macOS machines?
If so, would you like to block automatic updates?
Warning: Uninstalling/installing the app will delete the existing configuration; it is not an update.

[loicpipoz]

Hi @ChristopheLarchier,

Yes, my goal is to deploy kDrive across a fleet of managed macOS machines.
Deployment is handled by AutoPkg + Munki, and end-users are standard (non-admin) users.

In this kind of environment, we usually want to block in-app automatic updates and manage updates centrally via Munki (or MDM). Ideally, this would be exposed as managed preferences / configuration profile keys (.mobileconfig), for example:

• disable automatic updates
• disable Sentry / telemetry
• restrict usage to specific authorised domains / tenants
• etc.

For the uninstall/upgrade part: I’ve implemented a Munki preinstall_script that performs a silent uninstall before running your official kDrive-3.7.9.1.pkg. It keeps the configuration but removes the app and related components.

You can see here that the script works correctly:

Dec 05 2025 15:26:27 +0100 Installing kDrive (1 of 1)
Dec 05 2025 15:26:27 +0100     Running preinstall_script for kDrive
Dec 05 2025 15:26:27 +0100     2025-12-05T15:26:27+0100 [kdrive_munki_uninstall_common] info event_id=USER_CONTEXT Using user='lpipoz' home='/Users/lpipoz'
Dec 05 2025 15:26:27 +0100     2025-12-05T15:26:27+0100 [kdrive_munki_uninstall_common] info event_id=START Munki script: starting kDrive uninstall (REMOVE_CONFIG=0).
Dec 05 2025 15:26:27 +0100     2025-12-05T15:26:27+0100 [kdrive_munki_uninstall_common] info event_id=SQLITE_SKIP Parms DB not found: /Users/lpipoz/Library/Application Support/kDrive/kDrive.parms.db
Dec 05 2025 15:26:27 +0100     2025-12-05T15:26:27+0100 [kdrive_munki_uninstall_common] info event_id=FORCE_QUIT Attempting to terminate kDrive process.
Dec 05 2025 15:26:29 +0100     2025-12-05T15:26:29+0100 [kdrive_munki_uninstall_common] info event_id=CONFIG_MODE Keeping configuration; clearing sync nodes and removing application.
Dec 05 2025 15:26:29 +0100     2025-12-05T15:26:29+0100 [kdrive_munki_uninstall_common] info event_id=CLEAR_NODES Clearing kDrive sync nodes via kDrive binary.
Dec 05 2025 15:26:30 +0100     2025-12-05T15:26:30+0100 [kdrive_munki_uninstall_common] info event_id=RM_APP Removing kDrive.app: /Applications/kDrive/kDrive.app
Dec 05 2025 15:26:31 +0100     2025-12-05T15:26:31+0100 [kdrive_munki_uninstall_common] info event_id=RM_UNINSTALLER Removing kDrive Uninstaller.app: /Applications/kDrive/kDrive Uninstaller.app
Dec 05 2025 15:26:31 +0100     2025-12-05T15:26:31+0100 [kdrive_munki_uninstall_common] info event_id=RM_DIR Removing kDrive directory: /Applications/kDrive
Dec 05 2025 15:26:31 +0100     2025-12-05T15:26:31+0100 [kdrive_munki_uninstall_common] info event_id=END Munki script: kDrive uninstall sequence completed.
Dec 05 2025 15:26:31 +0100     2025-12-05T15:26:31+0100 [kdrive_munki_uninstall_common] info event_id=CLEANUP Cleanup complete.
Dec 05 2025 15:26:31 +0100     Running preinstall_script for kDrive was successful.
Dec 05 2025 15:26:31 +0100 Installing kDrive from kDrive-3.7.9.1.pkg
Dec 05 2025 15:26:31 +0100  Package name is kDrive Desktop
Dec 05 2025 15:26:31 +0100  Upgrading at base path /
Dec 05 2025 15:26:31 +0100     Préparation à l’installation…
Dec 05 2025 15:26:31 +0100     Préparation du disque…
Dec 05 2025 15:26:31 +0100     Préparation de kDrive Desktop…
Dec 05 2025 15:26:31 +0100     Attente de la fin des autres installations…
Dec 05 2025 15:26:31 +0100     Configuration de l’installation…
Dec 05 2025 15:26:32 +0100     6.117848 percent complete
...
Dec 05 2025 15:26:35 +0100     95.057416 percent complete
Dec 05 2025 15:26:35 +0100     Exécution des scripts du paquet…

The only drawback is that the user has to log in again, but the configuration is preserved, so from an end-user perspective it behaves almost like an in-place upgrade.

Having official support for:
• a documented, non-interactive uninstall/cleanup mechanism (with an option to preserve configuration), and
• configuration via .mobileconfig for things like auto-update and telemetry

would make kDrive much easier to integrate in managed macOS environments (Munki, Jamf, MDM, etc.).

[ChristopheLarchier]

Hello @loicpipoz
Your request has been added to our backlog.

You can already disable in-app updates by launching the app (once) with the option "--noUpdate".

"The only drawback is that the user has to log in again"
This should not happen if the password is still in the keystore (name = com.infomaniak.drive.desktopclient).

[loicpipoz]

Hi @ChristopheLarchier,

Thanks for the info about --noUpdate, that will fit very well in an AutoPkg / Munki workflow 👍

Regarding the re-login: it does happen here when the install is driven by Munki, even with REMOVE_CONFIG=0. I can reproduce two different behaviours with the same uninstall script:

Case 1 – Manual uninstall + manual install → no re-login

1. Install kDrive-3.7.8.2.
2. Configure a sync (user signs in, everything works).
3. Run my uninstall script manually with REMOVE_CONFIG=0.
4. Manually install kDrive-3.7.9.1 by running the pkg.
5. Launch kDrive.

👉 In this case, kDrive does not ask the user to sign in again.
From a user perspective, it behaves like an upgrade.

Case 2 – Munki run with preinstall_script → re-login required

1. Install kDrive-3.7.8.2.
2. Configure a sync (user signs in, everything works).
3. Configure Munki so that:
   • the kDrive item has a preinstall_script that calls the same uninstall script with REMOVE_CONFIG=0,
   • then Munki installs kDrive-3.7.9.1.pkg.
4. Run a Munki install (standard user, managed client).

👉 In this scenario, after the Munki run, kDrive asks the user to log in again, even though:

• the script is run with REMOVE_CONFIG=0,
• configuration files are preserved as much as possible,
• we are not touching the user keychain manually.

So it looks like there is a difference between:

• uninstall + install done manually in user context, and
• uninstall (in Munki preinstall_script) + install done in the same Munki transaction.

If it helps, I can provide more detailed logs or run specific tests you suggest to better understand why the credentials from com.infomaniak.drive.desktopclient are not reused in the Munki flow.

[ChristopheLarchier]

Hello @loicpipoz ,
You can check in the DB ($HOME/Library/Application Support/kDrive/.parms.db) if the value of user.keychainkey is the same as the Account field of the password.

If it's the same and the user is asked to sign in, please share your logs using the Share button in the Preferences / Debugging information popup and tell me the date and time of the sharing.