Kann bash_profile nicht verändern "not permitted"

[jacques_noris]

Ich habe festgestellt, dass im Terminal bei mir die meisten Unix-Befehle nicht gefunden werden. Als ich in mein .bash_profile geschaut habe, habe ich gesehen, dass da auch kein Path drin steht. Als ich es einfügen und speichern wollte, ging das aber nicht "Operation not permitted".

Dann habe ich gesehen, dass die File-Rechte auf 501 stehen. Ich kann sie aber nicht ändern. Immer wenn ich es versuche bekomme ich "Unable to change file mode on .bash_profile: Operation not permitted"

Was ist da los?

(Ich muss vielleicht erwähnen, dass ich mein SSD frisch von einem Time Machine Backup neu eingespielt habe. Habe das Gefühl, dabei sind einige Bits durcheinander gepurzelt...Siehe u.a. Thread hier drunter)

 

[dg2rbf]

Hi,
tja, wahrscheinlich musst du SIP abschalten, in die Recovery booten und im Terminal "csrutil disable" eingeben, zum Abschalten von SIP, wenn du .bash_profile Bearbeitet hast, dann im Terminal SIP wieder einschalten, "csrutil enable" im Terminal eingeben und mit enter Abschliessen.

Franz

 

[jacques_noris]

Danke für den Tipp! Habe jetzt bei Apple nachgelesen und SIP verhindert tatsächlich Veränderungen u.a. "/bin". Krass, war mir nicht klar.

 

[dg2rbf]

Hi,
SIP verhindert die Veränderung aller System relevanten Bestandteile.
Franz

 

[rootie]

Uhm .bash_profile ist aber im Benutzerkonto und keinesfalls eine systemrelevante Datei. Hiermit kann man seine Bash Konfigurieren. Ich gehe mal davon aus, dass der Benutzer der Datei nicht du selbst bist und damit reichen die Dateirechte 501 nicht.

Mach mal

sudo chown benutzername .bash_profile


Dass man hierfür das SIP abschalten muss ist Quatsch!

 

[Bachsau]

Dass man hierfür das SIP abschalten muss ist Quatsch!

Das Selbe gilt übrigens auch für Systemweite-Konfigurationsdateien in "/etc". Die SIP verhindert nicht, dass man seine Konfiguration anpassen kann, auch nicht die Systemweite. Außerdem liegt ".bash_profile" nicht in "/bin".

Der Standardmäßige PATH wird übrigens in "/etc/paths"gespeichert und kann dort auch angepasst werden. Diese Datei wird von "/usr/libexec/path_helper" gelesen, welches aus "/etc/profile" heraus aufgerufen wird.

SIP zu deaktivieren ist kein Tipp, den man leichtfertig geben sollte, denn in 99% der Fälle ist das, was dadurch geschützt wird. zurecht geschützt. Wer die Notwendigkeit sieht, es zu verändern, tut das meist aus Unwissenheit. Systemweite Befehle werden unter Unix üblicherweise in "/usr/local/bin" installiert, und dieses Verzeichnis steht auch im Standard-PATH vor "/usr/bin" und "/bin". Es gibt also keinen Grund, irgendetwas in den beiden letzteren Verzeichnissen anzufassen. Ich habe meine Terminal-Umgebung komplett angepasst, habe MacPorts installiert und verwende auch die Bash aus deren Repository als meine Standard-Shell. Für nichts davon habe ich die SIP oder Teile davon je abschalten müssen.

Für alle, die es interessiert: Im Dateisystem schützt SIP genau jene Dateien und Verzeichnisse, für die das "restricted" flag gesetzt ist. Das lässt sich mit "ls -laO" einsehen und im Recovery-Modus auch mittels "chflags norestricted" entfernen, ohne SIP komplett deaktivieren zu müssen. Aus den oben genannten Gründen ist davon aber ebenfalls abzuraten.

 

[Scotch]

sudo chown benutzername .bash_profile

Vorher vielleicht noch prüfen, wem die .bash_profile Datei überhaupt gehört

 

[rootie]

Vorher vielleicht noch prüfen, wem die .bash_profile Datei überhaupt gehört

Im eigenen Benutzerordner sollte sich die Frage eigentlich nicht stellen [emoji38]

 

[Bachsau]

"Ich hab' schon Pferde vor der Apotheke kotzen sehen", wie man so sagt.
Gerade unter macOS weiß man leider nie, welche Software gerade wieder meint, sich an den Zugriffs- und Besitzrechten von Dateien vergreifen zu müssen. Ich erlebe es regelmäßig, dass mein Benutzerorder auf 777 gesetzt wird oder "/Users" plötzlich meinem Hauptbenutzer gehört. Der "Respekt" von Entwicklern vor solchen Dingen ist leider unter macOS längst nicht so ausgeprägt, wie unter Linux. Mit jeder installierten ".pkg" kann praktisch alles passieren. Dieses Problem dürfte der Hauptgrund dafür sein, weshalb Apple SIP überhaupt eingeführt hat, und warum es unter Windows den "Trusted Installer" gibt: Damit Drittanbieter endlich die Finger von Dingen lassen, an denen sie einfach nicht rumzufummeln haben.

Was ich aber zum Thema noch sagen kann: Es macht Sinn der "Terminal"-App in den Systemeinstellungen zur Sicherheit "Festplattenvollzugriff" einzuräumen, sonst verhindert schon die Sandbox des Terminals viele Zugriffe.

 

[Scotch]

Im eigenen Benutzerordner sollte sich die Frage eigentlich nicht stellen

Gerade da - sonst wäre das Problem des TE doch gar nicht existent:

Ich muss vielleicht erwähnen, dass ich mein SSD frisch von einem Time Machine Backup neu eingespielt habe. Habe das Gefühl, dabei sind einige Bits durcheinander gepurzelt...