EACCES: permission denied - Rechte falsch?

[Critizz]

Hallo Community,

Kurze Vorgeschichte:
Ich bin neu im Bereich Frontend und wollte jetzt mit vue.js (javascript framework - ähnlich wie react) etwas herumexperimentieren.

Vue.js installiert man über die kommandozeile mit dem Befehl:

npm install -g vue-cli

um dann ein Projekt zu erstellen, benutzt man:

vue init webpack namevomprojekt


& da fängt es schon an.

Ich kann diesen Befehl nicht ausführen und bekomme die Meldung:
Error: EACCES: permission denied, unlink '/Users/critizz/.vue-templates/webpack/.gitignore'

wenn ich ein "sudo" vor dem befehl schreibe, klappt es.

Jedoch werde ich dann jedes mal dazu aufgefordert mein Admin Pw einzugeben, wenn ich Dateien aus dem Projekt-Ordner hin und her schieben möchte oder auch wenn ich eine neue Datei erstellen möchte.


Kann es vielleicht sein, das meine rechte allgemein "beschädigt" sind?

Ich habe die selbe Frage auch auf Stackoverflow (in englisch) gestellt:

https://stackoverflow.com/questions...s-wrong?noredirect=1#comment88873198_50936253



Und diese Anleitung habe ich benutzt, um Vue.js zu installieren:
https://medium.com/codingthesmartway-com-blog/vue-js-2-quickstart-tutorial-2017-246195cfbdd2

 

[Olivetti]

wie hast du denn node installiert? üblicherweise liegt da schon der fehler.
bzw. laufen denn andere node-projekte normal?

 

[Critizz]

wie hast du denn node installiert? üblicherweise liegt da schon der fehler.
bzw. laufen denn andere node-projekte normal?

Ich habe node damals glaube ich per homebrew installiert.
Hab node & npm jetzt komplett runtergeworfen und nochmal neu installiert..

Mit dem Befehl "brew doctor" hab ich etwas merkwürdiges gefunden (Siehe Bildschirmfoto)

Meinst du daran wird es die ganze zeit gelegen haben?

 

[xentric]

Meinst du daran wird es die ganze zeit gelegen haben?

Den Tipp aus der angehängten Fehlermeldung würde ich auf gar keinen Fall machen. Wieso sollte man /usr/local/include/ einem normalen User zuweisen. Wer auch immer das in implementiert hat, der hat offensichtlich keine Ahnung von POSIX.

Error: EACCES: permission denied, unlink '/Users/critizz/.vue-templates/webpack/.gitignore'

Ja, dann ändere halt die Rechte rekursiv von ~/.vue-templates. Ist doch alles in deinem User-Ordner.

wenn ich ein "sudo" vor dem befehl schreibe, klappt es.

Wahrscheinlich liegt da das Problem. Wieso mixt du sudo mit nicht sudo? Wahrscheinlich hast du jetzt einfach einige Dateien in deinem Home die root gehören anstatt deinem user. Deshalb der Fehler. Sofern man den ganzen npm Kram auch korrekt lokal installieren kann wie z.B. bei python in einem virtualenv, sollte man keine adminrechte (sudo) brauchen.

 

[Critizz]

Den Tipp aus der angehängten Fehlermeldung würde ich auf gar keinen Fall machen. Wieso sollte man /usr/local/include/ einem normalen User zuweisen. Wer auch immer das in implementiert hat, der hat offensichtlich keine Ahnung von POSIX.

Also ich hab das jetzt leider schon gemacht und jetzt scheint es zu funktionieren?
Weißt du, wie ich das Rückgängig machen kann?

Ich wunder mich nur, warum es bei allen anderen ohne sudo problemlos klappt & bei mir halt nur mit sudo..
Die anderen haben ja scheinbar auch nichts in ihren Einstellungen geändert

 

[Critizz]

Eine weitere Fehlermeldung, die ich gestern bekommen hab war:

Error: Could not symlink share/systemtap/tapset/node.stp Target /usr/local/share/systemtap/tapset/node.stp

laut stackoverflow waren auch meine Rechte für das Verzeichnis: /usr/local/share falsch.

mit: "sudo chown -R $(whoami) /usr/local/share/systemtap lässt sich das wohl beheben.


liegt es nur an mir oder sind die rechte von macOS von haus aus schon so eingestellt?

 

[xentric]

liegt es nur an mir oder sind die rechte von macOS von haus aus schon so eingestellt?

