Windows: Ordner mit Schloss markiert und unlöschbar

win7Heute möchte ich auf Problem eingehen, welches möglicherweise so manchen Benutzer schier zur Verzweiflung treibt: Auf einem logischen Laufwerk gibt es einen Ordner, der sich nicht löschen lässt, weil Windows den Zugriff verweigert.


Anzeige

Mich hatte es auf einer Produktmaschine mit Windows 7 getroffen. Auf dem Systemlaufwerk und auf einer zweiten Festplatte mit einer Backup-Partition war ein Ordner mit einem recht kryptischen Namen der Art 3fef4e759753fef4e75975. Der Name bestand nur aus Hex-Ziffern und deutete darauf hin, dass irgend ein Update oder Service Pack diesen bei der Installation zurückgelassen hatte. Beim Windows-Laufwerk konnte ich den betreffenden Ordner mit administrativen Berechtigungen löschen. Aber auf einem Backup-Laufwerk verweigerte Windows pertinent das Löschen. Hier ein kleiner Abriss, wie ich das störrische Biest am Ende des Tages doch von der Platte putzen konnte.

Meine Idee: Lösche es als Administrator

Meine erste Überlegung war, diesen Ordner im Explorerfenster zu löschen. Also habe ich den Ordner im Explorer angewählt und den Kontextmenübefehl Löschen gewählt. Dann wurde ich gefragt, ob ich den Ordner in den Papierkorb verschieben mag.

Ordner01

Habe ich natürlich bestätigt, um mich dann mit folgendem Dialogfeld konfrontiert zu sehen (wobei der Ordner definitiv nicht freigegeben war).

Ordner02

Ich habe die Fortsetzen-Schaltfläche angewählt und die Sicherheitsabfrage der Benutzerkontensteuerung bestätigt. Anschließend erhielt ich das folgende Dialogfeld angezeigt.

Ordner03

Also erneut die Fortsetzen-Schaltfläche angewählt und die Sicherheitsabfrage der Benutzerkontensteuerung bestätigt. Worauf mir zuerst das obige Dialogfeld mit dem Hinweis auf die Freigabe samt Aufforderung zur Bestätigung über die Fortsetzen-Schaltfläche erneut angezeigt wurde. Nach mehrfachen Bestätigungen diverser Dialogfelder erhielt ich dann die nachfolgende Fehleranzeige.


Anzeige

Ordner04

Der Ordnerzugriff wurde mir durch Windows verweigert, wobei die Fehlermeldung recht sinnfrei war. Die erforderlichen Berechtigungen sollte ich von Rom7\SysAdmin erhalten. Das war aber mein Administratorkonto und durch Bestätigung der Benutzerkontensteuerung hätte ich eigentlich die Berechtigungen besitzen müssen.

NTFS-Zugriffsberechtigungen zuweisen half nicht

Ich habe dann den Ordner mit der rechten Maustaste angewählt, den Kontextmenübefehl Eigenschaften gewählt und auf der Registerkarte Sicherheit die Zugriffsberechtigungen kontrolliert.

Ordner05

Die Gruppe der Administratoren hat in obigem Screenshot Vollzugriff – ich erinnere mich, dass diese Berechtigung ursprünglich fehlte, aber über die Schaltfläche Bearbeiten zugeteilt werden konnte. Alleine, es änderte nichts – ich bekam bei der oben beschriebenen Vorgehensweise die gezeigten Dialogfelder zu Gesicht und das Löschen wurde verweigert.

