Word-, Excel- oder PowerPoint-Datei bleibt „gesperrt“, obwohl niemand sie geöffnet hat – woran liegt das?

Sperrmechanismen in Microsoft Office: Lockfiles (~$), Dateisystem-Sperren und Co-Authoring im Vergleich

Wenn ein Office-Dokument „gesperrt“ bleibt, obwohl es scheinbar niemand mehr geöffnet hat, liegen oft mehrere Sperrschichten übereinander: klassische Dateisystem-Sperren (z. B. durch SMB-Handles), Office-eigene Indikatoren (temporäre Lockfiles wie ~$) sowie cloudbasierte Bearbeitungsmodelle (Co-Authoring in SharePoint/OneDrive). Diese Mechanismen verfolgen unterschiedliche Ziele: Schutz vor gleichzeitigen Schreibzugriffen, Wiederherstellung, Konfliktvermeidung und Benutzerinformation. Für eine saubere Fehleranalyse ist entscheidend, die Signale korrekt einzuordnen: Eine ~$-Datei ist nicht automatisch eine „echte“ Dateisperre, und umgekehrt kann eine Dateisystem-Sperre existieren, ohne dass Office eine Lockfile hinterlässt.

Office-Lockfiles (~$): Zweck, Inhalt und Lebenszyklus

Bei lokal oder auf klassischen Dateifreigaben bearbeiteten Office-Dateien (Word/Excel/PowerPoint) erzeugen Desktop-Apps typischerweise eine temporäre Lockfile im selben Verzeichnis wie das Dokument, häufig beginnend mit ~$ (beispielsweise ~$Bericht.docx). Diese Datei dient primär als Office-interner Indikator, dass die Datei in Bearbeitung ist, und kann Metadaten enthalten, etwa zur Anzeige „von Benutzer X geöffnet“. Die exakte Struktur ist anwendungs- und versionsabhängig; für die Praxis ist wichtiger: Die Lockfile ist ein Hilfsartefakt, kein vom Betriebssystem erzwungenes Sperrprimitive.

Im Normalfall löscht Office die Lockfile beim geordneten Schließen der Datei. Bleibt sie zurück, ist das ein Indiz für einen unvollständigen Abschluss (Absturz, Netzwerkunterbrechung, nicht beendeter Prozess) oder für eine Umgebung, in der die Löschung nicht zuverlässig durchgesetzt werden konnte (z. B. kurzzeitige Offline-Phasen, verzögerte Dateisynchronisation). Eine verbleibende ~$-Datei kann dazu führen, dass Office beim nächsten Öffnen einen „gesperrt“-/„schreibgeschützt“-/„Benachrichtigen“-Dialog zeigt, selbst wenn auf Dateisystemebene kein exklusives Handle mehr existiert.

Dateisystem-Sperren: Handles, Sharing-Flags und SMB-Semantik

Unabhängig von Office kann das zugrunde liegende Betriebssystem Dateien blockieren, indem ein Prozess ein Dateihandle mit bestimmten Sharing-Flags öffnet. Unter Windows und SMB-Freigaben ist das die maßgebliche „harte“ Sperre: Ein offenes Handle mit restriktiven Freigaberechten kann verhindern, dass andere Prozesse dieselbe Datei gleichzeitig zum Schreiben öffnen oder umbenennen/löschen. Diese Sperre ist robuster als eine Lockfile, weil sie durch den Server (bei SMB) bzw. den lokalen Kernel erzwungen wird.

In der Praxis entsteht das typische Missverständnis so: Office zeigt eine Sperrmeldung an, aber die Ursache ist nicht zwingend das SMB-Handle. Umgekehrt kann eine Datei durch einen anderen Prozess (Vorschau-Handler, PDF-Konverter, Backup/AV-Scanner, Indexer) per Handle blockiert werden, ohne dass Office irgendeine ~$-Datei erzeugt oder erkennt. Besonders relevant ist das auf Terminalservern/RDS und auf Fileservern mit vielen Integrationen, bei denen Handles länger als erwartet offen bleiben können.

