Mongod skarży się, że nie ma folderu / data / db

Dzisiaj używam mojego nowego komputera Mac. Postępuję zgodnie z przewodnikiem wprowadzającym na mongodb.org aż do kroku, w którym tworzy się katalog / data / db. btw, skorzystałem z trasy homebrew.

Otwieram więc terminal i myślę, że jestem w tak zwanym katalogu domowym, ponieważ kiedy robię „ls”, widzę foldery aplikacji komputerowych Filmy Muzyka Zdjęcia Dokumenty i Biblioteka.

Więc zrobiłem

mkdir -p /data/db

po pierwsze, mówi, że odmówiono zgody. Próbowałem różnych rzeczy przez pół godziny i wreszcie:

mkdir -p data/db

pracował a kiedy „ls”, katalog danych i zagnieżdżony w nim folder db istnieją.

następnie odpalam mongod i narzeka, że ​​nie znalazłem danych / db

Czy zrobiłem coś złego?

Teraz zrobiłem

sudo mkdir -p /data/db

a kiedy wykonuję „ls”, widzę katalog danych i katalog db. jednak w db dir nie ma absolutnie nic i kiedy teraz uruchamiam mongod

Sun Oct 30 19:35:19 [initandlisten] exception in initAndListen: 10309 Unable to create/open lock file: /data/db/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating
Sun Oct 30 19:35:19 dbexit: 
Sun Oct 30 19:35:19 [initandlisten] shutdown: going to close listening sockets...
Sun Oct 30 19:35:19 [initandlisten] shutdown: going to flush diaglog...
Sun Oct 30 19:35:19 [initandlisten] shutdown: going to close sockets...
Sun Oct 30 19:35:19 [initandlisten] shutdown: waiting for fs preallocator...
Sun Oct 30 19:35:19 [initandlisten] shutdown: lock for final commit...
Sun Oct 30 19:35:19 [initandlisten] shutdown: final commit...
Sun Oct 30 19:35:19 [initandlisten] shutdown: closing all files...
Sun Oct 30 19:35:19 [initandlisten] closeAllFiles() finished
Sun Oct 30 19:35:19 [initandlisten] shutdown: removing fs lock...
Sun Oct 30 19:35:19 [initandlisten] couldn't remove fs lock errno:9 Bad file descriptor
Sun Oct 30 19:35:19 dbexit: really exiting now

EDYCJA Pobieranie komunikatu o błędzie dla

sudo chown mongod:mongod /data/db

chown: mongod: Invalid argument

Dziękuję wszystkim!

Utworzyłeś katalog w niewłaściwym miejscu

/ data / db oznacza, że ​​znajduje się bezpośrednio w katalogu głównym „/”, podczas gdy „data / db” (bez wiodącego /) prawdopodobnie znajduje się tylko w innym katalogu, takim jak katalog główny „/ root”.

Musisz utworzyć ten katalog jako root

Musisz użyć sudo, npsudo mkdir -p /data/db

Lub musisz zrobić, su -aby zostać superużytkownikiem, a następnie utworzyć katalog za pomocąmkdir -p /data/db

Uwaga:

MongoDB ma również opcję, w której możesz utworzyć katalog danych w innej lokalizacji, ale ogólnie nie jest to dobry pomysł, ponieważ tylko nieco komplikuje takie rzeczy, jak odzyskiwanie bazy danych, ponieważ zawsze musisz ręcznie określić ścieżkę db. Nie poleciłbym tego robić.

Edytować:

pojawia się komunikat o błędzie „Nie można utworzyć / otworzyć pliku blokady: /data/db/mongod.lock errno: 13 Odmowa dostępu” . Utworzony katalog nie wydaje się mieć odpowiednich uprawnień i własności - musi być zapisywalny przez użytkownika, który uruchamia proces MongoDB.

Aby zobaczyć uprawnienia i własność katalogu „/ data / db /”, wykonaj następujące czynności: (tak powinny wyglądać uprawnienia i własność)

$ ls -ld /data/db/
drwxr-xr-x 4 mongod mongod 4096 Oct 26 10:31 /data/db/

Lewa strona „drwxr-xr-x” pokazuje uprawnienia użytkownika, grupy i innych. „mongod mongod” pokazuje, kto jest właścicielem katalogu i do której grupy należy ten katalog. Oba są w tym przypadku nazywane „mongod”.

