Ich habe SIP deaktiviert, ich habe Lese-/Schreibrechte mit Terminal, aber nicht mit Finder. Was verursacht das?

Betriebssystem: macOS Catalina 10.15.2

Hintergrund: Ich bin seit vielen Jahren *nix-User. Ich verwende einen Remote-Linux-Server, auf dem das Stammverzeichnis verwendet wird (dh es gibt Ordner, in denen Benutzer r/w wie /data und /analyses können), und ich habe macOS bisher auf die gleiche Weise verwendet. Ich habe dieses Jahr ein neues MacBook von meinem Arbeitsplatz bekommen. Ich administriere die Maschine, also kann ich alles ändern, was Root kann.

Im Interesse der weiteren Verwendung des Dateiorganisationssystems auf unserem Remote-Server habe ich SIP deaktiviert und mounte / mit Lese-/Schreibzugriff bei jedem Start (ähnlich wie hier ) . Ich kann mit dem Terminal problemlos in den Ordnern /dataund arbeiten , aber wenn es um die Verwendung von Finder geht, ist dies nicht der Fall. /analysesDas Erstellen und Löschen von Ordnern und Dateien ist mit Finder nicht möglich. Dies ist bei anderen GUI-Apps nicht der Fall (zum Beispiel kann ich einen Texteditor wie Sublime verwenden, um reine Textdateien in diesen Ordnern zu bearbeiten oder neue zu erstellen und in einem Verzeichnis meiner Wahl zu speichern).

Problem: Wenn ich den Finder verwende, um diese Dateien zu verschieben oder zu ändern (z. B. eine Datei in den Papierkorb zu ziehen), erhalte ich eine Warnmeldung: "file" can't be modified or deleted because it's required by macOS. Ich kann diese Dateien mit anderen Apps löschen oder ändern, einschließlich Terminal, aber der Einfachheit halber hätte ich gerne Hilfe bei der Suche nach einer Lösung für dieses Problem mit Finder (z. B. gibt es etwas, das ich mit den Berechtigungen von Finder ändern könnte, oder mit den von macOS festgelegten Berechtigungen für die Verzeichnisse, in denen ich arbeite).

Was ich bereits versucht habe: Ändern der Datei- und Ordnerberechtigungen/Eigentumsrechte mit chmodund chown, ohne Auswirkung auf das Verhalten des Finders

ps Sofern Sie nicht sicher sind, dass es direkt hilft, dieses Problem mit dem Finder zu lösen, danke ich Ihnen im Voraus, dass Sie alle Vorträge darüber, warum ich SIP wieder aktivieren sollte, auslassen, ich habe sie bereits alle gehört. :)

Die kurze Antwort lautet: Es ist beabsichtigt (oder sollte ich sagen, fehlendes Design) und Sie können es nicht ändern! Wenden Sie sich an Apple unter: Produkt-Feedback
@ user3439894 Ich würde dies gerne als Antwort akzeptieren, wenn Sie es als eine schreiben, mit etwas ausführlicherer Erklärung, warum dieses Verhalten nicht geändert werden kann
Ich müsste zurückgehen und die Recherchen wiederholen, die ich durchgeführt habe, als macOS Catalina verfügbar wurde, um maßgeblichere Quellen finden zu können. Die kurze Antwort darauf, warum der Benutzer es nicht ändern kann, lautet jedoch, weil es sich um einen Hardcoder im Quellcode von Finder handelt . Genau wie beim Ändern der Einstellung, um das Anzeigen versteckter Ordner zuzulassen, erlaubt Apple nicht, im Finder anzuzeigen oder Sie mit ⇧⌘G ( Gehe zu Ordner… ) dorthin zu führen, und es gab eine Zeit, in der sie das getan haben, aber jetzt Es ist im Quellcode fest codiert, so dass man es nicht kann. /dev
@ user3439894 danke, das ist im Grunde alles, was ich wissen musste. ob es möglich ist und ungefähr warum. schätze dein Fachwissen!
Übrigens gibt es eine kostenpflichtige App namens Path Finder , die eine kostenlose Testversion hat und ein Dateimanager für macOS ist . Sie könnten es versuchen und sehen, ob Sie die Dinge tun können, die Sie wollen, die der Finder nicht kann. (Ich bin nicht mit dem Entwickler dieses Produkts verbunden.)

Antworten (2)

Wenn Sie Verzeichnisse außerhalb des Stammverzeichnisses erstellen müssen, ist die beste Option die Verwendung von Firmlinks, die mit konfiguriert werden können /etc/synthetic.conf. Von der Handbuchseite:

...
synthetic.conf is intended to be used for creating mount points at / 
(e.g. for use as NFS mount points in enterprise deployments) and symbolic
links (e.g. for creating a package manager root without modifying the
system volume).  synthetic.conf is read by apfs.util(8) during early sys-
tem boot.
...

Wenn Sie /dataund /analyseswoanders erstellen und die Links dann von verwalten lassen synthetic.conf, sollten Sie in der Lage sein, das Deaktivieren von SIP zu vermeiden und über den Finder auf diese Verzeichnisse zugreifen zu können.

danke, ich schätze, dass dies meine Frage anders als in früheren Kommentaren und direkter als die andere formelle Antwort behandelt. Ich werde dies als akzeptierte Antwort markieren.

Ich verwende einen Remote-Linux-Server, auf dem das Root-Verzeichnis verwendet wird (dh es gibt Ordner, in denen Benutzer r/w können, wie z. B. /data und /analyses ) ... Im Interesse der weiteren Verwendung des Dateiorganisationssystems auf unserem Remote-Server, Ich habe SIP deaktiviert und mounte / mit Lese- / Schreibzugriff bei jedem Start

Dies ist keine gute Strategie und sollte vermieden werden.