Co-Authoring: Kein klassisches Lock, sondern koordinierte Parallelbearbeitung

In SharePoint Online (und je nach Konfiguration auch SharePoint Server) sowie OneDrive for Business ist Co-Authoring das Standardmodell für moderne Office-Dateiformate (.docx, .xlsx, .pptx) – vorausgesetzt, die Datei liegt in einer unterstützten Dokumentbibliothek und wird von kompatiblen Clients bearbeitet. Statt eine Datei exklusiv zu sperren, werden Änderungen fortlaufend synchronisiert und zusammengeführt. Office nutzt dazu Dienstschnittstellen und Sitzungskonzepte (Bearbeitungssitzungen), nicht einfach nur eine Dateisperre.

„Gesperrt“ bedeutet hier häufig etwas anderes als auf einer SMB-Freigabe: Beispielsweise kann eine Datei im Lesemodus geöffnet werden, weil AutoSave nicht verfügbar oder deaktiviert ist, weil die Bibliothek Auschecken (Check-out) erzwingt, weil eine Richtlinie (z. B. Sensitivity Labels/Information Protection, DLP/Conditional Access) den Zugriff einschränkt oder weil ein Client die Sitzung nicht sauber beendet hat und der Dienst die Bearbeitung kurzfristig konservativ behandelt. Zusätzlich können lokale Synchronisationszustände (OneDrive Sync Client) eine „scheinbare Sperre“ erzeugen, wenn Upload/Download aussteht und Office dadurch den Speicherpfad als nicht konsistent bewertet.

Woran Sperrarten in der Praxis erkennbar werden

Für die Einordnung ist hilfreich, die Beobachtungsebene zu trennen: Meldet Office einen anderen Benutzer, ist das oft Lockfile- oder Co-Authoring-Kontext. Meldet Windows „Datei wird verwendet“ oder verweigert das Dateisystem Umbenennen/Löschen, ist eher ein Handle ursächlich. In Cloudbibliotheken ist die Weboberfläche ein zusätzlicher Hinweisgeber (gleichzeitige Bearbeiter, Check-out-Status, Versionshinweise), während auf SMB-Freigaben eher Server-Tools und Sitzungstabellen zählen.

• Hinweis auf Lockfile: Im Ordner liegt eine Datei wie ~$Dateiname.docx; Office bietet „Schreibgeschützt öffnen“ oder „Benachrichtigen“, obwohl ein erneutes Öffnen nach kurzer Wartezeit manchmal wieder möglich ist.
• Hinweis auf Dateisystem-Sperre (Handle): Umbenennen/Löschen scheitert im Explorer mit „wird von einem anderen Prozess verwendet“; auf dem Fileserver zeigt eine Handle-Abfrage den Pfad, z. B. per Get-SmbOpenFile oder über die Computerverwaltung compmgmt.msc (Freigegebene Ordner → Geöffnete Dateien).
• Hinweis auf Co-Authoring/Cloudzustand: In der Titelleiste ist AutoSave aktiv/inaktiv; der Status zeigt „Upload ausstehend“ oder „Synchronisierungsproblem“ im OneDrive-Client; im Browser werden gleichzeitige Bearbeiter angezeigt oder die Datei ist ausgecheckt.
• Gemischte Signale: Eine ~$-Datei existiert, aber zusätzlich blockiert ein SMB-Handle (z. B. weil der Clientprozess noch läuft). In solchen Fällen ist das Entfernen der Lockfile allein wirkungslos, weil die echte Sperre bestehen bleibt.

Warum die Verwechslung so häufig ist