Nein, die sind von Haus aus nicht falsch. Und wie ich schon gesat habe, dein User hat als Eigentümer nichts im /usr/local/* zu suchen!

Der Tipp ist einfach falsch, du machst etwas falsch oder die Software ist schlecht geschrieben. Ich würde nicht

sudo chown -R $(whoami) /usr/local/share/
sudo chown -R $(whoami) /usr/local/include/

oder sonst soetwas ausführen. Klar, lässt sich das damit beheben, aber das ist nicht das eigentliche Problem. Wenn nur du das System nutzt, kannst du das natürlich so machen, aber ideal ist das nicht.

Wie sind denn die genauen Rechte (rwx) und Eigentümer von den Ordnern/Dateien jetzt? Eine Executable braucht ein x bit.

 

[Critizz]

Nein, die sind von Haus aus nicht falsch. Und wie ich schon gesat habe, dein User hat als Eigentümer nichts im /usr/local/* zu suchen!

Der Tipp ist einfach falsch, du machst etwas falsch oder die Software ist schlecht geschrieben. Ich würde nicht

sudo chown -R $(whoami) /usr/local/share/
sudo chown -R $(whoami) /usr/local/include/

oder sonst soetwas ausführen. Klar, lässt sich das damit beheben, aber das ist nicht das eigentliche Problem. Wenn nur du das System nutzt, kannst du das natürlich so machen, aber ideal ist das nicht.

Wie sind denn die genauen Rechte (rwx) und Eigentümer von den Ordnern/Dateien jetzt? Eine Executable braucht ein x bit.

Also meine Rechte für Ordner die z.B auf dem Desktop liegen, lauten: drwxr-xr-x
meinst du das?


Gibt es denn eine Möglichkeit alle meine Rechte unter macOS zurückzusetzen?

 

[Haskelltier]

Zuerst mal ein paar Sachen. Wenn du node „damals“ korrekt installiert hast (also keine Fehler aufgetreten sind), dann sollte die Warnung, die „brew doctor“ ausgegeben hat, nicht das Problem verursacht haben.

Der ursprüngliche Fehler hat auch gar nicht mit dem /usr/local/include Verzeichnis zu tun, sondern mit dem in der Fehlermeldung genannten Verzeichnis/Datei. Du solltest also zwei Dinge machen:

1) Schaue nach ob alle Dateien und Ordner in /Users/critizz/.vue-templates/ die richtige Benutzer- und Gruppen-ID haben und die Rechte korrekt sind. Das kannst du beispielsweise mit dem Terminal-Befehl „ls“ (und Parameter "-l", eventuell noch "-R").

2) Sollten die nicht stimmen, kannst du sie im Terminal mit „chown“ und/oder „chmod“ anpassen. Sollten sie für viele Unterordner nicht passen, kann natürlich auch hier Rekursion helfen.

Dann sollte es auch wieder ohne root-Rechte klappen dort Dinge zu ändern. Und in Zukunft dann aufpassen was du mit sudo machst.

 

[Critizz]

node habe ich damals per homebrew installiert & ich denke, ich hatte damals keine fehlermeldungen

mit ls -l

+

den pfad von .vue-templates bekomme ich die Meldung:

drwxr-xr-x 14 critizz staff 448 20 Jun 23:23 webpack

das sieht doch okay aus?

und wie mach ich den Befehl: sudo chown -R $(whoami) /usr/local/include wieder rückgängig?

 

[Critizz]

sorry wenn ich das nochmal pushe aber gibt es nicht die möglichkeit alle meine rechte die ich jetzt z.B für /usr/.. & andere verzeichnisse verändert habe komplett zurückzusetzen? also so als wäre mein mac wieder komplett neu mit unveränderten rechten bzw. mit den standardrechten?

würde gerne komplett von vorne anfangen und nodejs + homebrew komplett von meiner platte schmeißen und neu installieren (ich habe es vermutlich damals falsch installiert)

 

[xentric]

sorry wenn ich das nochmal pushe aber gibt es nicht die möglichkeit alle meine rechte die ich jetzt z.B für /usr/.. & andere verzeichnisse verändert habe komplett zurückzusetzen?

Nein, gibts nicht. Und keiner weiß, was du installiert hast also was da alles an Dateien herumfliegt. Du musst entweder alles manuell durchgehen, oder das Backup einspielen. Das meiste sollte root gehören, aber wie gesagt, das ist abhängig von deinem System und dem was installiert ist.

 

[Olivetti]

sein macos-standardzeugs kann er prüfen, mit:

sudo /usr/libexec/repair_packages --verify --standard-pkgs /

 

[Kaito]

Den Tipp aus der angehängten Fehlermeldung würde ich auf gar keinen Fall machen. Wieso sollte man /usr/local/include/ einem normalen User zuweisen. Wer auch immer das in implementiert hat, der hat offensichtlich keine Ahnung von POSIX.

Nein, die sind von Haus aus nicht falsch. Und wie ich schon gesat habe, dein User hat als Eigentümer nichts im /usr/local/* zu suchen!

Der Tipp ist einfach falsch, du machst etwas falsch oder die Software ist schlecht geschrieben. Ich würde nicht

Das sehe ich jetzt weniger wild als du.
Die Software von der der Text stammt ist Homebrew und Homebrew wurde mit dem Designziel entworfen, kein sudo/root Rechte zu benötigten. Das geht so weit, dass die Arbeit mit root Rechten explizit verhindert wird.
Homebrew sagt sich jetzt, dass /usr/local auf einem Mac von OSX nicht verwendet wird (das entspricht POSIX). Das stimmt auch, das Verzeichnis existiert bei einem Clean Install gar nicht. Andere Paketmanager wie macports setzen sich in /opt, Fink in /sw und bleiben /usr/local auch fern. Wenn /usr/local also überhaupt existiert, dann ist das bei 99% der User so, weil sie irgendeinen Installer haben laufen lassen und dem root Rechte gaben, der dann /usr/local erst erstellt hat. Homebrew benötigt dabei auch nicht ganz /usr/local, sondern eigentlich verlangt es die angesprochenen non-root Rechte nur für diverse Ordner in /usr/local. /usr/local selbst darf durchaus root gehören.

Ich verstehe dich insofern, dass $(whoami):admin von einem theoretischen Standpunkt nicht der Besitzer dieses Ordners sein sollte. Realistisch gesehen macht es in der Praxis aber keinen Unterschied, da 99% der Leute die einzigen Benutzer und Admins auf ihrem System sind.
Die Begründung liegt darin, dass in so einem Fall (alles gehört root) der Anwender ohnehin einfach vor jeden Befehl ein sudo klatscht und das bei unbedarften Anwendern, die munter Befehle aus dem Internet kopieren, nachher zu mehr Schaden führen kann, als schlicht ein paar Unterverzeichnissen $(whoami):admin zu geben.
Wenn man sich entscheidet /usr/local an Homebrew zu übergeben, dann wäre ein eigener Homebrew-User eigentlich noch am sinnvollsten, aber in der Praxis auch nicht so bequem.

 

[xentric]

Das sehe ich jetzt weniger wild als du.
Die Software von der der Text stammt ist Homebrew und Homebrew wurde mit dem Designziel entworfen, kein sudo/root Rechte zu benötigten. Das geht so weit, dass die Arbeit mit root Rechten explizit verhindert wird.
Homebrew sagt sich jetzt, dass /usr/local auf einem Mac von OSX nicht verwendet wird (das entspricht POSIX). Das stimmt auch, das Verzeichnis existiert bei einem Clean Install gar nicht. Andere Paketmanager wie macports setzen sich in /opt, Fink in /sw und bleiben /usr/local auch fern. Wenn /usr/local also überhaupt existiert, dann ist das bei 99% der User so, weil sie irgendeinen Installer haben laufen lassen und dem root Rechte gaben, der dann /usr/local erst erstellt hat. Homebrew benötigt dabei auch nicht ganz /usr/local, sondern eigentlich verlangt es die angesprochenen non-root Rechte nur für diverse Ordner in /usr/local. /usr/local selbst darf durchaus root gehören.

Ich verstehe dich insofern, dass $(whoami):admin von einem theoretischen Standpunkt nicht der Besitzer dieses Ordners sein sollte. Realistisch gesehen macht es in der Praxis aber keinen Unterschied, da 99% der Leute die einzigen Benutzer und Admins auf ihrem System sind.
Die Begründung liegt darin, dass in so einem Fall (alles gehört root) der Anwender ohnehin einfach vor jeden Befehl ein sudo klatscht und das bei unbedarften Anwendern, die munter Befehle aus dem Internet kopieren, nachher zu mehr Schaden führen kann, als schlicht ein paar Unterverzeichnissen $(whoami):admin zu geben.
Wenn man sich entscheidet /usr/local an Homebrew zu übergeben, dann wäre ein eigener Homebrew-User eigentlich noch am sinnvollsten, aber in der Praxis auch nicht so bequem.

Ich hab genau das gleiche gesagt:

Wenn nur du das System nutzt, kannst du das natürlich so machen, aber ideal ist das nicht.

Das meiste sollte root gehören, aber wie gesagt, das ist abhängig von deinem System und dem was installiert ist.

Aber ich verstehe deine Zusammenfassung und ich hoffe sie bringt dem OP etwas Erkenntnis, auch wenn ich daran Zweifel habe, da ich seine Posthistory kenne.