Il file di programma esiste in / usr / bin, ma non può essere utilizzato

Chiaramente il mio file esiste in /usr/bin

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

Tuttavia, quando provo ad chownesso, ricevo un errore

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

Anche altri tentativi di eseguirlo falliscono!

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

Cosa sta succedendo qui?

— Jorik
fonte

Il terzo punto potrebbe accadere anche se '/ usr / bin /' non si trova nel PERCORSO. Dovresti aver provato con /usr/bin/ngrokper essere una simmetria completa del seguente caso con sudo.

— Patrick Mevzek,

Risposte:

/usr/bin/ngroksarà un collegamento simbolico che non punta da nessuna parte (o piuttosto a un file inesistente). Verificare con ls -l.

— Sven
fonte

L'errore "impossibile dereference" è l'omaggio morto qui. Non "dereferenziare" un file normale, lo si apre.

— Kevin,

O readlink -f /usr/bin/ngrokper trovare dove dovrebbe puntare il link.

— Eric Duminil,

oppurenamei -l /usr/bin/ngrok

— hanshenrik,

Dato l' chownerrore, la possibilità più probabile è che si tratti di un collegamento simbolico, come ha risposto Sven . Tuttavia, solo per riferimento nel caso in cui qualcuno finisca qui per i casi in cui il file esiste e non è un collegamento, ma dà un errore comando-non-trovato / file-non-trovato, un'altra possibilità è che l'eseguibile sia collegato dinamicamente e per qualche motivo non è in grado di caricare librerie:

libreria mancante (esegui lddsul binario per vederli)
caricatore mancante
AppArmor nega l'accesso a una libreria o caricatore
...

Inoltre, per uno script, se l'interprete nello shebang non può essere eseguito per ragioni simili, si otterrebbe lo stesso errore.

— Muru
fonte

Ancora più confuso, questo può effettivamente comportare un enigmatico "nessun file o directory".

— Rackandboneman,

Hai anche la possibilità di cambiare la proprietà del link simbolico stesso con

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

se non si desidera (o si dispone dell'autorizzazione) per modificare la proprietà del file di destinazione.

— weasel5i2
fonte

Non sono sicuro di come questo risponda alla domanda - la domanda è "Cosa sta succedendo qui?" e il problema è che il file di destinazione non esiste. Questo non risolve il problema e non risponde alla domanda.

— wizzwizz4,

@ wizzwizz4 Suppongo che tu possa anche interpretare la domanda come "il file esiste (il link simbolico è un file), perché mi dice diversamente e perché non posso cambiarne la proprietà?" Questa risposta copre questa interpretazione. Sven presuppone (probabilmente correttamente) che l'OP voglia lavorare con il file di destinazione.

— JoL

@muru Questo non è applicabile su un sistema Linux, che non dispone delle autorizzazioni per i collegamenti simbolici. In realtà, Linux è uno dei pochi (è l'unico?) Di sistemi operativi POSIX-familiari che non hanno la possibilità di impostare link simbolico proprietario / gruppo. Vedi la chown(1)pagina man di Linux . Le possibili ragioni per cui Linux fa questo sono discusse su unix.stackexchange.com/questions/33180/…

— Andrew Henle,

@AndrewHenle e in che modo aiuta? La modifica del proprietario / gruppo per un collegamento simbolico non fa alcuna differenza qui poiché le autorizzazioni applicate durante l'esecuzione sono sempre del file di destinazione. Quindi potresti avere un link di proprietà di chiunque, ma cambiare la proprietà su quel link non fa assolutamente alcuna differenza rispetto alle autorizzazioni considerate durante l'esecuzione.

— muru,

@muru e in che modo aiuta? Leggi la domanda che ho già collegato poiché in particolare si chiede: "In Linux è possibile cambiare il proprietario o il proprietario del gruppo di un collegamento simbolico (collegamento simbolico). Mi chiedevo perché qualcuno avrebbe voluto farlo, poiché i permessi di un collegamento simbolico non sono utilizzato quando si accede a un file attraverso di esso "

— Andrew Henle