Le fichier du programme existe dans / usr / bin, mais ne peut pas être utilisé

De toute évidence, mon fichier existe dans /usr/bin

$ ls /usr/bin/ngrok
/usr/bin/ngrok

Cependant, lorsque j'essaye, chownje reçois une erreur

$ sudo chown my_user:users /usr/bin/ngrok
chown: cannot dereference '/usr/bin/ngrok': No such file or directory

D'autres tentatives pour l'exécuter échouent également!

$ ngrok
bash: ngrok: command not found
$ sudo /usr/bin/ngrok
sudo: /usr/bin/ngrok: command not found

Que se passe-t-il ici?

— Jorik
source

Le troisième point pourrait également se produire si «/ usr / bin /» n'est pas dans votre CHEMIN. Vous devriez avoir testé avec /usr/bin/ngrokpour être une symétrie complète du cas suivant avec sudo.

— Patrick Mevzek

Réponses:

/usr/bin/ngroksera un lien symbolique qui ne pointe nulle part (ou plutôt vers un fichier inexistant). Vérifiez avec ls -l.

— Sven
source

L'erreur "ne peut pas déréférencer" est le cadeau mort ici. Vous ne déréférencez pas un fichier normal, vous l'ouvrez.

— Kevin

Ou readlink -f /usr/bin/ngrokpour trouver où le lien doit pointer.

— Eric Duminil

ounamei -l /usr/bin/ngrok

— hanshenrik

Compte tenu de l' chownerreur, la possibilité la plus probable est qu'il s'agit d'un lien symbolique, comme l'a répondu Sven . Cependant, juste pour référence au cas où quelqu'un se retrouverait ici pour les cas où le fichier existe et n'est pas un lien, mais donne une erreur de commande introuvable / fichier introuvable, une autre possibilité est que l'exécutable soit lié dynamiquement et pour une raison quelconque, il n'est pas en mesure de charger les bibliothèques:

bibliothèque manquante (exécutez lddsur le binaire pour les voir)
chargeur manquant
apparmor refusant l'accès à une bibliothèque ou à un chargeur
...

De plus, pour un script, si l'interpréteur du shebang ne pouvait pas être exécuté pour des raisons similaires, vous obtiendriez la même erreur.

— muru
source

Encore plus déroutant, cela peut en effet conduire à un énigmatique «aucun fichier ou répertoire».

— rackandboneman

Vous avez également la possibilité de changer la propriété du lien symbolique lui-même avec

chown -h my_user:users /usr/bin/ngrok

si vous ne souhaitez pas (ou n'avez pas l'autorisation) de modifier la propriété du fichier cible.

— belette5i2
source

Je ne sais pas comment cela répond à la question - la question est "Que se passe-t-il ici?" et le problème est que le fichier cible n'existe pas. Cela ne résout pas le problème et ne répond pas à la question.

— wizzwizz4

@ wizzwizz4 Je suppose que vous pouvez également interpréter la question comme "le fichier existe (le lien symbolique est un fichier), pourquoi me dit-il le contraire et pourquoi ne puis-je pas changer sa propriété?" Cette réponse couvre cette interprétation. Sven suppose simplement (probablement correctement) que l'OP veut travailler avec le fichier cible.

— JoL

@muru Ceci n'est pas applicable sur un système Linux, qui n'a pas d'autorisations pour les liens symboliques. En fait, Linux est l' un des rares (est le seul?) Des systèmes d' exploitation familiale qui Posix n'ont la possibilité de définir le propriétaire / groupe symlink. Voir la page de manuel Linux . Les raisons possibles pour lesquelles Linux fait cela sont discutées sur unix.stackexchange.com/questions/33180/…chown(1)

— Andrew Henle

@AndrewHenle et comment cela aide-t-il? Changer de propriétaire / groupe pour un lien symbolique ne fait aucune différence ici car les autorisations appliquées lors de l'exécution sont toujours du fichier cible. Vous pouvez donc avoir un lien appartenant à qui que ce soit, mais le changement de propriété sur ce lien ne fait absolument aucune différence pour les autorisations prises en compte lors de son exécution.

— muru

@muru et comment cela aide-t-il? Lisez la question que j'ai déjà liée car elle demande spécifiquement: "Sous Linux, il est possible de changer le propriétaire ou le propriétaire du groupe d'un lien symbolique (lien symbolique). Je me demandais pourquoi quelqu'un voudrait le faire, car les autorisations d'un lien symbolique ne sont pas utilisé lors de l'accès à un fichier via celui-ci "

— Andrew Henle