.zshrc : Vous n'êtes pas propriétaire du fichier...

[bugsfunny]

Bonsoir,

Je découvre Ventura sur un Mac installé pour ça. Je dois modifier le fichier ./zshrc pour les chemin d'application et je découvre que le système m'interdit de modifier le fichier. J'ai comme erreur "Vous n'êtes pas propriétaire du fichier ./zshrc et ne disposez pas de l'autorisation d'écriture sur celui ci"...

Comme précédemment j'ai déjà eu des erreurs pour installer react-native-cli avec npm pour des raisons de droits je me demande si Ventura n'a pas changé quelque chose dans le système qu'il faudrait configurer quelque part pour résoudre ces problèmes. A supposer que ces problèmes soient liés.

Est ce que quelqu'un ici aurait des informations pour résoudre ce problème ?

Merci.

 

[edenpulse]

fichier ./zshrc

Deja c’est ~/.zshrc pour commencer

Et difficile de t’aider sans savoir quelles commandes tu lances, ni sans screenshots…

 

[bugsfunny]

Oui, effectivement c'est bien ~/.zshrc, désolé pour la faute de frappe...
Je fais ouvrir avec textedit mais le fichier est édité (ce qui est normal) en mode normal et pas root. Je me demandais simplement si sous Ventura il n'y avait pas une nouvelle protection (que je ne connais pas, je suis habitué à Catalina). Sous Catalina j'arrive bien à éditer mon zshrc mais pas sous Ventura (je suis obligé de passer par sudo nano...)

Pour résumer ma question était de savoir si Ventura avait ajouté des protections supplémentaires qui expliqueraient que j'ai des installations qui ne passent pas.

 

[sinbad21]

Bonjour, essaie en mode root dans Terminal en faisant :

sudo nano ~/.zshrc

 

[Romuald]

Note de la modération : On déménage dans le forum Linux, ça me semble plus sa place !

 

[edenpulse]

Bonjour, essaie en mode root dans Terminal en faisant :

sudo nano ~/.zshrc

Non mais non...

Le fichier a surement de mauvais droits. Un petit changement de droits pour remettre ça en place serait bénéfique.

 

[bugsfunny]

J'ai déjà fait sudo nano ~/.zshrc et ça fonctionne. C'est la seule solution que j'ai trouvé. Mais je ne sais toujours pas ouvrir mon fichier. .zshrc avec textedit en admin par exemple (sauf à passer par le terminal pour le lancer mais ça me parait bien compliqué).

Pour installer react-native je dois lancer cette commande par exemple pour mettre à jour le chemin: echo 'eval "$(rbenv init - zsh)"' >> ~/.zshrc
Eh bien j'obtiens en réponse "permission denied" même avec un sudo alors que sous Catalina ça passait bien. D'ou ma question sur ce forum pour savoir comment procéder avec Ventura.

comment puis je utiliser cette dernière commande vous Ventura sans me faire refuser à chaque fois ? (echo 'eval "$(rbenv init - zsh)"' >> ~/.zshrc)

Je précise que quand je regarde les droits sur le fichier .zshrc l'utilisateur que je suis a bien les droits en écriture.

@Romuald
Non, ce n'est pas du linux. C'est bien du MacOS et ce n'est pas ma faute si je me retrouve à patauger dans les commandes de terminal pour installer un environnement de développement sous Ventura.

PS:
Même un "source .zshrc" je ne peux plus le faire... Je dois rater quelque chose. Si quelqu'un a une idée....
Idem quand j'ouvre un terminal. J'ai ce message au démarrage: .zshrc permission denied

 

[sinbad21]

Et quand tu fais ls -al ~/.zshrc tu as quoi comme owner/group et comme droits ?

 

[bugsfunny]

Et quand tu fais ls -al ~/.zshrc tu as quoi comme owner/group et comme droits ?

Bonjour et merci pour votre réponse.

J'ai 644 avec Ventura comme pour le même fichier sous Catalina. En revanche une chose que je ne m'explique pas c'est qu'au niveau des droits c'est "root" qui a le droits d'écriture alors qu'avec la machine sous Catalina c'est sous mon nom d'user (moi). On dirait que par défaut Ventura attribue certains fichiers à root alors qu'ils sont à "moi" sous Catalina. .zprofile est comme ça aussi. Ce qui est encore plus curieux c'est que même avec sudo, les fichiers qui ont les droits en écriture pour root sont refusés aussi.

Je viens d'ajouter "moi" au niveau des droits de lecture et d'écriture pour voir ce que ça donne.

 

[sinbad21]

J'ai vérifié sous Sonoma, je n'avais pas de fichier .zshrc j'en ai créé un avec nano, il a bien mon user:staff comme owner/groupe.

Il y a donc un problème avec ce fichier .zsh, qui me fait suspecter un problème de owner plus vaste sur tout le dossier Utilisateur. Ce ne serait pas du luxe de faire un cmd+i sur le User et de remettre les bonnes informations sur tout le dossier.

Ci-dessous l'exemple donné par Apple :

 

[bugsfunny]

Je crois qu'il y a plusieurs problèmes superposés.

J'ai modifié le propriétaire du fichier et à ma grande surprise, ça n'a rien changé. J'ai même passé le chmod de 644 à 755 mais rien non plus. Je suis revenu à 644.

J'ai alors supprimés certains liens "path" dans mon fichier et là surprise, ça remarche (en gardant le propriétaire du fichier à "moi" plutôt que root quand même). A part les .zshrc et .zshprofile je n'ai pas trouvé d'autre fichier avec les droits sur root à ce niveau.

Ce sont ces paths qui posent problème:
export JAVA_HOME=$(/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home)
export PATH=$PATH:$JAVA_HOME/bin

et

eval "(rbenv init -)"

J'ai regardé le dossier Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/bin et il est en écriture et lecture système uniquement mais je devine qu'à ce niveau c'est normal. En revanche le terminal devrait pouvoir au moins le lire d'autant que j'ai autorisé le terminal dans "autoriser l'accès à tout le disque".

Au final, les deux path conduisent à permission denied. Du coup je me demande s'il faut autoriser (et comment) à la main ou si ça ne vient pas des préférences, du côté de "autoriser l'accès à tout le disque" auquel il faudrait rajouter quelque chose.

 

[sinbad21]

Quel est l'intérêt de faire ces exports ? Java ne marche pas sans eux ?

 

[bugsfunny]

Ca fait parti de la configuration pour installer React Native quand on veut développer.
Et puis on doit quand même pouvoir ajouter des path sans que ça bloque avec un access denied.

 

[sinbad21]

Ca fait parti de la configuration pour installer React Native quand on veut développer.
Et puis on doit quand même pouvoir ajouter des path sans que ça bloque avec un access denied.

Oui c'est bizarre.

 

[bugsfunny]

Oui c'est bizarre.

C'est la doc officielle pourtant...

Ceci dit ça ne résoud pas le problème.