Warum meldet chown unter OS X "Betrieb nicht erlaubt"?

Ja, Mac hat viele Erweiterungen zu Unix im Bereich der Dateien. Ignoriert man die ganze resource fork Sache, die nicht mehr viel benutzt wird, gibt es:

• die Standard-Unix-Berechtigungen ugo rwx und so weiter. Es gelten die normalen Unix-Werkzeuge.
• ACL‘s, einsehbar mit ls -le und änderbar mit chmod [-a | +a | =a].
• Dateiflags, anzeigbar mit ls -lO (Großbuchstabe oh, nicht Null) und änderbar mit chflags.
• erweiterte Attribute , anzeigbar mit ls -l@ (nur Attributschlüssel) und anzeigbar und änderbar mit xattr. (Verwenden Sie xattr -h für die Hilfe, wenn man xattr Ihnen nichts gibt.)
• Beginnend mit OS X 10.11 “El Capitan”, * System Integrity Protection ** (SIP) schützt einige Dateien weiter vor Änderungen durch normale Prozesse, auch wenn Sie sudo verwenden, um als root zu laufen. Dateien, die durch SIP geschützt sind, werden von ls -lO als mit dem Flag restricted und/oder als mit dem Attribut ls -l@ aufgeführt.

Operationen an einer Datei können Ihnen aufgrund von Unix-Berechtigungen, ACLs, Dateiflags oder SIP verweigert werden. Um eine Datei vollständig freizugeben:

sudo chmod -N file # Remove ACLs from file
sudo chmod ugo+rw file # Give everyone read-write permission to file
sudo chflags nouchg file # Clear the user immutable flag from file
sudo chflags norestricted file # Remove the SIP protection from file
sudo xattr -d com.apple.rootless file # Remove SIP protection from file

Wenn der Systemintegritätsschutz (SIP) aktiviert ist, geben com.apple.rootless und sudo chflags norestricted auch den Fehler “Operation nicht erlaubt” zurück. Um das Flag und/oder das Attribut zu löschen, müssen Sie in macOS Recovery booten und entweder die Befehle vom Terminal aus ausführen (möglicherweise müssen Sie zuerst das Festplattendienstprogramm verwenden, um Ihr Boot-Laufwerk zu entsperren und zu mounten, dann denken Sie daran, dass Ihre Dateien unter sudo xattr -d com.apple.rootless oder wie auch immer Ihr Boot-Laufwerk benannt ist, liegen) oder SIP insgesamt deaktivieren und dann neu starten und die Befehle sollten dann funktionieren. Seien Sie sich jedoch bewusst, dass zukünftige Betriebssystem-Updates wahrscheinlich das /Volumes/Macintosh HD-Flag und das restricted-Attribut für alle Dateien wiederherstellen werden, aus denen Sie es entfernt haben.

_ Das Deaktivieren von SIP wird nicht empfohlen _, da es einen Großteil des Schutzes vor Malware und versehentlicher Beschädigung aufhebt, außerdem ist es nicht notwendig, wenn Sie den Schutz einfach auf Dateibasis entfernen können. Wenn Sie SIP deaktivieren, aktivieren Sie es wieder, wenn Sie mit den Änderungen fertig sind.

Beachten Sie, dass Sie, wenn com.apple.rootless anzeigt, dass das Flag ls -lO gesetzt ist, in den Einzelbenutzermodus wechseln müssen, um es wieder zu deaktivieren. Ich werde hier nicht näher darauf eingehen, da es wichtigere Fragen darüber gibt, warum die Datei dieses Flag gesetzt hat und warum Sie versuchen, daran herumzupfuschen, und was die Konsequenzen sein werden.

Ich hatte das gleiche Problem. Es stellte sich heraus, dass die beanstandeten Dateien vom Betriebssystem als “Gesperrt” markiert waren. Ich fand diese Lösung und sie löste die Probleme in Sekunden: http://explanatorygap.net/2005/07/10/unlocking-files-recursively-from-the-command-line/

