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 /data
und arbeiten , aber wenn es um die Verwendung von Finder geht, ist dies nicht der Fall. /analyses
Das 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 chmod
und 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. :)
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 /data
und /analyses
woanders 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.
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
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 - Data
angehä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).
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/Shared
oder 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.
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.
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!
Benutzer3439894
Ei
Benutzer3439894
/dev
Ei
Benutzer3439894