Seit ca. einer Woche kommt es auf einem Windows Server in Verbindung mit MinIO und restic zu einem Problem mit den Locks.

Im MinIO-Log finden sich dann Meldungen wie diese:

API: PutObject(bucket=test, object=hv01/locks/cf0319a2777bdf0963b50afdab488d706a490816a60d6ef513a20fd8da489218)
Time: 12:44:54 UTC 04/15/2023
DeploymentID: be47cc5e-40bc-4658-afc1-d6f3ebd8aff7
RequestID: 17561C5C9DA36DD4
RemoteHost: 127.0.0.1
Host: 127.0.0.1:9000
UserAgent: MinIO (windows; amd64) minio-go/v7.0.47
Error: file access denied (cmd.StorageErr)
       7: internal\logger\logger.go:258:logger.LogIf()
       6: cmd\erasure-object.go:1271:cmd.erasureObjects.putObject()
       5: cmd\erasure-object.go:954:cmd.erasureObjects.PutObject()
       4: cmd\erasure-sets.go:767:cmd.(*erasureSets).PutObject()
       3: cmd\erasure-server-pool.go:960:cmd.(*erasureServerPools).PutObject()
       2: cmd\object-handlers.go:1865:cmd.objectAPIHandlers.PutObjectHandler()
       1: net\http\server.go:2122:http.HandlerFunc.ServeHTTP()

In diesem Fall greift restic auf MinIO zu. Am Anfang der Session möchte restic immer eine Sperre, kurz Lock, setzen. Dieser Vorgang funktioniert nur noch einmalig direkt nach dem Start von MinIO. Ist restic fertig, wird der Lock gelöscht, aber genau hier geht irgendetwas schief und es bleibt ein unlesbarer bzw. “unzugreifbarer” Locks-Ordner zurück, der zudem nicht anderweitig (via S3-Tools oder direkt im Dateisystem) gelöscht werden kann und erst durch den Neustart von MinIO verschwindet.

Es scheint, als habe MinIO da noch irgendwie die Finger drauf oder erhält womöglich von Windows keine passende Rückmeldung oder sowas. Zunächst nahm ich an, es liegt an den April-Patches von Microsoft und MinIO, daher wurden beide rückgängig gemacht, aber leider war’s das nicht. Das Storage wurde ebenfalls überprüft, hier zeigten sich bislang keine Fehler oder Probleme. Alle anderen Zugriffe auf das gleiche Storage bzw. genau genommen das gleiche Volume verlaufen völlig reibungslos.

Für den Moment bleibt es ein Rätsel. Bei Zugriffsprobleme verweist MinIO darauf, das es ein “underlaying storage problem” sei. Mit anderen Worten: An uns liegt es nicht. Das mag sein, im Moment ist die Ursache bzw. der Grund leider unklar. Als Workaround lasse ich im Moment einmal am Tag MinIO neu starten.

Update 05.06.2023

Es scheint als sei das Problem durch das aktuelle MinIO-Update (Version: RELEASE.2023-06-02T23-17-26Z (go1.19.9 windows/amd64)) gelöst worden.