Office kommuniziert Sperren aus Anwendersicht („von X geöffnet“), während die technische Ursache unterschiedlich sein kann. Auf SMB-Freigaben treffen Office-Lockfiles und Dateihandles oft gleichzeitig auf: Office legt eine ~$-Datei an und hält zusätzlich ein Handle auf das Dokument. In Cloudbibliotheken wird dagegen häufig ohne exklusives Handle gearbeitet; die „Sperre“ ist dann eher eine Sitzungs- oder Konsistenzentscheidung (z. B. Client ist offline, Sitzung hängt, Upload blockiert). In OneDrive-Synchronisationsszenarien kommt hinzu, dass der lokale Dateipfad nicht automatisch identisch mit dem Autoritätsort (SharePoint/OneDrive) ist: Office kann lokal öffnen, während die Cloud-Version noch einen anderen Bearbeitungszustand meldet.

Warum das Verhalten je nach Umgebung variiert: SMB-Freigabe, Netzlaufwerk, OneDrive-Sync, SharePoint-Bibliothek und Offline-Zustände

Ob ein Office-Dokument „gesperrt bleibt“, hängt weniger von Word, Excel oder PowerPoint allein ab als von der Umgebung, in der die Datei liegt, und davon, wie der Zugriff technisch vermittelt wird. Office kombiniert mehrere Mechanismen: klassische Dateisperren des Betriebssystems/Dateiservers (z. B. SMB-Handles und Caching-/Opportunistic-Locking-Mechanismen), Office-eigene Lockfiles (z. B. ~$Dateiname.docx) sowie – in Cloud-Umgebungen – Koordinationsdaten für Co-Authoring, AutoSave und Versionsverwaltung. Je nach Speicherort werden diese Ebenen unterschiedlich priorisiert, sind unterschiedlich sichtbar und verhalten sich bei Netzwerkabbrüchen oder Client-Abstürzen unterschiedlich.

SMB-Freigabe und Netzlaufwerk: Handles, Opportunistic Locks und „verwaiste“ Lockfiles

Auf klassischen Dateifreigaben (SMB) entscheidet am Ende der Dateiserver über exklusive Zugriffe: Solange ein Client ein Handle offen hält, kann eine andere Instanz je nach Öffnungsmodus nicht schreiben. Office erzeugt zusätzlich Lockfiles im gleichen Ordner, die andere Office-Clients warnen und Benutzerinformationen anzeigen können. Diese ~$-Dateien sind nicht identisch mit der SMB-Sperre: Eine Datei kann gesperrt sein, obwohl kein ~$-Lockfile mehr existiert (Handle hängt), und umgekehrt kann ein ~$-Lockfile liegen bleiben, obwohl das Handle bereits geschlossen wurde (z. B. Crash oder Netzwerkunterbrechung).

In SMB-Szenarien verschärfen Netzwerkereignisse die Lage: Bei einem VPN-Abbruch oder einem Wechsel zwischen WLANs kann der Server ein Handle noch für eine gewisse Zeit als aktiv betrachten, bis Timeouts greifen (abhängig von SMB-Client/Server, Netzqualität und Session-Reconnect). Zusätzlich können Zwischenschichten (DFS-Namespace, Storage-Appliances, Antivirus-Scanner am Server) die Beobachtung verfälschen, weil sie selbst kurzzeitig Handles öffnen oder Metadatenzugriffe triggern. Für Anwender wirkt das wie eine „Geistersperre“, obwohl auf dem Client kein sichtbares Office-Fenster mehr offen ist.

OneDrive-Synchronisation: „lokal geöffnet“ ist nicht gleich „cloudseitig freigegeben“