Jeśli katalog „/ data / db” nie ma powyższych uprawnień i praw własności, wykonaj następujące czynności :

Najpierw sprawdź, jaki użytkownik i grupa ma użytkownik mongo:

# grep mongo /etc/passwd
mongod:x:498:496:mongod:/var/lib/mongo:/bin/false

Powinieneś mieć wpis dla mongod w / etc / passwd, ponieważ jest to demon.

sudo chmod 0755 /data/db
sudo chown -R 498:496 /data/db    # using the user-id , group-id

Możesz także użyć nazwy użytkownika i nazwy grupy w następujący sposób: (można je znaleźć w / etc / passwd i / etc / group)

sudo chown -R mongod:mongod /data/db 

to powinno sprawić, że zadziała ...

W komentarzach poniżej niektóre osoby tego używały:

sudo chown -R `id -u` /data/db
sudo chmod -R go+w /data/db

lub

sudo chown -R $USER /data/db 
sudo chmod -R go+w /data/db

Wadą jest to, że $ USER to konto, które ma powłokę logowania. Ze względów bezpieczeństwa demony nie powinny mieć powłoki, dlatego w pliku grep pliku hasła powyżej widać / bin / false.

Sprawdź tutaj, aby lepiej zrozumieć znaczenie uprawnień do katalogu:

http://www.perlfect.com/articles/chmod.shtml

Być może zapoznaj się także z jednym z samouczków, które można znaleźć w Google: „UNIX dla początkujących”

Po uzyskaniu tego samego błędu co Nik

chown: id -u: Niepoprawny argument

I okazało się to najwyraźniej wystąpił z użyciem niewłaściwego typu cudzysłowie (powinno być małe cudzysłowy ) użytkowników Ubuntu

Zamiast tego właśnie użyłem

sudo chown $ USER / data / db

jako alternatywa, a teraz mongod ma potrzebne uprawnienia.

To działa dla mnie, znalezione w komentarzach:

sudo chown -R $USER /data/db

Utwórz folder.

sudo mkdir -p /data/db/

Pozwól sobie na folder.

sudo chown `id -u` /data/db

Wtedy możesz biegać mongodbez sudo. Działa na OSX Yosemite

Aby naprawić ten błąd w systemie OS X, ponownie uruchomiłem i zatrzymałem usługę: $ brew services restart mongodb $ brew services stop mongodb

Potem pobiegłem mongod --config /usr/local/etc/mongod.confi problem zniknął.

Błąd wydawał się pojawiać po aktualizacji pakietu homebrew mongodb.

Instalowanie poprzez brew na Macu, gdzie grupa YOUR_USER_NAME i personel to

sudo mkdir -p /data/db
sudo chmod +x+r+w /data/db/
sudo touch /data/db/mongod.lock
sudo chown YOUR_USER_NAME:staff /data/db
sudo chmod +x+r+w /data/db/mongod.lock
sudo chown YOUR_USER_NAME:staff /data/db/mongod.lock

Jeśli uruchamiasz mongo bez argumentów, zakładasz, że działasz na maszynie produkcyjnej, więc użyj domyślnych lokalizacji.

do korzystania z własnej bazy danych (programistycznej lub innej):

./bin/mongod --dbpath ~/data/db

Miałem ten problem z istniejącą konfiguracją Mongodb. Nadal nie jestem pewien, dlaczego tak się stało, ale z jakiegoś powodu proces Mongod nie mógł znaleźć pliku mongod.config. Ponieważ nie mógł znaleźć pliku konfiguracyjnego, próbował znaleźć pliki DB w / data / db, folderze, który nie istniał. Jednak plik konfiguracyjny był nadal dostępny, więc upewniłem się, że proces ma uprawnienia do pliku konfiguracyjnego i uruchomiłem proces mongod z flagą --config w następujący sposób:

mongod --config /etc/mongod.conf

W samym pliku konfiguracyjnym miałem to ustawienie:

storage:
  dbPath: /var/lib/mongodb

W ten sposób proces może ponownie znaleźć prawdziwy folder DB.

Zrobiłem

brew install mongodb

01.02.2018 i to dało mi mongodbwersję 3.6.2.

Poproszony przez odpowiedź od orluke powyżej, próbowałem tylko

