Backups und ESET

Weil ich nicht mehr auf Time Machine setzen wollte, habe ich mich für die Open Source-Lösung restic entschieden. Ich nutze restic schon lange auf Windows und Linux. Als ich eine meiner Backupfestplatten an den Mac angeschlossen habe, kam diese Meldung:

Could not mount “Ventoy”.
(com.apple.DiskManagement.disenter error 49.153.)

Es stellt sich heraus: das ist das Device Control-Feature des Produkts ESET Endpoint Security. Wäre schön, wenn die Meldung das sagen würde....und es ist sehr wahrscheinlich auch die Erklärung, warum Time Machine nicht mehr funktioniert hat - mit ähnlich seltsamen Fehlermeldungen.

Die Lösung ist, eine Regel einzurichten, die meine Festplatten erlaubt. Dazu ESET öffnen, über ⌘, in die Einstellungen gehen » Device Control » Rules. Ganz unten links ist ein +. Unter Manufacturer gibt es ein Populate, sodass die Regel nur für Hersteller, Modell und Seriennummer gilt. In meinem Fall habe ich eine Regel für jede erlaubte externe Festplatte angelegt. Sobald die Regeln aktiv sind, kann ich Device Control wieder aktivieren und trotzdem meine Backups auf externe Festplatten sichern. Vor fremden USB-Geräten bleibe ich so geschützt.

Technische Schritte zur Erkennung des Problems

Diagnose: exFAT-Volume lässt sich unter macOS 27.0.1 nicht mounten

Ausgangslage: externe 4-TB-USB-Festplatte von TOSHIBA. Der Mount bricht mit com.apple.DiskManagement.disenter error 49.153 ab; dezimal 49153 ist 0xC001.

1. Partitionslayout ansehen

   diskutil list external

   disk4 mit GUID-Partitionstabelle, zwei Partitionen vom Typ „Microsoft Basic Data“: disk4s1 („Ventoy“, 4,0 TB) und disk4s2 („VTOYEFI“, 33,6 MB). Das ist das typische Ventoy-Layout. Ich nutze Ventoy, falls ich mal einen Rechnen von einem .ISO-Image starten möchte - aber das hat mit dem Problem nichts zu tun.

2. Details zur Partition

   diskutil info disk4s1

   File System Personality ExFAT, nicht gemountet, Protokoll USB, Gerät „External USB 3.0“, Volume-UUID 0B47E02F-864F-3918-8D77-E825351878F6. Die zugleich abgefragten Logs von fsck_exfat und diskarbitrationd waren leer.

3. Mount erneut versuchen, Dateisystem prüfen, ohne zu schreiben

   diskutil mount disk4s1
   fsck_exfat -n /dev/rdisk4s1

   Mount schlägt fehl („try the readOnly option“). fsck_exfat -n prüft über das Raw-Device und schreibt nichts: Boot-Regionen, Systemdateien, Upcase-Tabelle, Verzeichnisbaum und Bitmap sind in Ordnung („The volume Ventoy appears to be OK“). Ein beschädigtes Dateisystem als Ursache ist damit unwahrscheinlich.

4. Read-only-Mount

   diskutil mount readOnly disk4s1

   Schlägt ebenfalls fehl. Im per grep gefilterten Log fand sich nichts dazu.

5. Manueller Mount am DiskArbitration vorbei

   mount -t exfat -o rdonly /dev/disk4s1 <mountpoint>

   mount_exfat versucht über kmutil die alte exfat.kext zu laden. Ergebnis: Authenticating extension failed: Bad code signature, exfat filesystem is not available, Exit-Code 71. Das ist eine falsche Fährte: macOS 27 mountet exFAT über FSKit, nicht über die Kext.

6. Systemkontext erfassen

   sw_vers
   systemextensionsctl list
   pluginkit -m -p com.apple.fskit.fsmodule

   macOS 27.0.1 (26A434). Als Endpoint-Security-Extension ist com.eset.endpoint aktiv, außerdem mehrere Network Extensions (ESET, Little Snitch, Proton VPN). An FSKit-Modulen sind com.apple.fskit.exfat, .msdos und .ftp installiert.

7. Mount auslösen und gleichzeitig die Logs lesen

   diskutil mount disk4s1
   /usr/bin/log show --last 1m --style compact \
     --predicate 'process == "fskitd" OR process == "diskarbitrationd" OR process CONTAINS "exfat" OR process CONTAINS[c] "eset" OR process == "diskmanagementd"'

   Die entscheidenden Zeilen:

   fskitd  ReallyMountVolume: Enter for provider com.apple.filesystems.UserFS.FileProvider
   fskitd  -[mountEntry mount:options:auditToken:]: will mount over LIFSv2
   fskitd  mount(2) error: 1
   fskitd  mount launch failed with result "Operation not permitted"[1]
   diskarbitrationd  mount call of <private> returned (status code 0x00000001).

   Der Syscall mount(2) liefert EPERM. Das FSKit-Modul liest das Volume also problemlos, aber eine Policy auf Kernel-Ebene verweigert den Mount. Das passt zu einem Endpoint-Security-Client, der ES_EVENT_TYPE_AUTH_MOUNT ablehnt.

8. MDM ausschließen, ESET-Installation finden

   profiles status -type enrollment
   ls /Library/Application\ Support/ESET*

   Weder DEP noch MDM-Enrollment, also keine Restriktion per Konfigurationsprofil. Verzeichnisse von ESET sind vorhanden. Im Log tauchte ESET namentlich nicht auf. Ich wünschte ESET wäre hinterher, sich als Ursache auffindbarer zu machen. 🤯

9. ESET-Komponenten näher ansehen

   find "/Library/Application Support/ESET" -iname "*device*"
   ls /Applications | grep -i eset

   Gefunden: .../ESET/Security/log/devicecontrol.dat. Installiert sind ESET Endpoint Security, ESET Management Agent und ESET Remote Administrator Agent.

10. Zeitstempel abgleichen

    ls -la "/Library/Application Support/ESET/Security/log/"
    date

    devicecontrol.dat hat die mtime 11:44, die Systemzeit war 11:44:38. Die Datei wurde also genau beim Mount-Versuch aus Schritt 8 geschrieben. Ihr Inhalt war nicht lesbar: Sie gehört eset-ecsm-logd, Rechte drwx------. Der Beleg ist also nur zeitlich, aber zusammen mit dem EPERM eindeutig.

11. Mount nach dem Deaktivieren

    diskutil mount disk4s1

    Volume Ventoy on disk4s1 mounted.

Fazit

Tipp: Wenn mount(2) unter macOS EPERM liefert, zuerst mit systemextensionsctl list nachsehen, ob ein Endpoint-Security-Client läuft.