Liegt die Datei in einem lokal synchronisierten OneDrive-Ordner, kommen zwei Perspektiven zusammen: Aus Sicht von Office wird eine lokale Datei geöffnet (NTFS), aus Sicht der Cloud wird eine Datei mit Versionshistorie, Upload-Queue und eventuellen Konflikten bearbeitet. AutoSave und Co-Authoring funktionieren hier oft, aber nicht immer identisch zu „direkt in SharePoint“. Wenn die Synchronisation verzögert ist, kann Office das Dokument bereits geschlossen haben, während OneDrive noch Uploads finalisiert oder Konflikte auflöst. In dieser Phase bleibt der Dateistatus für andere Nutzer widersprüchlich: lokal frei, cloudseitig noch als „in Bearbeitung“ markiert oder mit konkurrierenden Versionen versehen.

Besonders relevant sind Konfliktfälle: Wenn zwei Geräte dieselbe Datei offline ändern und später synchronisieren, entstehen Konfliktkopien oder Upload-Blockaden. Office kann dann „nur Lesen“ öffnen, weil die lokale Kopie nicht als konsistenter Stand gilt oder weil der Sync-Client die Datei als problematisch markiert. Das sieht wie eine Sperre aus, ist aber oft eine Schutzmaßnahme gegen Datenverlust durch konkurrierende Stände.

SharePoint/OneDrive in der Cloud: Co-Authoring, „Editing Sessions“ und serverseitige Steuerung

Wird ein Dokument direkt aus einer SharePoint-Dokumentbibliothek oder OneDrive (Web/Cloud) geöffnet, verlagert sich die Kontrolle stärker in die Microsoft-365-Dienste. Statt einer klassischen Dateisystem-Sperre koordinieren SharePoint/OneDrive Bearbeitungssitzungen, AutoSave und Versionierung. Co-Authoring reduziert harte Exklusivsperren, kann aber weiterhin Zustände erzeugen, die wie eine Sperre wirken: etwa wenn ein Dokument ausgecheckt ist, wenn eine Richtlinie (z. B. Sensitivity Label/Information Protection oder eine Zugriffsvorgabe) den gleichzeitigen Zugriff einschränkt, oder wenn ein Client eine Bearbeitungssitzung nicht sauber beendet (Absturz, Standby, Authentifizierung/Token-Erneuerung fehlgeschlagen).

Wichtig ist die Unterscheidung zwischen „Datei ist exklusiv gesperrt“ und „Bearbeitung ist aktuell nicht möglich“. In Cloud-Bibliotheken sieht man häufig Hinweise wie „wird bearbeitet von …“ oder es wird nur das Öffnen im Browser angeboten. Diese Hinweise basieren auf serverseitigen Sitzungsinformationen und können zeitverzögert aktualisieren, insbesondere wenn der Client nicht mehr erreichbar ist oder die Sitzung nicht sauber geschlossen wurde.

Offline-Zustände und Mischbetrieb: warum Sperren nach Abbrüchen „nachlaufen“

In gemischten Umgebungen (Laptop im Außendienst, VPN, zeitweise offline, anschließend Cloud-Sync) addieren sich Mechanismen. Ein typisches Muster: Das Dokument wird über ein Netzlaufwerk im VPN geöffnet, das VPN bricht ab, Office beendet sich oder hängt, und anschließend wird dieselbe Datei über einen anderen Pfad (z. B. lokal synchronisiert) erneut geöffnet. Der Dateiserver kann das ursprüngliche SMB-Handle noch als aktiv führen, während OneDrive/SharePoint parallel eine eigene Bearbeitungssitzung verwaltet. Dadurch entsteht der Eindruck, es seien „zwei Sperren“ vorhanden, obwohl es sich um zwei unterschiedliche Koordinationsschichten handelt.

Auch Windows-Energiesparzustände spielen hinein: Beim Standby werden Netzwerkverbindungen nicht immer sauber abgemeldet, und nach dem Aufwachen rekonstruiert der Client Sessions. Je nach Timing kann der Server eine Sperre erst nach Ablauf interner Timeouts freigeben. In Cloud-Szenarien kommt hinzu, dass ein Gerät offline weiterarbeitet und erst später den letzten AutoSave-Stand synchronisiert; bis dahin halten Dienste unter Umständen einen Bearbeitungsstatus aufrecht, um Versionskonflikte zu vermeiden.