$ brew services restart mongodb

i wszystko ożyło. Mój mongoose.createConnection()telefon zrobił to, co chciałem. GUI MongoDB Kompas , wersja społeczność, by połączyć. Użyłem Compassa, żeby obejrzeć local.startup_logkolekcję. Miał jeden dokument, dziennik, w którym właśnie uruchomiłem usługę mongoDB, i tak też było

cmdLine:Object
    config:"/usr/local/etc/mongod.conf"

i rzeczywiście był taki plik:

$ more /usr/local/etc/mongod.conf
systemLog:
  destination: file
  path: /usr/local/var/log/mongodb/mongo.log
  logAppend: true
storage:
  dbPath: /usr/local/var/mongodb
net:
  bindIp: 127.0.0.1

i był /usr/local/var/mongodbkatalog z dużą ilością niejasnych plików. Wydaje się, że tak właśnie działa teraz instalacja.

Nie jestem pewien, czy brew services restartustawia uruchomienie usługi przy logowaniu. Więc zrobiłem

brew services stop mongodb
brew services start mongodb

i mam nadzieję, że to uruchomi się ponownie po ponownym uruchomieniu. I rzeczywiście tak się stało. Właściwie teraz uważam, że właściwą rzeczą jest po pierwszej instalacji

brew services start mongodb

i to powinno uruchomić usługę i zrestartować ją po ponownym uruchomieniu.

Twoje polecenie utworzy strukturę katalogów w bieżącym folderze, a nie katalog główny komputera (czego brakuje /).

Pierwsze polecenie było słuszne, ale ponieważ próbujesz utworzyć folder /, który jest chronionym katalogiem, musisz go poprzedzić sudo, co jest skrótem od „superuser do”. Zostaniesz poproszony o podanie hasła.

Zatem pełne polecenie brzmiałoby:

$ sudo mkdir -p /data/db

Musisz utworzyć / data / db ... czyli katalog o nazwie / data / w katalogu głównym (tj. / ) I podfolder w tym katalogu o nazwie / db / ...

Występują błędy uprawnień, ponieważ musisz użyć sudo, aby utworzyć katalog główny w katalogu głównym w systemie MacOS, sudo pozwala uruchamiać polecenia jako administrator.

Więc uruchom to zamiast ...

$ sudo mkdir -p /data/db

Pojawi się monit o podanie hasła, to samo hasło, którego używasz do zmiany ustawień systemu (to małe okno dialogowe, które otwiera się, gdy próbujesz zmienić rzeczy w Preferencjach systemowych na przykład), i prawdopodobnie takie samo, jak przy logowaniu.

Próbujesz utworzyć katalog, do którego nie masz uprawnień roota.

Do testowania mongodb używam tylko katalogu z mojego katalogu użytkownika, takiego jak:

cd
mkdir -p temp/
mongod --dbpath .

Spowoduje to utworzenie bazy danych mongo w temp / z bieżącego katalogu roboczego

Rozwiązałem ten sam problem, tworząc foldery / data / db za pomocą menedżera okien. Najpierw próbowałem to zrobić przez terminal, a żeby utworzyć folder w katalogu głównym, musiałem użyć sudo.

Właśnie poszedłem do katalogu głównego za pomocą Findera i utworzyłem nowy folder za pomocą „New Folder”. Totally dla mnie pracował.

Uwaga: używam OSX.

Krótka uwaga:

Jeśli próbowałeś uruchomić mongod bez uprzedniej zmiany uprawnień, prawdopodobnie będziesz mieć plik mongod.lock (i kilka innych plików) w katalogu / data / db. Nawet po zmianie uprawnień do katalogu / data / db w celu umożliwienia dostępu do $ USER nadal będziesz otrzymywać komunikat „Nie można utworzyć / otworzyć pliku blokady: /data/db/mongod.lock errno: 13 Odmowa dostępu „błąd. Uruchom ls -al / data / db, a prawdopodobnie zobaczysz, że uprawnienia dla poszczególnych plików są nadal ustawione na rootowanie dla użytkownika, a nie dla twojego $ USER. Powinieneś usunąć plik mongod.lock, a także inne. Następnie, gdy uruchomisz ponownie mongod, wszystko powinno działać i możesz sprawdzić, czy uprawnienia do plików są zgodne z uprawnieniami do katalogu, ponownie uruchamiając ls -al.

