BOLO: Issues with Docker Desktop upgrades

[pmarkowsky]

A user in the MacAdmins Slack reports an issue with Docker Desktop upgrades resulting in a block of the vmnet process (9BNSXJN65R:com.docker.vmnetd) right after upgrade. Then everything works as intended.

Scenario

• User has Docker Desktop installed
• Admin performs upgrade via Kandji
• User sees an initial block message from santa for the vmnet process
• Everything continues afterwards

Important details

• They have a Team ID rule for Docker 9BNSXJN65R
• They're upgrading using Kandji.
• They're currently on version 4.44.3 (202357)

Resources

• Thread in the Mac Admins Slack #santa channel

[disenchant]

The same happed multiple times with Nextcloud for NKUJUXUJ3B:com.nextcloud.desktopclient.FinderSyncExt.

Also as an addition to the issue description: The blocking doesn't go away after it first pops up but instead it requires a reboot.

It looks like there's some caching issue in Santa when an application component is replaced. Based on the two components we experienced this (Docker's vmnetd and Nextcloud's FinderSyncExt) it could have to do with them being quite deeply integrated with macOS (network respectively FileProvider). As a last but maybe important information; we're not using a sync server but instead a configuration profile with our rules in it.

PS: I'm working together with Adrian who reported this in the Santa Slack channel so I can confirm we're talking about the same issue 😉

[pmarkowsky]

The thing is we don't cache blocks only allows.

@disenchant What OS version are you on and which version of Santa?

There is a caching bug in versions of Santa prior to 2025.7 on macOS 26 Tahoe.

[pmarkowsky]

@disenchant can you send me the output of santactl fileinfo for the application that's being blocked?

Can you also send me the output of the log from /var/db/santa/santa.log related to the application that's being blocked?

[pmarkowsky]

We were able to reproduce the issue. Essentially the helper tool com.docker.vmnetd is installed by Docker Desktop's com.docker.backend by directly writing to the same file /Applications/Docker.app/Contents/MacOS/install updates /Library/PrivilegedHelperTools/com.docker.vmnetd.

During an update there are ~200 write calls similar to the above event. If com.docker.vmnetd is executed in the middle of this, it is reasonable for Santa to get a bad view of the file as it's being changed.

After the file has finished being updated. Santa then gets a consistent view of the file and is able to apply rules again.

[agiurgea]

Hello,

Today I received again a warning from Santa when Docker tried to update itself automatically.

Regards

[agiurgea]

Hello,

Another app is presenting the same issue with Santa when it got updated:

App Name: Zwift (Smarttrainer)
App Link: https://www.zwift.com/
SigningID: C2GM8Y9VFM:ZwiftMacCrashHandler
TeamID: C2GM8Y9VFM
BundleID: %file_bundle_id%
Hash: 6f4887b19e43c3e7464efc527be5b2376710ce286fa240096c585bb3e59f75e1

Although we have this app whitelisted, it still triggered the Santa message. All ok after the Mac restart. But quite annoying.

Regards

[pmarkowsky]

@agiurgea Was it able to work after restarting the app or did you require a system restart?

Also what version of Santa and what version of macOS are you seeing this on?

[agiurgea]

@agiurgea Was it able to work after restarting the app or did you require a system restart?

Also what version of Santa and what version of macOS are you seeing this on?

The user had to restart the Mac and then it worked fine.
OS version
15.6.1 (24G90)
Santa Version: 2025.7

[Rinaldyr]

Hi, just wanted to share that we've also encountered this with some people on another app, jamfRemoteAssistConnector.

We have the certificate of this app already allowlisted (as seen in the santactl fileinfo of the affected user below), but one day (14th Jan onwards) it triggered the Santa popup and was evaluated as BLOCK_UNKNOWN. I think it automatically resolved itself after syncing.

$ santactl fileinfo /Library/Application\ Support/JAMF/Remote\ Assist/jamfRemoteAssistConnector
Path                 : /Library/Application Support/JAMF/Remote Assist/jamfRemoteAssistConnector
SHA-256              : 890a2ef9431d5a56a5d1685247f6073a9ba020467e4da4d128711001bcaeddb4
SHA-1                : 278c7611696746c71940dc1c2548e6268714e435
Team ID              : 483DWKW443
Signing ID           : 483DWKW443:com.jamf.remoteassist.connector
CDHash               : ea1acb213d04ddf56c312451c792b06c4a872a1b
Type                 : Executable (arm64, x86_64)
Code-signed          : Yes
Secure Signing Time  : 2026-01-08T14:56:43Z
Signing Time         : 2026-01-08T14:56:43Z
Rule                 : Allowed (Certificate)
Signing Chain:
  1. SHA-256            : 22f5e72bf9f3cee443e89f14b6af992c532eac6fcd896df1dc2bd44c4653701e
    SHA-1               : 32f48c85fe760f6009529ba94ee7fe9723e0f340
    Common Name         : Developer ID Application: JAMF Software (483DWKW443)
    Organization        : JAMF Software
    Organizational Unit : 483DWKW443
    Valid From          : 2022-05-31T17:57:42Z
    Valid Until         : 2027-06-01T17:57:41Z

We are on Santa 2025.9 on macOS 26.2.

Many thanks

[agiurgea]

Hello,

Again issues when updating NextCloud. Even though the TeamID of NextCloud is whitelisted, several users reported that Santa blocked the update.

Santa v2025.12 MacOS: Tahoe26.2

App Name: nextcloud
App Link: nextcloud
SigningID: NKUJUXUJ3B:com.nextcloud.desktopclient.FinderSyncExt
TeamID: NKUJUXUJ3B
BundleID: com.nextcloud.desktopclient.FinderSyncExt
Hash: 3dcc2ed36f2bffd6f052acaed4e1ea3efe5b69539dd825d3c686ee597efa326a

If the update is postponed, in a few days the issue is not present anymore.

Is there a way to avoid this?