Das erste und wichtigste, was Sie wissen müssen, ist, dass macOS ≠ Linux . Womit Linux Sie „durchkommen lässt“, ist nicht immer eine bewährte Vorgehensweise für die Systemadministration. Wenn wir alles reduzieren, fragen Sie im Wesentlichen nach der Platzierung von zwei Ordnern, und das Stammverzeichnis ist eigentlich nicht der beste Ort für sie, daher die Probleme, auf die Sie stoßen.

Durch das Deaktivieren von SIP entfernen Sie einen der wichtigsten Schutzmaßnahmen, die macOS zu einem der sichersten Betriebssysteme auf dem heutigen Markt machen. Dies zu tun, um die Sicherheitsarchitektur zu umgehen, sodass Sie Ordner/Mount-Volumes erstellen können, die sich im Stammverzeichnis befinden, ist kontraproduktiv. Anstatt gegen das Betriebssystem zu kämpfen, ist es am besten, damit zu arbeiten.

Es sei denn, Sie sind sicher, dass es direkt hilft, dieses Problem mit Finder zu lösen ...

Beim Finder ist das kein Problem. SIP gibt es schon lange; seit El Capitan (10.11) im Jahr 2015 veröffentlicht wurde. Das ist nichts Neues. Die neue APFS-Containerstruktur mit zwei Volumes, einem beschreibbaren und einem nicht (mit - Dataangehängtem Volume-Namen), ist jedoch neu. Während einige der Sicherheitsänderungen, die Apple implementiert hat, mehr Kopfschmerzen als nötig verursachen, gehört dies nicht dazu.

Dies ist eigentlich etwas, was Systemadministratoren tun sollten – das System härten und einschränken, was und wo der Benutzer schreiben kann, indem er die Verzeichnisse/Volumes mit entsprechenden Lese-/Schreib-/Ausführungsberechtigungen „containerisiert“ (Sandboxing).

Stellen Sie für Benutzer zugängliche Verzeichnisse am richtigen Ort bereit

Auch hier ist das Stammverzeichnis nicht wirklich ein geeigneter Ort für gemeinsam genutzte Daten, egal ob es sich um macOS oder Linux handelt. Unabhängig davon, ob diese Verzeichnisse lokal auf dem Mac sind (der Mac ist die Netzwerkfreigabe) oder Sie sie von einem Remote-Dateiserver mounten, sollten sie in einem geschützten Volume wie in abgelegt /Users/Sharedoder in gemountet werden /Volumes. Der Grund dafür ist, dass Sie die "übergeordneten" Rechte festlegen und auf alle untergeordneten Ordner anwenden können, während Sie möglicherweise die falschen Berechtigungen auf das gesamte System anwenden würden, wenn Sie die Rechte von etwas im Stammverzeichnis ändern würden.

Selbst mein Synology NAS (Linux-basiert) erlaubt mir nicht, Freigaben im Stammordner zu erstellen. Es zwingt mich, sie in einem Untervolume mit Berechtigungen zu mounten, die ich (mit Root-Zugriff) nicht ändern kann.

TL;DR

Du schwimmst hier gegen den Strom; Arbeit mit dem Betriebssystem und nicht dagegen. Wenn Sie feststellen, dass Sie alle Schutzfunktionen deaktivieren müssen, mit denen das System geliefert wurde, folgen Sie wahrscheinlich nicht einer bewährten Methode der Branche. Versuchen Sie nicht, macOS und Finder dazu zu zwingen, sich auf eine bestimmte Weise zu verhalten, weil Sie es „unter Linux tun“ können; Folgen Sie seinem Beispiel und Sie erhalten ein sicheres, verfügbares und vor allem zuverlässiges System, auf das sich Ihre Benutzer verlassen können.

Obwohl ich die Details schätze, lesen Sie Dinge in meinen Beitrag, die nicht dort sind, also werde ich es deutlicher machen: Hier ist kein "Share" oder NAS beteiligt. Dies sind Verzeichnisse, die ich erstellt habe, keine Einhängepunkte. Sie werden bei Bedarf manuell rsync-ed. Der fragliche Mac ist nicht über das Netzwerk zugänglich, der Remote-Linux-Computer jedoch. Ich mache mir keine Gedanken darüber, was Apple oder die „Industrie“ als Best Practices betrachten, also vergeuden Sie bitte nicht Ihren Atem damit, mich von den Vorteilen zu überzeugen, wenn sie mir die Kontrolle über den Computer entreißen.
Ob diese Verzeichnisse - das entscheidende Wort ist "ob", was bedeutet, dass es keine Rolle spielt, wofür Sie sie verwenden. Best Practices sind aus einem Grund (mindestens einem wichtigen) Best Practices; Sie mindern das Risiko. Wenn du deinen eigenen Weg gehen willst, ist das cool; es bedeutet nur, dass macOS nicht das richtige Werkzeug für Sie ist, Linux schon.
RE: Wie repariert man macOS-Berechtigungen nach dem Ausführen von „sudo chown -R www /“? (Eine warnende Geschichte) -- Das gehört wirklich nicht in Ihre Liste, weil der Befehl, den er tatsächlich ausgeführt hat, , sudo chown -R _WWW:_WWW /da er seitdem bearbeitet wurde, vollständig in der Lage ist, Teile des Systems durcheinander zu bringen, ohne SIP zu deaktivieren . In einer sauber gebauten macOS Catalina 10.15.4 VM hat dieser Befehl nur die _ownership und die Gruppe auf über 54.700 Dateien/Verzeichnissen geändert und das System total durcheinander gebracht, während SIP aktiviert war!
Hier ist ein Link zu einem ZIP-Archiv der Dateien, die der Befehl berührt hat: gofile.io/?c=rzjW7P