• SMB/Fileserver-Perspektive prüfen: Auf Windows-Dateiservern zeigt Get-SmbOpenFile (PowerShell) offene Dateien/Handles; in der Computerverwaltung kann „Freigegebene Ordner“ → „Geöffnete Dateien“ Hinweise liefern. Bleibt dort ein Eintrag bestehen, ist es primär eine Serversperre, nicht „nur“ ein Office-Lockfile.
• Lockfile-Verhalten im Kontext bewerten: Ein verbliebenes ~$-Lockfile auf einem SMB-Share deutet häufig auf einen unclean shutdown hin; in OneDrive-Sync-Ordnern ist ein solches Lockfile weniger aussagekräftig, weil zusätzlich Sync- und Cachezustände wirken.
• OneDrive-Sync als eigene Fehlerdomäne behandeln: Bei „gesperrt“-Eindruck im Sync-Ordner zuerst den Sync-Status prüfen (OneDrive-Client: „Synchronisierungsprobleme“, „Upload ausstehend“) und nach Konfliktkopien suchen, bevor serverseitige Sperren vermutet werden.
• SharePoint/Co-Authoring-Indikatoren ernst nehmen: Wenn die Bibliothek „ausgecheckt“ oder „wird bearbeitet von“ anzeigt, handelt es sich häufig um einen Dienstzustand; ein reines Löschen lokaler Lockfiles löst diesen Fall typischerweise nicht.

Die gleiche Benutzerfehlermeldung („Datei ist gesperrt“, „nur Lesen“, „kann nicht bearbeitet werden“) beschreibt somit je nach Umgebung unterschiedliche Ursachen: In SMB-Welten dominiert die Handle-Sperre und deren Auflösung durch Server/Netzwerk. Im OneDrive-Sync-Ordner stehen Upload- und Konfliktzustände im Vordergrund. In SharePoint-Bibliotheken sind Bearbeitungssitzungen, Co-Authoring-Logik und Bibliotheksregeln entscheidend. Eine saubere Diagnose setzt daher immer beim Speicherort und dem Zugriffsweg an, nicht beim Dateityp.

Diagnose und Abhilfe in der Praxis: Sessions prüfen, Lockfiles bewerten, Sync-Konflikte auflösen und sicher entscheiden, wann Löschen erlaubt ist

Wenn ein Office-Dokument „zur Bearbeitung gesperrt“ bleibt, obwohl niemand es sichtbar geöffnet hat, sind in der Praxis fast immer drei Ursachenklassen beteiligt: eine noch bestehende Dateiserver-Session (SMB-Handle), ein verwaistes Office-Lockfile (z. B. ~$Datei.docx) oder ein Cloud-/Sync-Zustand (OneDrive/SharePoint) mit Co-Authoring, Upload-Pending oder Konfliktdateien. Eine saubere Diagnose trennt diese Ebenen konsequent, sonst werden Symptome behandelt (Lockfile löschen), während die eigentliche Sperre (Handle oder Sync) weiterbesteht.

1) Serverseitig beginnen: Offene Sessions und Handles verifizieren (SMB/Netzlaufwerk)

Bei klassischen Netzlaufwerken entscheidet häufig nicht Office, sondern der Dateiserver: Solange ein Client ein Handle auf die Datei hält, kann der Server exklusive Zugriffe blockieren. Das passiert typischerweise nach Verbindungsabbrüchen (WLAN/VPN), Standby oder wenn ein Office-Prozess nicht sauber beendet wurde. Die wichtigste Regel: Erst feststellen, ob überhaupt noch ein Handle existiert; erst danach Lockfiles bewerten.

