sh: 0: getcwd () nie powiodło się: brak takiego pliku lub katalogu na cytowanym dysku

211

Próbuję skompilować kod ARM w Ubuntu 12.

Wszystko działa dobrze, kiedy umieszczam kod w katalogu lokalnym.

Ale kiedy wstawiam kod do cytowanego katalogu montowania, pojawia się błąd:

making testXmlFiles
sh: 0: getcwd() failed: No such file or directory
ARM Compiling xxxxx.c
sh: 0: getcwd() failed: No such file or directory

Oto moje ustawienie w fstab

//10.0.0.1/data /mnt/data   cifs    auto,noserverino,credentials=/root/.smbcredentials,file_mode=0777,dir_mode=0777,uid=user,gid=users,noperm 0 0

Co tu się dzieje? Co może powodować ten błąd?

— CrazyKitty Rotoshi
źródło

Próbuję w Ubuntu 10.10, to działa dobrze z tą samą konfiguracją.

— CrazyKitty Rotoshi

49

Ten komunikat o błędzie może zostać wyświetlony podczas próby wykonania polecenia ze ścieżki, która nie istnieje (np. Jeśli proces B usuwa folder, w którym aktualnie znajduje się proces A. Przykład z życia: w terminalu A: mkdir ~/myfunnydir && cd ~/myfunnydirw terminalu B: rm -rf ~/myfunnydiri wreszcie z powrotem w terminalu a znowu: java --version)

— dBm

Twój katalog jest automatycznie montowany, ale poświadczenia są przechowywane w /root. Zwykły użytkownik nie będzie mógł go zamontować, ponieważ poświadczenia nie będą dla niego czytelne. Spróbuj zrobić to jako non-auto mount i pozwól rootowi zamontować.

— alvits

564

Ten błąd jest zwykle spowodowany uruchomieniem polecenia z katalogu, który już nie istnieje.

Spróbuj zmienić katalog i ponownie uruchom komendę.

— Hooman
źródło

4

getcwdpobiera bieżący katalog roboczy, a jeśli katalog zostanie usunięty lub przeniesiony, będzie niezadowolony! Zobacz Linux Manual dla getcwd

— Hooman

2

Być może będziesz musiał to zrobić, jeśli usunąłeś katalog, w którym byłeś, i odtworzyłeś go w tym samym miejscu o tej samej nazwie.

— Jackson,

sama prawda! miły!

— farhad goodarzi

1

wszystko, co zrobiłem, to uderzenie CD i ponowne uruchomienie polecenia, i zadziałało, dzięki!

— FreeSoftwareServers

Zauważyłem to sam podczas uruchamiania aktualizacji apt-get z nieistniejącego katalogu. Wiadomość wysyła spam około 20 razy, a następnie aktualizacja jest kontynuowana, jakby nic się nie wydarzyło. Miałem nadzieję znaleźć więcej informacji na temat tego, dlaczego apt-get dba nawet o to, w którym folderze jestem, szczególnie tak natarczywie, z tak niewielką konsekwencją.

— Darren Ringer

11

Wypróbuj następujące polecenie, zadziałało dla mnie.

cd; cd -

— timxor
źródło

co to jest?

— dılo sürücü

cd;zwykle zabierze Cię do katalogu domowego i cd -zabierze Cię z powrotem do katalogu, w którym byłeś tuż przed bieżącym katalogiem. Zasadniczo idziesz do katalogu domowego i wracasz. Jednak jeśli oryginalny katalog, w którym byłeś, zostanie usunięty, to nie zadziała.

— Hooman

7

Zdarzyło mi się to również w odtworzonym katalogu, katalog jest taki sam, ale aby ponownie go uruchomić, wystarczy uruchomić:

cd .

— Roberto Rodriguez
źródło

6

Czasami może się to zdarzyć z linkami symbolicznymi. Jeśli napotkasz ten problem i wiesz, że jesteś w istniejącym katalogu, ale twoje dowiązanie symboliczne mogło się zmienić, możesz użyć tego polecenia:

cd $(pwd)

— smcjones
źródło

4

W Ubuntu 16.04.3 LTS następna komenda działa dla mnie:

exit

Potem zaloguję się ponownie.

— Czy Ma
źródło

2

w rzeczywistości wystarczyłoby przejść do istniejącego katalogu, jak już powiedział

— Hooman

2

Sprawdź ścieżkę katalogu, czy istnieje, czy nie. Ten błąd pojawia się, jeśli folder nie istnieje z miejsca, w którym uruchomiono polecenie. Prawdopodobnie wykonałeś polecenie remove z tej samej ścieżki w wierszu poleceń.

— Aritrik
źródło

1

Tak powiedział już

— Hooman

0

W moim przypadku nic powyżej nie zadziałało. Po chwili uderzenia głową o ścianę dowiedziałem się, że zniszczyłem/etc/passwd wpisy, uruchamiając niestandardowy skrypt linux-server-setup-setup-bash, który wcześniej działał dobrze, ale tym razem wyrażenie regularne polecenie „sed” usunęło wszystkie istniejące wpisy: D Po skopiowaniu wklejonych domyślnych wpisów z innego działającego serwera linux mogłem w końcu ponownie uruchomić sshd.

Nie zapomnij więc wykonać kopii zapasowej oryginalnego /etc/passwdpliku przed zastosowaniem na nim jakiejkolwiek zamiany wyrażenia regularnego :)

— Tech Nomad
źródło

-8

Nawet ja miałem ten sam problem z python virtualenv Zostało to naprawione przez prosty restart

sudo shutdown -r now

— yunus
źródło

4

w rzeczywistości wystarczyłoby przejść do istniejącego katalogu, jak już dawno powiedział

— Hooman