Es scheint, dass sich der Befehl rm in Tiger so verändert hat, dass er die Dateien automatisch entsperrt, wenn Sie rm -Rf mit erhöhten Rechten verwenden.

In OS X vor Tiger: find /Volumes/Transit -flags +uchg -print0 | xargs -0 chflags nouchg

In OS X nach Tiger: sudo rm -Rf foldername/

Außerdem kann es auch nach OS X 10.4 Dateimetadaten-Flags wie uchg und uappnd geben, die jede Änderung der Dateirechte oder des Besitzes verhindern. chflags kann die Flags entfernen. Einige der Dateiattribute/Metadaten und wie sie von verschiedenen Kopierwerkzeugen gehandhabt werden, sind hier .

In OS X 10.11 (El Capitan) kann dies auch durch die neue Funktion Rootless verursacht werden. Siehe diese Antwort für eine Erklärung.

Kurz gesagt, für bestimmte wichtige Verzeichnisse gibt es keine Möglichkeit, sie zu ändern - egal ob Sie sudo, chown oder chmod verwenden. Dies betrifft das Verzeichnis /usr, (obwohl Sie /usr/local ändern dürfen).

Um ein Rootless-geschütztes Verzeichnis zu ändern, müssen Sie Rootless deaktivieren . Und natürlich müssen Sie es nach Ihren Änderungen wieder aktivieren, da es eine wichtige Sicherheitsverbesserung ist.

Ich hatte das gleiche Problem mit der Crashplan.app.

Alle hier aufgelisteten Lösungen halfen mir nicht, aber diese hier hat es geschafft http://forums.macrumors.com/showthread.php?t=1546163

Sie müssen die System- und Benutzer-Immutable-Flags ändern:

Tun Sie dies, um zu sehen, welche Flags für Ihre Datei/Ordner aktiv sind:

ls -lhdO MyFile

Die Antwort könnte wie folgt aussehen:

drwxrwxr-x 3 root admin schg,uchg 102B Apr 8 2013 MyFile

schg , uchg sind die unveränderlichen Flags. Einer für das System und einer für den Benutzer. Um sie zu entfernen, gehen Sie wie folgt vor:

chflags noschg CrashPlan.app # this removes system immutable flag
chflags nouchg CrashPlan.app # this removes the user immutable flags

Dann ist, zumindest bei mir, die Datei freigeschaltet und Sie können sie löschen!

Nach langem Hin und Her musste ich folgendes tun, um das Problem zu beheben:

• Verschieben der Datei nach ~/Desktop
• sudo chown myusername:staff ./entries
• Zurückschieben der Datei an den ursprünglichen Ort funktionierte nicht (Operation nicht erlaubt, wieder), also…
• sudo rm ./entries
• sudo mv ~/Desktop/entries ./entries

Ich hatte das gleiche Problem, mit meinem Home-Ordner. Am Ende habe ich einfach den Finder wie folgt benutzt:

Gehen Sie -> Computer -> Ihr Laufwerk -> Benutzer -> Ihr Benutzername -> Rechtsklick -> Get Info

Ich fand heraus, dass es gesperrt war, wahrscheinlich habe ich es in der Vergangenheit gemacht und vergessen. Deaktivieren Sie das Kontrollkästchen “Gesperrt”, das Problem ist behoben.

Ich kann die Verwendung von “Get Info” aus dem Finder empfehlen, um diese Art von Problemen zu lösen.

(OS X 10.8.3)

Stellen Sie sicher, dass sowohl die Datei als auch ihr übergeordneter Ordner entsperrt sind

Ich stand vor einem ähnlichen Problem, als ich versuchte, eine Mac Mail E-Mail-Signaturdatei zu löschen. Ich konnte sie nicht löschen, bis ich sowohl die Datei als auch den übergeordneten Ordner entsperrt hatte.