Utwórz katalog w katalogu głównym

sudo mkdir -p /data/db

Teraz zmień właściciela

sudo chown -R $USER /data

Możesz iść!

mongod

zamiast używać sudo mongod, nie musisz sudo mongodpodawać hasła za każdym razem, ale w prawdziwym projekcie, którego powinieneś użyć , nie udzielaj pozwolenia zwykłemu użytkownikowi!

Podczas próby uruchomienia mongodb ciągle pojawiał się następujący błąd.

"shutting down with code:100" 

Korzystałem z następującego polecenia:

./mongod --dbpath=~/mongo-data

Dla mnie poprawka polegała na tym, że nie potrzebowałem znaku „=”, co powodowało błąd. Więc zrobiłem

./mongod --dbpath ~/mongo-data

Chciałem to wyrzucić, ponieważ błąd w żaden sposób nie wskazuje, że to jest problem. Prawie usunąłem zawartość katalogu ~ / mongo-data, aby zobaczyć, czy to pomogło. Cieszę się, że pamiętam, że czasami argumenty cli nie używają znaku „=”.

Do tej daty myślałem również, że musimy utworzyć ten folder / data / db, aby uruchomić komendę mongod.

Ale ostatnio próbowałem uruchomić mongod poleceniem service i zadziałało to dla mnie i nie było potrzeby tworzenia katalogu / data / db.

service mongod start

Aby sprawdzić status mongod, możesz uruchomić następującą komendę.

service mongod status

To rozwiązanie rozwiązuje mój problem

1. Utwórz katalog jako

   sudo mkdir -p / data / db

2. Spowoduje to utworzenie katalogu o nazwie db, a następnie spróbuje rozpocząć od poleceń

   sudo mongod

Jeśli pojawi się kolejny błąd lub problem z uruchomieniem mongod, możesz znaleźć problem jako

Nie udało się skonfigurować detektora: SocketException: Adres już używany Jeśli znajdziesz inny błąd niż musisz zabić działający mongod, wpisując na terminalu jako

ps ax | grep mongod
sudo kill ps_number

i znajdź działający port mongod i zabij ten proces. Innym sposobem jest utworzenie określonego portu podczas uruchamiania mongod as

sudo mongod --port 27018

Wpisz „id” na terminalu, aby zobaczyć dostępne identyfikatory użytkowników, które możesz podać, a następnie po prostu wpisz

„sudo chown -R idname / data / db”

To mi się udało! Mam nadzieję, że to rozwiąże problem.

W bardziej aktualnych wersjach MongoDB, mam 3.2.10, domyślnie jest przechowywany

/var/lib/mongodb

Po (ponownej) instalacji pakietu narzędzi dostałem podobny błąd na urządzeniu z systemem Windows 10;

wyjątek w initAndListen: NonExistentPath: Katalog danych C: \ data \ db \ nie znaleziono., zakończenie

Rozwiązanie Analogiczne do objaśnionego dla systemów Linux: po prostu utworzenie folderu jest wystarczające, aby móc uruchomić mongod.exe(serwer mongoDB).

Pomyślałem, że mogę zostawić to osobom, które kończą tutaj z tymi samymi wyszukiwanymi hasłami na urządzeniu z systemem Windows.

Chciałem tylko zaznaczyć tutaj, że jeśli spróbujesz tego i napotkasz mkdir: /data/db: Read-only file system, zapoznaj się z tym komentarzem, który pomógł mi: https://stackoverflow.com/a/58895373 .

W ten sposób, jeśli ktoś będzie na tej odpowiedzi i użyje Kontroli F dla „tylko do odczytu”, to zobaczy

Istnieje naprawdę głupi sposób, aby stworzyć ten problem, który zapoczątkowałem:

1) zostaw instalację mongo na chwilę 2) wróć, a serwer nie działa 3) spróbuj go uruchomić, ale nie używaj sudo tym razem 4) mongo nie może znaleźć danych / db /, ponieważ teraz szuka katalog domowy użytkownika zamiast katalogu domowego

Tak, to jest naprawdę głupie, ale jeśli minęło trochę czasu, odkąd byłeś w systemie, może cię potknąć.

Krótka odpowiedź: upewnij się, że korzystasz z mongo z tym samym domniemanym katalogiem domowym