Ungültige Sicherheitskennung für Dateien ...

1. offizieller Beitrag

    Gestern hatte ich ein Erlebnis der mehr unerfreulichen Art mit Windows 2000.


    In meinem Serverchen meidete ein Y-Stromverteiler plötzlich den Kontakt und zwei wichtige Platten blieben stehen. Nach dem Auswechseln des Y-Stromverteilerkabels hatte ich vorsichtshalber einen Checkdisk laufen lassen beim Neustart, um eventuellen Verlusten vor zu beugen.


    Und genau damit kam ich richtig in die Sch.....


    ChkDsk behob einige Kleinigkeiten und meinte dann:


    "Ungültige Sicherheitskennung für Datei <Nummer> wird durch standardmässige Sicherheitskennung ersetzt."


    Als das dann nach 230.000 Dateinummern und über eine Stunde später zu Ende war, klappte die automatische Anmeldung nicht mehr, weil das Benutzerprofil angeblich nicht gefunden wurde.


    Dass ich mit gedrückter Shift-Taste beim Boot die Anmeldmaske erzwingen kann, fiel mir leider erst viel später wieder ein, nachdem ich auf der Reparaturkonsole herumgeturnt war.


    Fakt war, daß bis auf den Administrator-Account bei allen Benutzern komplett die Rechte weg waren ebenso wie bei allen Verzeichnissen und Dateien.


    Nachdem ich die Rechte wieder einigermassen hingebogen hatte, damit der Server wieder lief, kam dann der Download vom SFK, der hängenblieb. Da bin ich dann schlafen gegangen.


    Heute dann hatte ich auf dem Weg zum Kunden bei ca. 100 km/h plötzlich einen platten Reifen am Auto, der zum Glück schnell und preiswert geflickt wurde.


    Am nachmittag gabe es dann wieder Probleme mit den Rechten am Server und ich machte erstmal ein frisches Image und spielte danach ein mit Acronis 8 erstelltes älteres Image zurück und klickte hierbei die Überprüfung nach Wiederherstellung an. (ein etwa gleichaltriges von DriveImage hätte erst wieder Änderungen an der Partition bedeutet).


    Dass die auch nur CHKDSK starten war mir nicht bewußt. Nach der berühmten Stunde und 230.000 Dateien weiter, habe ich dann das Image gleich nochmal reingezogen, mit einigen Dateien aus dem Image vom gleichen Tag, und die ganzen WIndows-Updates ab Januar dazu eingespielt.


    Jetzt die Frage an die True-Image Experten.
    Kann das an True-Image liegen, daß da die Benutzerrechte total daneben sind ?
    Sowas hatte ich früher im DriveImage noch nie.

    Hi,


    >>Kann das an True-Image liegen, daß da die Benutzerrechte total daneben sind ?<<


    könnte ich mir nicht erklären, warum.


    Ich vermute eher, dass Du zum Zeitpunkt der Imageerstellung bereits ein irgendwie verbogenes Windows hattest und CHKDSK will das bereinigen.


    Ich lasse vor der Imageerstellung immer ein CHKDSK über die Partitionen laufen und defragmentiere.


    Gut, dass Dir beim Reifenplatzen nichts passiert ist. Das wäre dramatischer.


    Happy day vom
    Tom

    • Offizieller Beitrag

    Hi Martin


    Auch ich kann mir das nicht vorstellen. Denn meine zurückgespielten Images haben immer die richtigen Benutzerrechte zurückgebracht, bzw. beibehalten. Wie das allerdings bei Servern ist....keine Ahnung.


    Gratuliere Dir, dass Dir nichts passiert ist, beim Reifenplatzer. Aber hoffentlich wurde der Reifen repariert, und nicht geflickt, sonst passiert Dir das schon bald wieder. :wink:


    Mit freundlichen Grüssen
    Edi

    Freundlichkeit ist ansteckend


    Wenn die Trümmer des Flugzeuges in der Pistenachse liegen und der Pilot aus eigener Kraft im Restaurant ein Bier bestellen kann, ist die Landung als gelungen zu betrachten. :feixen:

    Zum Reifen,


    Da muss auf der Landstrasse was gelegen haben. Jedenfalls knallte es im Radkasten hinten rechts und das Laufgeräusch veränderte sich minimal. Dem Auto war sonst nichts anzumerken (Mazda Tribute).


    Deshalb habe ich sicherheitshalber angehalten und habe dann das schicke Notrad montieren dürfen.


    Mitten auf der Lauffläche ein Loch, wo der zarte kleiner Finger einer Dame reinpasst.


    Heutzutage wird da nicht mal mehr der Reifen demontiert, sondern nur noch mit einem Spezialwerkzeug eine Art Streifen mit einer klebrigen Flüssigkeit in das Loch gepresst und gleichzeitig Luft auf den Reifen gegeben.


    Dauerte insgesamt 10 Minuten.


    Zum Rechner:
    "Server" ist mein Begriff, weil er die anderen "bedient" - ansonsten ist das ein stinknormaler W2K-PC, der mit Hintergrund-Priorität läuft mit rund 750 GB Plattenkapazität, meine 3 Drucker steuert, 2 Netzkarten hat und noch ein Faxmodem dran. Ausserdem läuft da noch der Janaserver drauf als Proxy zm Internet, Emailserver und HHTP-Server fürs lokale Netz sowie Firewall und Virenscanner.


    Das war der Rechner, der beim BIOS Update eingegangen ist und dadurch kurzzeitig sein altes 233 MHz Motherboard wieder mal gesehen hat :)


    Wie auch immer - ich denke auch, daß das Problem schon länger existiert. Ich werde mal mit einem Tool schauen, wie die SID's zu den Usern bzw. umgekehrt ausschauen und ob ich da noch was retten kann.
    Ansonsten hilft wirklich nur eine frische Installation von Windows mit allem was dazu gehört.

    Hi Martin,


    wenn du das erste Mal von einem zurückgespielten Image bootest, kann es sein, das Windows die anderen Platten nach vorhandenen SID's durchsucht, und die im neu bootenden dann umbenennt.


    Folge: Da die Berechtigungen an den Dateien hängen, passen die SID's nicht mehr.


    Dieses Problem tritt nur auf Systemen mit definierten Benutzerkonten und eingeschränkten Benutzerrechten auf.


    Teste also nochmal das Zurückspielen des Images, ohne das noch weitere Platten beim Booten sichtbar sind, zuerst dann als Administrator anmelden, anschliessend als normaler User, dann wieder herunter- und mit den restlichen Platten wieder hochfahren.


    Bei mir hatte es geholfen.


    Gruss Fred

    Ich vermute mal, dass TI nicht die Sektoren original wiederherstellt. Wenn doch, wäre das eine Ursache, nämlich, dass dein Platte das Zeitliche segnet. Hast Du mal mit Drive-Sitter oder so den Smart-Status überprüft ?
    Wenn's da Probleme gibt, ist 'ne Grundformatierung fällig ( und eine gehörige Portion Misstrauen gegenüber der Platte ). Sonst kommt es immer wieder zum Einsatz von Chkdsk.
    Zum Reifen : Wenn ich mich nicht irre, ist die beschriebene Reparaturmethode schon seit langem verboten. Ich hoffe, Du hast keinen H-Reifen reparieren lassen, da ist reparieren überhaupt verboten, bei allen anderen darf nur noch Vulkanisiert werden, und das dauert mindestens eine Stunde.
    Ein Fingerdickes Loch darf so oder so ( nicht mal bei einem Fahrradreifen ) repariert werden. Limit ist ein dicker Nagel.


    E.Z.

    Hi,


    >>Ich vermute mal, dass TI nicht die Sektoren original wiederherstellt<<


    lt. Hersteller werden nur die belegten Sektoren im Image abgebildet (ist ja auch sinnvoll, sonst würde auch der unbelegtePlatz im Image liegen).
    Wenn nun allerdings die Sektoren bereits fehlerhaft addressiert sind, oder soinstwie derWurm drin ist, wird das natürlich im Image genauso abgebildet.


    Das mit den zusätzlichen Platten stimmt bedingt. Wenn ich, egal ob ich ein Image zurückgespielt habe oder aus einen bereits tagelang laufendem System, dem PC eine neue FP spendiere, muss die erst eingebunden werden.


    zum Reifen: da Ecki es angesprochen hat: ich hoffe auch nicht, dass Du mit einem geflickten Reifen länger fährst, als der Händler einen neuen besorgt hat.
    Bei meinem Exoten (Ford Explorer) hatte ich auch mal einen Nagel im Reifen. Ich musste dann drei Tage mit einem geflickten Reifen fahren, weil die Reifengröße und das Fabrikat nicht eher verfügbar war. Das mulmige Gefühl in der Magengegend werde ich wohl nie vergessen.


    Happy day vom
    Tom

    Hi Tom - hi E.Z,


    ich habe Martin eigentlich so verstanden, das nicht seine Dateien verletzt sind - da würde die Sektorierung auf der Platte eine Rolle spielen, sondern die an den Dateien hängenden SecurityIDentifier (SID's), mit der die Berechtigungen verwaltet werden.
    "Verletzungen" an den SID's nimmt nur jemand war, der nicht den von Windows normalerweise einzigen User, der dann auch immer Administrator ist, anlegen lässt, da nur der Administrator und der Gast auf allen Rechnern die gleiche SID bekommt.


    Wenn ich das damals bei meinem Crash richtig beobachtet habe, versucht Windows nach einem ImageRückspielNeustart auf allen vorhandenen Platten bestehende SID's dem restaurierten System zuzuordnen.
    Nur wenn keine SID's zu finden sind, wird repariert.


    Wenn, wie damals bei mir, beim ersten ImageRückspielNeustart die alte Platte noch vorhanden ist, beim nächsten Boot aber nicht mehr, kommt Windows durcheinander.


    Ob das System Client oder Server ist, spielt dabei keine Rolle, die Platte muß nur NTFS formatiert sein.


    Beispiel für eine SID: S-1-5-21-124440339-167723038-725XXXXXX-XXXX


    Gruss Fred

    Hi,


    >>Wenn, wie damals bei mir, beim ersten ImageRückspielNeustart die alte Platte noch vorhanden ist, beim nächsten Boot aber nicht mehr, kommt Windows durcheinander.<<
    stimmt,
    das ist aber unabhängig vom Image.


    Wenn ich eine neue NTFS-Platte (per Wechselrahmen) hinzufüge, erfordert das immer einen Neustart.
    Ist die Platte dann aber einmal "erkannt" , muss diese Prozedur nicht wiederholt werden.


    Happy day vom
    Tom

    @schipseldepp


    Zitat

    Dieses Problem tritt nur auf Systemen mit definierten Benutzerkonten und eingeschränkten Benutzerrechten auf.


    Spannend,


    genau so war es. Die Daten sind in Ordnung.


    Das Image wurde mit Benutzerrechten (aber TrueImage als Admin gestartet) erstellt, aber von einer anderen Bootpartition aus (Servicepartition, kennt nur Admin) zurückgespielt und direkt danach innerhalb von TrueImage ohne Neustart die Diskprüfung ausgeführt, was zum Problem führte.


    Die SID's sind alle da, aber möglicherweise unterschiedlich zwischen den beiden Bootpartitionen. Auch der gegenseitige Test mit SID2User und User2SID bringt auf der betroffenen Partition die richtigen Ergebnisse, liefert also zum User die richtige Kennung und SID, umgekehrt liefert die Kennung und SID den richtigen User zurück.


    Admin und Gast laufen unter 5 21 xxxx 500 bzw. 501,
    die angelegten User unter: 5 21 xxx 1000 bzw 1001


    Die eigentliche SID dazwischen ist immer gleich


    Die Gruppen selber haben ja kein SID sondern nur die Kennung:
    Benutzer 5 32 545
    Hauptbenutzer unter 5 32 547
    Administratoren 5 32 544


    Auf die Servicepartition habe ich noch nicht geschaut, ob die die gleiche SID hat.