Warum würde dsenableroot NICHT auf einem 10.7.5 OSX Server funktionieren?

Also möchte ich Root aktivieren ... Ich habe es unter /System/Library/Core Services/Directory Utility versucht (dh "Root aktivieren ...").

Das Problem ist, dass root (oder "andere") niemals eine Anmeldeoption wird ... und es mir auch nicht erlaubt, als root in die Box zu gelangen ...

Wenn ich im Terminal dsenableroot versuche, bekomme ich:

'dsenableroot:: ***Failed to enable root user.'

Wenn ich versuche zu DEAKTIVIEREN (dseneable -d) .. bekomme ich:

'dsenableroot:: ***Failed to disable root user.'

Irgendwelche Gedanken?

Ich sollte erwähnen, dass dieser Server zuvor mit ssh "als root" verwendet wurde - er scheint auf mysteriöse Weise die Fähigkeit für andere Systeme im Netzwerk verloren zu haben, ihn zu sehen oder sich als root einzuloggen.

Bearbeiten: Bitte verschwenden Sie keine Bandbreite, um mich von einer Problemumgehung auf Client-/Benutzerebene zu überzeugen. Ich bin ein leitender Netadmin und kann meine Big-Boy-Hosen tragen. Ich habe in den letzten 2 Jahrzehnten, in denen ich als Root operierte, erfolgreich meine dutzenden Server NICHT auf Vordermann gebracht.

Dies ist ein Back-End-Support-Server, der in einer DMZ sitzt und ein bestimmtes Appliance-Paket ausführt – es wird nicht aktualisiert, wird nicht offengelegt, und nein, ich habe nicht die Absicht, im nächsten Jahrzehnt auf ein neueres Betriebssystem zu aktualisieren. Tatsächlich habe ich 2 Ersatzserver daneben sitzen, falls/wenn dieser Server stirbt, um ihn sofort zu ersetzen.

Ich würde lieber nur wissen, wie das vorliegende Problem behoben werden kann, nämlich dass dieser 10.7.5-Server Root nicht aktivieren kann ...

Warum dann nicht als normaler Benutzer per SSH einloggen sudooder die sudoers-Datei verwalten, um Ihrem ausgewählten Benutzer Root-Berechtigungen für ausgewählte Skripte und Tools zu gewähren?
Danke für den Hinweis. Vielleicht hätte ich diese Frage vorab beantworten sollen. Die kurze Antwort lautet: NEIN, ich gebe nicht auf etwas anderes als das Aktivieren von Root einen rosa Hintern. Ich habe etwa 12 oder 13 Server und einer von ihnen kann Root nicht aktivieren. Und ich würde es vorziehen, den eigentlichen Root-Zugriff zu haben, was für Serveradministratoren ziemlich üblich ist. Klebeband interessiert mich nicht. Ich bin nicht an der Verwendung auf Clientebene interessiert. Ich muss root betreiben und root wie beabsichtigt aktivieren.
Sind die anderen Server auch 10.7.5 oder nur diese bestimmte Box?
Nenn mich nicht Nazi - ich bin schon Deutscher...
Ich habe einige 10.6, andere 10.7, andere 10.8, 10.9 usw. ... es variiert ... Vor ungefähr 12-15 Wochen funktionierte die SSH-Anmeldung einwandfrei ... und ich habe keine Updates oder größere Änderungen vorgenommen. .. es wurde einfach keine Option mehr und mein ssh (als root) funktionierte nicht mehr ... Ich kann problemlos als jeder Admin-Benutzer ssh, kann 'sudo', aber KANN mich NICHT als root anmelden, noch kann ich desenable root erfolgreich ausführen. ..
In der Anwendung „Verzeichnis-Dienstprogramm“ gibt es unter dem Menü „Bearbeiten“ einen Eintrag für „Root-Benutzer aktivieren“ oder „Root-Benutzer deaktivieren“ (direkt unter „Root-Passwort ändern …“) Beachten Sie, dass diese normalerweise nur ungrau werden Wenn das Vorhängeschloss im Fenster des Verzeichnisdienstprogramms geöffnet wird Sind diese Elemente auf Ihrem 10.7-Computer immer noch ausgegraut, selbst nachdem Sie das Vorhängeschloss entsperrt haben?
"Root-Passwort ändern" und "Root diable" sind beide verfügbar (beide sind nicht ausgegraut). Ich habe versucht, "Root zu deaktivieren", dann den Server neu zu starten (und dann später wieder zu aktivieren), aber es scheint so zu sein nutzlos .. Mit anderen Worten, das System DENKT, dass root aktiviert ist ... Wenn ich jedoch versuche, 'su' zu verwenden, fordert es zur Eingabe des Passworts auf, antwortet jedoch sofort mit "su: Sorry" ... All dies ist natürlich der Fall nur symptomatisch für die Tatsache, dass dsenableroot beim Aktivieren oder Deaktivieren fehlschlägt ...

Antworten (3)

Versuch: sudo dscl . -passwd /Users/root PASSWORD. Sonst: Ein Bit-Flip hat Ihre Festplatte getroffen und Ihre Directory Services-"Datenbank" genau dort beschädigt, wo sich normalerweise die Daten des Root-Benutzers befinden. Überprüfen Sie dies mit den üblichen Tools wie dscl oder kopieren Sie sogar die root.plist:

sudo cat /private/var/db/dslocal/nodes/Default/users/root.plist >  ~/Desktop/root.plist

Die standardmäßige root.plist mit deaktiviertem Root sieht so aus:

Geben Sie hier die Bildbeschreibung ein

Die root.plist mit aktiviertem root (alle Hashes redigiert etc.):

Geben Sie hier die Bildbeschreibung ein

Darf ich fragen, wie Sie eine textbasierte Version der .plist-Datei erhalten konnten? und welche software hast du verwendet? Ich frage nur, weil ich auf die gleichen Probleme wie das OP gestoßen bin und die von Ihnen vorgeschlagenen Schritte durchlaufen habe und ein anderes Format erhalten habe ... Nicht so klar wie Ihres.
@Xertiem Die App ist Xcode.

Nun, es scheint, dass der Server tiefere Probleme hatte – das SSD-Laufwerk begann einen frühen Ausfall, und soweit ich das beurteilen kann, beschädigte die Datenbank der Verzeichnisdienste … mehrere Stunden nach der Arbeit daran verlor ich ALLEN Kontozugriff (alle Benutzer würden nicht mehr anmelden), und schließlich stürzte es ab ...

TimeMachine ist eine tolle Sache.....

Ich habe die Lösung hier gefunden: Aktivieren Sie den „Root“-Benutzer im Einzelbenutzermodus in Mac OS X

  • Halten Sie gedrückt ⌘-S, während Sie das Gerät einschalten, das System startet dann im Einzelbenutzermodus
  • Typ

    /sbin/fsck -fy
    /sbin/mount -uw /
    launchctl load /System/Library/LaunchDaemons/com.apple.opendirectoryd.plist
    passwd root
    reboot
    

Der Mac wird jetzt neu gestartet und führt Sie zum Anmeldebildschirm. Melden Sie sich als Root-Benutzer am Mac an und verwenden Sie das im obigen Schritt festgelegte Kennwort.

Ein zusätzlicher Schritt, den Sie unternehmen können, um zu bestätigen, dass der Root-Benutzer angemeldet ist, besteht darin, die Benutzer & Gruppen in den Systemeinstellungen zu überprüfen. Der angemeldete Benutzer sollte Systemadministrator angeben