Plik programu istnieje w / usr / bin, ale nie można go użyć

Najwyraźniej mój plik istnieje /usr/bin

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

Jednak gdy próbuję to chownzrobić , pojawia się błąd

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

Dalsze próby jego uruchomienia również się nie udają!

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

Co tu się dzieje?

— Jorik
źródło

Trzeci punkt może się również zdarzyć, jeśli „/ usr / bin /” nie znajduje się w ŚCIEŻCE. Powinieneś był przetestować, /usr/bin/ngrokaby uzyskać pełną symetrię następującego przypadku z sudo.

— Patrick Mevzek,

Odpowiedzi:

/usr/bin/ngrokbędzie dowiązaniem symbolicznym, które nigdzie nie wskazuje (a raczej nieistniejącego pliku). Sprawdź za pomocą ls -l.

— Sven
źródło

Błąd „nie można wyłuskiwać” jest tutaj martwym rozdaniem. Nie „wyłuskujesz” normalnego pliku, otwierasz go.

— Kevin

Lub readlink -f /usr/bin/ngrokznaleźć, gdzie link powinien wskazywać.

— Eric Duminil

lubnamei -l /usr/bin/ngrok

— hanshenrik

Biorąc pod uwagę chown błąd, najbardziej prawdopodobne jest to, że jest to dowiązanie symboliczne, na co odpowiedział Sven . Jednak tylko w celach informacyjnych, na wypadek gdyby ktoś znalazł się tutaj w przypadkach, w których plik istnieje i nie jest łączem, ale daje błąd polecenia nie znaleziono / plik nie znaleziono, istnieje jeszcze jedna możliwość, że plik wykonywalny jest dynamicznie powiązany i z jakiegoś powodu nie można załadować bibliotek:

brakująca biblioteka (uruchom lddplik binarny, aby je zobaczyć)
brakujący moduł ładujący
przerażenie odmawiający dostępu do biblioteki lub modułu ładującego
...

Ponadto w przypadku skryptu, jeśli interpreter w trybie shebang nie mógłby zostać wykonany z podobnych powodów, wystąpiłby ten sam błąd.

— muru
źródło

Nawet bardziej mylące, może to rzeczywiście doprowadzić do enigmatycznego „braku takiego pliku lub katalogu”.

— rackandboneman

Możesz również zmienić własność samego dowiązania symbolicznego

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

jeśli nie chcesz (lub nie masz uprawnień) zmienić właściciela pliku docelowego.

— weasel5i2
źródło

Nie jestem pewien, jak to odpowiada na pytanie - pytanie brzmi „Co się tutaj dzieje?” problem polega na tym, że plik docelowy nie istnieje. To nie rozwiązuje problemu i nie odpowiada na pytanie.

— wizzwizz4

@ wizzwizz4 Podejrzewam, że możesz również zinterpretować pytanie jako „plik istnieje (dowiązanie symboliczne to plik), dlaczego mówi mi inaczej i dlaczego nie mogę zmienić jego własności?” Ta odpowiedź obejmuje tę interpretację. Sven po prostu zakłada (prawdopodobnie poprawnie), że OP chce pracować z plikiem docelowym.

— JoL

@muru Nie dotyczy to systemu Linux, który nie ma uprawnień do dowiązań symbolicznych. W rzeczywistości Linux jest jednym z niewielu (jest jedynym?) Systemów operacyjnych z rodziny POSIX, który ma możliwość ustawienia właściciela / grupy dowiązań symbolicznych. Zobacz Linux chown(1)stronę man . Możliwe przyczyny, dla których Linux to robi, są omówione na stronie unix.stackexchange.com/questions/33180/...

— Andrew Henle

@AndrewHenle i jak to pomaga? Zmiana właściciela / grupy dla dowiązania symbolicznego nie ma tutaj znaczenia, ponieważ uprawnienia stosowane podczas wykonywania dotyczą zawsze pliku docelowego. Możesz mieć link należący do kogokolwiek, ale zmiana właściciela tego linku nie ma absolutnie żadnej różnicy w zakresie uprawnień branych pod uwagę podczas jego wykonywania.

— muru

@muru i jak to pomaga? Przeczytaj pytanie, które już podlinkowałem, ponieważ konkretnie pyta: „W systemie Linux można zmienić właściciela lub właściciela grupy dowiązania symbolicznego (dowiązanie symboliczne). Zastanawiałem się, dlaczego ktoś chciałby to zrobić, ponieważ uprawnienia dowiązania symbolicznego nie są używane podczas uzyskiwania dostępu do pliku przez niego ”

— Andrew Henle,