Unter Windows Server lässt sich das ohne Rätselraten prüfen. In kleineren Umgebungen genügt die Computerverwaltung (Freigegebene Ordner → Geöffnete Dateien). In automatisierten oder größeren Umgebungen sind PowerShell/CLI-Auswertungen zuverlässiger, weil sie auch Remote und wiederholbar funktionieren.

• SMB-OpenFiles auf dem Dateiserver anzeigen: Get-SmbOpenFile | Where-Object {$_.Path -like "*\Datei.xlsx"}
• Zuordnung zu Benutzer/Client prüfen: Get-SmbOpenFile | Select-Object ClientComputerName,ClientUserName,Path,SessionId,FileId
• Session statt Datei bewerten (bei vielen offenen Dateien): Get-SmbSession | Sort-Object -Property ClientComputerName
• Gezielt schließen (nur nach Freigabe durch Fachseite): Close-SmbOpenFile -FileId <FileId> -Force
Close-SmbSession -SessionId <SessionId> -Force

Das erzwungene Schließen ist ein Eingriff mit Datenrisiko: Office kann ungespeicherte Änderungen im Client-Puffer haben. Vor dem Schließen sollte geklärt sein, ob der betroffene Benutzer tatsächlich nicht mehr arbeitet (z. B. per Rückfrage), und ob Co-Authoring/AutoSave im Spiel ist (dann kann bereits in die Cloud geschrieben worden sein, aber nicht zwingend bis zum letzten Stand).

2) Lockfiles richtig einordnen: Existenz, Zeitpunkt, Inhalt und Speicherort prüfen

Office-Lockfiles dienen vor allem der Koordination und Benutzerinformation. Sie liegen im selben Verzeichnis wie das Dokument und beginnen häufig mit ~$ (z. B. ~$Projektplan.docx). Ein verwaistes Lockfile kann nach einem Crash oder einer abrupt getrennten Sitzung übrig bleiben. Gleichzeitig kann ein Lockfile auch völlig legitim existieren, weil die Datei tatsächlich noch in einer Office-Instanz geöffnet ist oder weil ein Prozess den Zustand noch nicht sauber beendet hat.

Für die Bewertung zählen vier Fragen: (1) Gibt es serverseitig noch ein Handle auf der eigentlichen Datei? (2) Ist das Lockfile frisch (Zeitstempel) oder alt? (3) Passt die Größe/Änderungszeit zum erwartbaren Bearbeitungszeitpunkt? (4) Befindet sich der Speicherort in einem Sync-Kontext (OneDrive/SharePoint) oder auf einem reinen SMB-Share?

Das manuelle Löschen eines Lockfiles ist nur dann fachlich vertretbar, wenn kein Handle auf dem Dokument existiert und ausgeschlossen ist, dass ein Client gerade offline Änderungen puffert. In Cloud-/Sync-Szenarien ist diese Ausschlussprüfung schwieriger; dort führt „Lockfile löschen“ häufig zu Folgeproblemen (Konfliktkopien, Versionssprünge, erneute Sperren).

3) OneDrive/SharePoint: Sync-Zustand, Co-Authoring und Konflikte diagnostizieren

Bei OneDrive/SharePoint ist „gesperrt“ oft kein klassischer Dateilock, sondern ein Zusammenspiel aus Co-Authoring, AutoSave und Synchronisationszustand. Typische Auslöser sind ein Client, der noch hochlädt („Ausstehende Uploads“), ein kurzzeitig offline befindlicher Rechner mit späterem Reconnect oder eine Bearbeitung über unterschiedliche Endpunkte (Desktop-App und parallel im Browser). Die Diagnose muss deshalb den lokalen Sync-Client einbeziehen.