Anmerkung: Im nachhinein habe ich an dieser Stelle versäumt, die Zugriffsberechtigungen für Authentifizierte Benutzer anzusehen. Möglicherweise war diesen kein Vollzugriff zugeteilt (ich kann's nicht mehr prüfen) und hätte mir den restlichen Zinnober sparen können – siehe auch meine abschließende Bemerkung am Artikelende.

Ich habe dann versucht, auf der Registerkarte Sicherheit über die Schaltfläche Erweitert den Besitz zu übernehmen. Das klappte zwar, änderte aber nichts am Umstand, dass mir weiterhin das Löschen des Ordners wegen fehlender Zugriffsrechte verweigert wurde. Ich konnte lediglich den Namen des Ordners umbenennen – was mir aber nicht sonderlich viel nützte.

Ordner08

Also habe ich das Programm AccessEnum aus den Microsoft Sysinternals Tools aufgerufen und mir die Zugriffsberechtigungen anzeigen lassen. Administratoren besitzen Schreibberechtigungen etc.

Ich versuche jetzt mal Trick 17

Um nicht ständig durch die Sicherheitsabfragen der Benutzerkontensteuerung genervt zu werden, habe ich dann einen Weg gesucht, um per Dateimanager mit administrativen Berechtigungen zu arbeiten und das Ganze weiter zu untersuchen.

Stopp: Leider kann das Programm Explorer.exe nicht mit administrativen Berechtigungen laufen (auch wenn im Internet fälschlich was anderes behauptet wird). Der Aufruf über Als Administrator ausführen ist zwar möglich – da aber die Explorer.exe auch als Shell fungiert, verhindert Windows intern das Erteilen administrativer Tokens für den Prozess (ich habe das kurz im Artikel Explorer als Administrator ausführen angesprochen).

Tipp: Ich habe daher immer ein paar portable Dateimanager wie a43, FreeCommander oder Explorer++ auf einer separaten Festplattenpartition herumliegen. Diese brauchen nicht installiert zu werden und lassen sich über den Kontextmenübefehl Als Administrator ausführen aufrufen. Nach Bestätigung der Benutzerkontensteuerung läuft der ganze Prozess mit administrativen Berechtigungen und weitere Abfrage der Benutzerkontensteuerung entfallen (siehe auch). Man kann also auf alle Dateien, für die der Administrator Zugriffsrechte hat, zugreifen und diese auch manipulieren (umbenennen, löschen, verschieben).

Als ich den Ordner im Explorer++ inspizierte, wurden mir alle Unterordner mit einem Schloss versehen angezeigt (siehe folgender Screenshot).

Ordner06

Die Ordner enthielten jeweils die Dateien eula.rtf, LocalizedData.xml und SetupResources.dll und waren schreibgeschützt. Das Schreibschutzattribut ließ sich nicht aufheben. Deutete alles darauf hin, dass das Ganze ein Überbleibsel einer Installation war und der Installer seine eigenen temporären Ordner nicht mehr von der Platte putzen konnte. Ich hatte lediglich einen Teilerfolg, dass ich einen einzigen Ordner löschen konnte.

Andererseits sollten die Ordner auch nicht durch irgendwelche Windows-Prozesse geöffnet sein, da es ein Backup-Laufwerk war. Müßig zu erwähnen, dass ich die NTFS-Zugriffsberechtigungen angepasst und auch den Besitz des Objekts erfolgreich übernommen hatte.

Ich nehme den Holzhammer und versuche auch noch den nächsten Trick 17

Zum Schluss blieb mir nichts anderes übrig, als nach dem großen Holzhammer zu greifen und einen zweiten Griff in die Trickkiste zu tun. Bei den SysInternals Tools gibt es das Programm PsExec.exe, mit dem man Prozesse auch unter dem Benutzerkonto System laufen lassen kann. Ich setze das Programm gelegentlich ein, wenn sich Registrierungseinträge per Regedit.exe nicht löschen lassen. Also habe ich mir die Datei Explorer++.exe und die Datei PsExec.exe in einen lokalen Ordner kopiert und dann folgende Verknüpfung angelegt.

F:\<pfad>\explorer++_1.0.0.0_x86\PsExec.exe -i Explorer++.exe

Den Laufwerksbuchstaben und den Platzhalter <pfad> auf den Ordner mit der Datei PsExec.exe müsst ihr noch anpassen. Der Trick besteht im Aufruf des Programms Explorer++.exe über PsExec.exe mittels des Schalters –i. PsExec.exe bewirkt, dass der Prozess unter dem Konto System läuft, also alle Rechte eines Systemdiensts besitzt. Und der Schalter –i erzwingt, dass der Prozess im interaktiven Modus läuft, d.h. das Fenster des Dateimanagers wird angezeigt.

Ordner07

Beim Aufruf des Ordners im Explorer++ über die Verknüpfung waren die Schloss-Symbole weg. Habe mich schon gefreut wie ein Schneekönig – aber ich konnte den Ordner samt Unterordner nach wie vor nicht löschen. Das Schreibschutzattribut wurde sofort nach dem Aufheben wieder gesetzt und beim Löschen erschien die Abfrage der Benutzerkontensteuerung mit dem anschließenden Hinweis, dass ich die Administratorberechtigung benötige.


– Werbung – meine Windows Titel bei Amazon-



Die Ochsentour über die Dörfer ist angesagt

Am Ende des Tages bin ich dann im Explorer++ in jeden Ordner hineingegangen und konnte dort die enthaltenen Dateien eula.rtf, LocalizedData.xml und SetupResources.dll löschen. Im Anschluss ließ sich dann auch der übergeordnete Ordner entfernen. Das Ganze war zwar ein etwas umständliches Unterfangen, da ich zig mal beim Zugriff auf den Ordnerinhalt die Benutzerkontensteuerung zu bestätigen hatte.

Meine Idee, den Explorer++ über Als Administrator ausführen aufzurufen und dann zu löschen, scheiterte. Der Aufruf der Benutzerkontensteuerung unterblieb das zwar, dafür klappte aber das Löschen der Dateien nicht.

Am Ende des Tages konnte ich über diesen Umweg alle Unterordner löschen, erhielt aber beim Löschen des Hauptordners den Hinweis, dass der Ordner von einem Programm geöffnet sei. So richtig geglaubt habe ich das nicht – und meine Suche nach einem Programm, was den leeren Ordner noch im Zugriff hatte, war auch nicht wirklich erfolgreich.

In den Fuß geschossen?

Nach einiger Sucherei habe ich dann erneut über den Kontextmenübefehl Eigenschaften die Registerkarte Sicherheit für den verbliebenen (leeren) Hauptordner geöffnet.

Ordner09

Dort fiel mir auf, dass der Gruppeneintrag Authentifizierte Benutzer keinen Vollzugriff hatte (siehe obiger Screenshot). Also habe ich den Vollzugriff für den leeren Ordner über die Schaltfläche Bearbeiten gesetzt. Und im Anschluss konnte ich den leeren Ordner problemlos als normaler Benutzer im Explorerfenster löschen.

Keine Ahnung, ob ich das beim ersten Anpassen der Zugriffsberechtigungen übersehen hatte – und mir den ganzen Zinnober mit PsExec hätte ersparen können. Für mich war es nur wichtig, dass der Ordner endlich weg war. Laut diesem Artikel hätte mir das Ändern des Besitzes des Ordners eigentlich die notwendigen Zugriffsrechte verleihen müssen – was aber nicht der Fall war.

Fazit: Und was lernen wir daraus?

Ich hätte den Blog-Beitrag nicht zu schreiben brauchen, wenn er nicht als schlechtes, aber lehrhaftes Beispiel dienen kann. Erste Erkenntnis wäre, dass ihr bei vergleichbaren Fällen direkt in den Zugriffsberechtigungen die Werte für den Gruppeneintrag Authentifizierte Benutzer auf Vollzugriff kontrolliert. Möglicherweise wäre das die "Abkürzung" in meinem Fall gewesen.

Aber die Geschichte hat noch eine zweite Komponente – ihr habt über diesen Schwenk zwei Tricks kennen gelernt. Die obigen Kniffe mit Verwendung eines portablen Dateimanagers samt Aufruf über Als Administrator ausführen sind unter Windows ganz wertvoll. Versucht man nämlich im Explorer auf einen Ordner zuzugreifen, für den man keine Berechtigung besitzt, erscheint eine Abfrage der Benutzerkontensteuerung. Bestätigt man diese, werden allen Objekten im gewählten Element die notwendigen Zugriffsberechtigungen auf NTFS-Dateiebene zugewiesen – sprich: Der Zugriffs verändert die Dateiberechtigungen.

Das ist oft aber unerwünscht – bei Backup-Ordnern (WindowsImageBackup) hatte ich beispielsweise den Effekt, dass sich das Abbild nicht mehr zurücklesen ließ. Der Ansatz, einen portablen Dateimanager über Als Administrator ausführen aufzurufen, vermeidet dies. Der Prozess läuft mit administrativen Berechtigungen und erhält Zugriff auf den Ordnerinhalt, ohne dass die NTFS-Zugriffsberechtigungen angepasst werden müssen. Man kann also ohne weitere Spuren zu hinterlassen Systemordner inspizieren.

Ähnliche Artikel:
a1: Windows 8.1: Öffentliche Ordner verschieben
a2: Explorer als Administrator ausführen
a3: Dateimanager mit administrativen Rechten ausführen

a4: Notfallhilfe mit Windows PE, falls Windows 8 nicht startet
a5: Windows PE 4.0: Diese Programme laufen


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Datenträger, Tipps, Windows 7, Windows 8.1 abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

13 Antworten zu Windows: Ordner mit Schloss markiert und unlöschbar

  1. Marc sagt:

    die UAC ist Fluch und Segen, denn teilweise ist das "gelieferte Handwerkszeug" (hier Explorer) einfach nicht perfekt ausgestattet um Fehler zu korrigieren.

    • Rudolf Posselt sagt:

      Vielleicht macht Microsoft Windows 7 mit Absicht schlechter um dann das neue Windows 10 besser verkaufen zu können.
      Ich habe 2 PC`s nach einem Update hatten auf der Externen Festplatte auf einmal alle Ordner das Schloß und die Sicherung dauert nun wesentlich länger als vorher. Wenn ich diese Ordner öffnen möchte muß ich mit Administratorenrechten erst eine zusätzliche Bestätigung eingeben. Bei dem PC ohne Windows Update ist diese Einschränkung nicht vorhanden. Warum warnen die Fachzeitschriften nicht vor den Windowsupdates. Im Gegenteil sie empfehlen sie um Sicherheitslücken zu schließen ? Der Sicherheitswahn macht Windows immer langsamer. Man kann schließlich externe Festplatten zur Sicherheit in einen Tressor einsperren und virtuelle Schlösser sind daher unnötig und man sollte sie nicht allen Kunden ungefragt aufzwingen. Ich bevorzuge einen schnelleren PC. Ich hoffe, daß die Computerzeitschriften diesen Sicherheitsirrsinn endlich aufgreifen und mitteilen wie man diesen wieder abschalten kann. Rudolf Posselt

      • Günter Born sagt:

        @Rudolf: Hier laufen meine Produktivsysteme mit voll gepatchten Windows 7 Installationen. Deine Vermutungen sind in keinster Weise nachvollziehbar – und schau mal auf das Datum meines Blog-Beitrags. Im Januar 2014 hatte niemand Windows 10 auf dem Radar. Irgend etwas werkelt bei dir auf dem System, was die Zugriffsberechtigungen entzieht oder anpasst. Updates sind dies imho nicht, da Zugriffsberechtigungen auf NTFS-Ebene wirken.

  2. Peter Schirmer sagt:

    Nach dem dritten fehlgeschlagenen Versuch in der grafischen Oberfläche hätte ich den Holzhammer ausgepackt und von der DVD gebootet.

    Von dort aus in die Kommandozeile und den Ordner gelöscht. Mache ich auch so manches mal, wenn ein Experiment daneben gegangen ist. :-)

    Vorteil bei deiner Methode: Man bleibt stets in der grafischen Oberfläche und muss nicht Kommadozeilenschalter lernen.

  3. Helmut sagt:

    Moin

    Scheint dann vielleicht ein bestimmtes Update, oder ein Updatefehler Resultat unter 7 zu sein… ich kann mich erinnern, das ich so einen sturen Ordner auch mal auf einer Partition gefunden habe.
    Vielleicht ein Überbleibsel, wenn auf dem Windows Laufwerk nicht ausreichend Platz beim Windows Update ist und das Laufwerk für die temporären Dateien gewechselt und dann abschließend nicht sauber gelöscht wird? Ich habs jedenfalls so eingeordnet.
    Ist auch nur einmal vorgekommen.

    Ich hab seinerzeit den Weg über die Vista DVD genommen und über die Eingabeaufforderung gelöscht, wenn ich mich recht erinnere… oder doch per Linux Live-System? Ist schon etwas her…

  4. Ralf Buschner sagt:

    Solche Operationen gelingen meist auch recht gut mit einem Linux vom USB-Stick – dem konnte das NTFS bislang kaum etwas entgegensetzen…

  5. Pegasus sagt:

    Oder anstelle solcher Rechtebasteleien gleich nach Win PE booten. Von dort aus lässt sich praktisch alles widerstandslos löschen, was in Windows selbst mit Systemrechten nicht machbar war.

  6. Eintracht sagt:

    Hallo Günter,

    Danke für diesen Beitrag. Wäre es mit dem Befehl

    psexec -i -s cmd.exe

    nicht einfacher gegangen? Meines Wissens bist Du mit dem vorgenannten Befehl System.

    • Günter Born sagt:


      @Eintracht: Möglicherweise – und die anderen Poster haben ja auch auf Linux-Sticks hingewiesen. Aber …

      … dann hätte ich a) keinen Ansatz für diesen schönen Blog-Beitrag gehabt – b) ist der Beitrag ja als "One-Shot"-Ansatz entstanden (wie oft hat man diesen Glücksfall, und wenn dat Ding gelöscht ist, ist nichts mehr mit Alternativen versuchen) und c) gibt es halt auch Leute, die einfach nichts mit der als System laufenden Eingabeaufforderung anfangen können.

      Ich sitze gerade in Videostudio bei vide2brain und habe gerade in einem aktuellen Video festgestellt: Wenn ich Windows im abgesicherten Modus boote und dann eine Anmeldung am Administratorkonto vornehme, habe ich auch Zugriff auf die üblichen Ordner, ohne dass die Benutzerkontensteuerung hochkommt. Dort läuft der Explorer offenbar mit administrativen Credentials. Hätte möglicherweise auch geholfen.

      Nochmals danke an Alle für die hilfreichen Kommentare.

      Gruß aus dem verschneiten Graz.

  7. Joni sagt:

    Vielen Dank! Die Ochsentour über die Dörfer mit dem ausführen des Explorer++ über PsExec hat gut funktioniert.

    Joni

  8. Dilbert sagt:

    Ich habe dieses Problem auch auf diveresen Arbeitsplätzen und Servern.
    Ich könnte mir vorstellen, dass es auch einen Registry Schlüssel um den Speicherort dieser Ordner anzugeben, da könnte man wenigstens diese irgendwo im Unterverzeichniss sammeln. Das Problem mit dem Löschen habe ich auf einigen Systemen (Windows 7, Windows 2012 R2) nicht.

  9. Jürgen Wondzinski sagt:

    Diese Update-Überbleibsel hab ich schon des Öfteren auf Kundenrechnern vorgefunden. Wegbekommen hab ich sie immer auf die Weise, dass ich den BESITZ übernommen habe. Also: Ordner-Eigenschaften / Sicherheit / Erweitert / ganz oben: Besitzer Ändern. Da dann sich selbst zuweisen.

  10. Markus sagt:

    Das mit den "Authentifizierten Benutzern" ist auch nur die halbe Wahrheit. Im Normalfall sind die eigentlich überhaupt nicht Teil der Berechtigungen. Wenn es ein reines Berechtigungsthema wäre, dann sollte es reichen, den "Benutzern" oder direkt seinem angemeldeten Benutzeraccount Schreibrechte zu geben (Vollzugriff ist eigentlich gar nicht nötig), damit man einen Ordner löschen kann. Woher genau das Schloss kommt, habe ich leider auch noch nicht rausgefunden.

    Ich mache das mit dem Löschen mittlerweile auf die harte Tour. Man wird den Ordner samt Inhalt am einfachsten los, indem man ihn in einen Unterordner schiebt, einen leeren Ordner anlegt, eine Kommandozeile mit "Als Administrator ausführen" startet und dann mit robocopy /s /e /mir /b einfach den Ordner samt Inhalt durch Robocopy im Backup-Mode killen lässt. Der Methode hält nur sehr wenig stand, da Robocopy dann mit SYSTEM-Rechten agiert.

    Den Explorer kann man übrigens sehr wohl als Administrator starten: Im Task Manager die Explorer.exe killen und dann über das "Ausführen"-Fenster des Task Managers die Explorer.exe mit dem Haken "Diesen Task mit Administratorrechten erstellen" ausführen. Dann hat der Explorer insgesamt, auch als Shell, Administratorrechte. Hilft gegen die UAC, aber nicht gegen das Schloss…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.