• Sync-Client-Status auf dem betroffenen PC prüfen: OneDrive-Symbol → „Hilfe & Einstellungen“ → „Synchronisierung anhalten/fortsetzen“; bei Problemen „Synchronisierungsprobleme anzeigen“ und Konflikte explizit auflisten.
• Lokale Konfliktartefakte erkennen: Nach Dateien mit Mustern wie "Konflikt", "Computername" oder doppelten Dateinamen im selben Ordner suchen (Explorer-Suche), statt nur die Originaldatei zu öffnen.
• AutoSave/Co-Authoring-Status verifizieren: In der Office-Desktop-App oben links AutoSave-Schalter (falls vorhanden) und Kontostatus prüfen; bei Bibliotheken mit Versionierung zusätzlich im Web die Versionshistorie ansehen, bevor lokal „repariert“ wird.
• SharePoint-Sperrinformationen im Web prüfen: In der Dokumentbibliothek Details/Informationen zum Dokument öffnen und Hinweise wie „Gesperrt von“ oder Checkout-Status auswerten; bei Checkout (falls genutzt) nur dort aufheben, nicht per Dateisystem.

Eine häufige Fehlerkette ist: Datei wird lokal geöffnet, VPN bricht ab, OneDrive wechselt in „Offline“, Office hält den Bearbeitungszustand, der Benutzer schließt das Fenster, aber OneDrive kann die finale Synchronisierung nicht abschließen. In dieser Lage kann die Datei für andere als gesperrt erscheinen, obwohl lokal „geschlossen“ wurde. Abhilfe schafft hier nicht das Entfernen von ~$, sondern das Herstellen eines sauberen Sync-Endzustands (Wiederverbindung, Upload abschließen, ggf. Konfliktauflösung).

4) Entscheidungslogik: Wann Löschen erlaubt ist – und wann ausdrücklich nicht

Das Löschen von Lockfiles ist kein Standard-Schritt, sondern eine Ausnahmeentscheidung. Sicher ist es nur, wenn die Sperre eindeutig nicht mehr aktiv ist und keine ausstehenden Schreibvorgänge existieren. Unsicher ist es insbesondere bei Cloud-Dateien mit AutoSave, bei unbekanntem Offline-Status von Clients und wenn die Datei nicht auf einem klassischen SMB-Share liegt, sondern über OneDrive „Files On-Demand“ bereitgestellt wird.

• Löschen ist in der Regel vertretbar, wenn: Es existiert kein Handle auf die Datei (z. B. Get-SmbOpenFile liefert keinen Treffer), der Besitzer der letzten Bearbeitung ist erreichbar oder ausgeschlossen, und der Speicherort ist ein reines SMB-Verzeichnis ohne Sync-Layer.
• Löschen ist zu vermeiden, wenn: OneDrive/SharePoint beteiligt ist und der Sync-Client nicht „aktuell“ meldet, wenn im Web „Gesperrt von“ angezeigt wird, wenn Checkout/Compliance-Regeln greifen, oder wenn ein Client potenziell offline Änderungen gepuffert hat (Laptop/VM/Remote-Session).
• Vor dem Löschen minimal prüfen: Datei- und Lockfile-Zeitstempel vergleichen, Größe des Lockfiles auf spontane Änderungen beobachten, und bei Netzshares serverseitig Benutzer/Computer des letzten Zugriffs ermitteln (z. B. Get-SmbOpenFile, Get-SmbSession).
• Nach dem Löschen kontrollieren: Dokument erneut öffnen und sofort speichern; wenn die Sperre wiederkehrt, liegt die Ursache nicht im Lockfile, sondern in einer aktiven Session oder einem Sync-Prozess.

Wenn eine Sperre wiederholt „zurückkommt“, ist das ein klares Indiz für eine weiterhin aktive Ursache (offener Prozess, wiederhergestellte Session, OneDrive-Upload-Pending, Web-Checkout). In solchen Fällen sollte die weitere Analyse auf den verursachenden Client fokussieren: laufende WINWORD.EXE/EXCEL.EXE-Instanzen, Office-Add-ins, RDS/AVD-Sessions, sowie den OneDrive-Clientzustand auf genau diesem Gerät.