Sperrdatei kann nicht erstellt / geöffnet werden: /data/mongod.lock errno: 13 Berechtigung verweigert

187

Wie bringe ich mongo dazu, ein gemountetes Laufwerk auf ec2 zu verwenden? Ich verstehe es wirklich nicht. Ich habe ein Volume an ec2 angehängt, das Laufwerk als root formatiert und als root gestartet und doch als root kann ich nicht darauf zugreifen? Ich laufe auf Ubuntu 12.04. Kein anderer Mongo läuft

Ich sehe, dass Mongo in / data, dh / data / db, ein 'db'-Verzeichnis erstellt hat

cd /
ls -al
drwxr-xr-x  4 root root  4096 Mar  5 16:28 data

cd /data
ls -al
total 28
drwxr-xr-x  4 root root  4096 Mar  5 16:28 .
drwxr-xr-x 24 root root  4096 Mar  5 16:28 ..
drwxr-xr-x  2 root root  4096 Mar  5 16:28 db
drwx------  2 root root 16384 Mar  5 16:20 lost+found


sudo mkfs.ext3 /dev/xvdh
sudo mkdir /data
sudo su - -c 'echo "/dev/xvdh %s auto noatime 0 0" | sudo tee -a /etc/fstab'
sudo mount /data

sudo service mongodb start
mongodb start/running, process 17169

sudo ps -ef | grep mongod
ubuntu   15763 15634  0 16:32 pts/2    00:00:00 tail -f mongodb.log
ubuntu   18049 15766  0 16:43 pts/3    00:00:00 grep --color=auto mongod


Tue Mar  5 16:33:15 [initandlisten] MongoDB starting : pid=15890 port=27017 dbpath=/data 64-bit host=aws-mongo-server-east-staging-20130305161917
Tue Mar  5 16:33:15 [initandlisten] db version v2.2.3, pdfile version 4.5
Tue Mar  5 16:33:15 [initandlisten] git version: f570771a5d8a3846eb7586eaffcf4c2f4a96bf08
Tue Mar  5 16:33:15 [initandlisten] build info: Linux ip-10-2-29-40 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_49
Tue Mar  5 16:33:15 [initandlisten] options: { bind_ip: "10.157.60.27", config: "/etc/mongodb.conf", dbpath: "/data", logappend: "true", logpath: "/var/log/mongodb/mongodb.log", replSet: "heythat" }
Tue Mar  5 16:33:15 [initandlisten] exception in initAndListen: 10309 Unable to create/open lock file: /data/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating
Tue Mar  5 16:33:15 dbexit: 
Tue Mar  5 16:33:15 [initandlisten] shutdown: going to close listening sockets...
Tue Mar  5 16:33:15 [initandlisten] shutdown: going to flush diaglog...
Tue Mar  5 16:33:15 [initandlisten] shutdown: going to close sockets...
Tue Mar  5 16:33:15 [initandlisten] shutdown: waiting for fs preallocator...
Tue Mar  5 16:33:15 [initandlisten] shutdown: lock for final commit...
Tue Mar  5 16:33:15 [initandlisten] shutdown: final commit...
Tue Mar  5 16:33:15 [initandlisten] shutdown: closing all files...
Tue Mar  5 16:33:15 [initandlisten] closeAllFiles() finished
Tue Mar  5 16:33:15 [initandlisten] shutdown: removing fs lock...
Tue Mar  5 16:33:15 [initandlisten] couldn't remove fs lock errno:9 Bad file descriptor
Tue Mar  5 16:33:15 dbexit: really exiting now

Unten ist, wenn ich neu starte, wenn ich eine Sperrdatei entferne ....

Tue Mar  5 16:59:15 [initandlisten] MongoDB starting : pid=21091 port=27017 dbpath=/data 64-bit host=aws-mongo-server-east-staging-20130305161917
Tue Mar  5 16:59:15 [initandlisten] db version v2.2.3, pdfile version 4.5
Tue Mar  5 16:59:15 [initandlisten] git version: f570771a5d8a3846eb7586eaffcf4c2f4a96bf08
Tue Mar  5 16:59:15 [initandlisten] build info: Linux ip-10-2-29-40 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_49
Tue Mar  5 16:59:15 [initandlisten] options: { bind_ip: "10.157.60.27", config: "/etc/mongodb.conf", dbpath: "/data", logappend: "true", logpath: "/var/log/mongodb/mongodb.log", replSet: "heythat" }
Tue Mar  5 16:59:15 [initandlisten] exception in initAndListen: 10309 Unable to create/open lock file: /data/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating
Tue Mar  5 16:59:15 dbexit: 
Tue Mar  5 16:59:15 [initandlisten] shutdown: going to close listening sockets...
Tue Mar  5 16:59:15 [initandlisten] shutdown: going to flush diaglog...
Tue Mar  5 16:59:15 [initandlisten] shutdown: going to close sockets...
Tue Mar  5 16:59:15 [initandlisten] shutdown: waiting for fs preallocator...
Tue Mar  5 16:59:15 [initandlisten] shutdown: lock for final commit...
Tue Mar  5 16:59:15 [initandlisten] shutdown: final commit...
Tue Mar  5 16:59:15 [initandlisten] shutdown: closing all files...
Tue Mar  5 16:59:15 [initandlisten] closeAllFiles() finished
Tue Mar  5 16:59:15 [initandlisten] shutdown: removing fs lock...
Tue Mar  5 16:59:15 [initandlisten] couldn't remove fs lock errno:9 Bad file descriptor
Tue Mar  5 16:59:15 dbexit: really exiting now
mongodb 
— Tampa
quelle
1
Es sieht so aus, als ob Mongod das letzte Mal schlecht heruntergefahren wurde und die von ihm erstellte Datei mongod.lock nicht bereinigen konnte. Diese Datei ist vorhanden, um zu verhindern, dass mehrere Mongod-Instanzen an der Datei arbeiten. Wenn Sie die Datei löschen und versuchen, mongod erneut auszuführen, sollten Sie keine Probleme haben
— ACE
2
Siehe aktualisierte Frage. Gleiches Problem beim Entfernen der Sperrdatei
— Tampa
Scheint immer noch ein Problem mit der Sperrdatei zu sein. Wie lauten die Berechtigungen für das Verzeichnis, in dem sich die Sperrdatei befindet? TBH Ich habe dies nur in 2 Fällen gesehen: 1) Die Sperrdatei existiert bereits und 2) Mongod hat keine Berechtigung, die Sperrdatei an der gewünschten Stelle zu erstellen.
— ACE
1
Sie sollten sicherstellen, dass der Mongo-Benutzer Zugriff hat chown mongodb:mongodb on /var/lib/monogdb, auch auf das Datenverzeichnis.
— Hans N. Hjort
1
— BARJ

Antworten:

117

Ich hatte das gleiche Problem auf einer Ubuntu ec2-Instanz. Ich habe diesen Amazon-Artikel auf Seite 7 verfolgt:

http://d36cz9buwru1tt.cloudfront.net/AWS_NoSQL_MongoDB.pdf

Der Mongodb-Pfad in /etc/mongodb.confwurde auf /var/lib/mongodb(primärer Installationsort und Arbeitsweise) festgelegt. Als ich zu /data/db(EBS-Volume) wechselte, wurde "errno: 13 Permission verweigert" angezeigt.

  1. Zuerst rannte ich sudo service mongodb stop.
  2. Dann habe ich immer ls -lagesehen, welcher Gruppe und welchem ​​Eigentümer Mongodb /var/lib/mongodb(vorhandener Pfad) zugewiesen ist, und ich habe den /data/db(neuen Pfad) mit chownund entsprechend geändert chgrp. (Beispiel: sudo chown -R mongodb:mongodb /data/db)
  3. Dann habe ich den Pfad etc/mongodb.confzu aktualisiert /data/dbund die alten Mongo-Dateien im /var/lib/mongodbVerzeichnis gelöscht .
  4. Dann rannte ich sudo service mongodb startund wartete ungefähr eine Minute. Wenn Sie versuchen, sofort eine Verbindung zu 27017 herzustellen, können Sie dies nicht.
  5. Nach einer /data/dbMinutenüberprüfung (EBS-Volume) sollte Mongo ein Tagebuch, mongod.lock, local.ns, local.0 usw. abgelegt haben. Wenn nicht, versuchen sudo service mongodb restartSie es eine Minute später.

Ich habe gerade über eine Stunde damit verbracht. Das Ändern der Gruppe und das Löschen der alten Dateien ist wahrscheinlich nicht erforderlich, aber das hat bei mir funktioniert.

Dies ist ein großartiges Video zum Mounten eines ebs-Volumes an eine ec2-Instanz:

http://www.youtube.com/watch?v=gBII3o3BofU

— Randy Swanson
quelle
8
Ich hatte mit diesem Problem zu kämpfen und stellte fest, dass, wenn Sie Ihren Zielordner mit ls -lahZ auflisten, der Sicherheitskontext angezeigt wird, der Kontext für den Mongo-Datenordner wie folgt festgelegt werden sollte: "sudo chcon -R -u system_u -t mongod_var_lib_t / folder / data "dies neben den offensichtlichen Berechtigungen und der Kombination Benutzer: Gruppe. Ich hoffe es hilft.
— jmdiego
478

Ich benutze diese Methode, um das Problem zu lösen:

sudo chown -R mongodb:mongodb /data/db
— Haimei
quelle
8
Fügen Sie eine -ROption hinzu und es ist perfekt :)
— Adrien
7
das ist: sudo chown -R id -u/ data / db für die Uneingeweihten. :)
— rncrtr
8
Es stellt sich heraus, dass es ein Problem mit Backticks gibt. Versuchen Sie, sudo chown $USER /data/dbanstelle des ursprünglichen Befehls auszuführen.
— Paymahn Moghadasian
7
Dies ist in der Tat die richtige Antwort. @ Tampa du solltest diese Antwort akzeptieren. Übrigens - du brauchst das id -Uoder so nicht $USER. Mongo hat einen eigenen Benutzer / eine eigene Gruppe. Sie können und sollten mongodb hart codieren: mongodb. so ist der Befehl einfachsudo chown -R mognodb:mognodb /data/db
— Kerl Mograbi
11
Was macht das eigentlich? Es funktioniert, würde aber gerne verstehen :)
— zero_cool
81

In meinem Fall (AWS EC2-Instanz, Ubuntu) hat geholfen:

$ sudo mkdir -p /data/db/
$ sudo chown `USERNAME` /data/db

Und danach hat alles gut funktioniert.

— Belhor
quelle
6
Dies ist die beste Antwort, es ist höchstwahrscheinlich ein Berechtigungsproblem mit dem Benutzer, der mongod
— davo
2
Ja, das ist die beste Antwort
— Vegan Sv
1
Wir ändern / übertragen das Eigentum /data/dbanUSERNAME
— Saif
52

Sie müssen nur Zugriff auf Ihre geben /data/db Ordner .

Typ sudo chown -R <USERNAME> /data/db, ersetzen<USERNAME> durch Ihren Benutzernamen.

Sie können Ihren Benutzernamen durch Eingabe finden whoami.

— Julien Bouteloup
quelle
10

Ich hatte ein ähnliches Problem, der eigentliche Grund war, dass bereits eine Mongod-Sitzung von meinem vorherigen Versuch ausgeführt wurde.

Ich rannte 

killall mongod

und alles andere lief wie erwartet.

killallDer Befehl würde ein TERM-Signal an alle Prozesse mit einer echten UID senden. Dies tötet also alle laufenden Instanzen von Mongod, so dass Sie Ihre eigenen starten können.

— Venky Soorisetty
quelle
Dies ist buchstäblich die kürzeste Antwort und die einzige Antwort, die mein Problem nach unzähligen Stunden gelöst hat ... danke!
— Moomoochen
Ich bin froh, dass es geholfen hat! :) Ich wünschte, es gibt eine Möglichkeit, Menschen zu helfen, diese Antwort leichter zu finden.
— Venky Soorisetty
7

Bis heute habe ich versucht, mich durch die Datei zum Erstellen / Öffnen der Sperre zu bewegen: /data/db/mongod.lock errno: 13 Berechtigung verweigert Wird eine Mongod-Instanz bereits ausgeführt?, Beendet und versucht, alle oben angegebenen Antworten auf Lösen Sie dieses Problem, daher hat nichts durch Hinzufügen geklappt

sudo chown -R mongodb: mongodb / data / db

Es sei denn, ich habe meine aktuelle Benutzerberechtigung zum Standortpfad von hinzugefügt

sudo chown $ USER / data / db

Hoffe das hilft jemandem. Außerdem habe ich gerade Mongo DB auf meinem Pi installiert. Prost!

— Abdullah
quelle
Dies ist die eigentliche Lösung des Problems
— Sahil Nagpal
6

Ich hatte ein ähnliches Problem und befolgte alle obigen Anweisungen zum Eigentümerwechsel mit Sudo Chown usw. Nach den Änderungen lief immer noch eine Instanz von Mongodb im Hintergrund. Laufen

ps auxw | grep mongo

zeigte mir andere Aufgaben mit Mongo im Hintergrund, die nicht richtig geschlossen wurden. Ich habe dann kill auf allen ausgeführt und konnte dann meinen Server starten.

— Eugene G.
quelle
6

Für Mac - Benutzer:
Führen Sie ls ld / data / db /
Output sollte so etwas wie drwrx-xr-x 20 singh Rad 680 21. Juli 05.49 / data / db /
Wo singh ist der Eigentümer und Rad ist die Gruppe es gehört .
Führen Sie sudo chown -R singh: Rad / data / db aus.
Führen Sie mongod aus

— amanSingh
quelle
5

Das Entfernen der Datei mongodb.lock war in meinem Fall nicht das Problem. Ich habe dies getan und eine Fehlermeldung bezüglich des verwendeten Ports erhalten: [initandlisten] listen (): bind () fehlgeschlagen errno: 98 Adresse, die bereits für Socket verwendet wird: 0.0.0.0:27017. Ich habe hier eine andere Lösung gefunden: Der lokale Mongodb-Server kann nicht mit Anweisungen zum Beenden des Prozesses gestartet werden:

  1. Finden Sie von netstat heraus, auf welchem ​​Prozess der Mongodb-Port ausgeführt wird (27017).

    sudo netstat -tulpn | grep :27017

    Die Ausgabe lautet: tcp 0 0 0.0.0.0:27017 0.0.0.0:* LISTEN 1412 / mongod

  2. Töte den entsprechenden Prozess.

    sudo kill 1412 (Ersetzen Sie 1412 durch Ihre in Schritt 1 gefundene Prozess-ID.)

Und ich konnte mongodb wieder erfolgreich starten. Ich glaube, meine lief immer noch vor einer unsachgemäßen Abschaltung.

— Casey Murray
quelle
4

Wenn Sie diesen Fehler unter Windows mit dem Task-Manager haben, beenden Sie die ausgeführte Instanz von "mongod.exe". Sobald dies erledigt ist, löschen Sie die Datei mongo.lock dauerhaft und führen Sie mongod.exe aus. Danach sollte es perfekt funktionieren.

— b_kik
quelle
3

Mein Mongo (3.2.9) wurde unter Ubuntu installiert und meine Protokolldatei hatte die folgenden Zeilen:

2016-09-28T11:32:07.821+0100 E STORAGE  [initandlisten] WiredTiger (13) [1475058727:821829][6785:0x7fa9684ecc80], file:WiredTiger.wt, connection: /var/lib/mongodb/WiredTiger.turtle: handle-open: open: Permission denied 
2016-09-28T11:32:07.822+0100 I -        [initandlisten] Assertion: 28595:13: Permission denied 
2016-09-28T11:32:07.822+0100 I STORAGE  [initandlisten] exception in initAndListen: 28595 13: Permission denied, terminating

2016-09-28T11: 32: 07.822 + 0100 I CONTROL [initandlisten] dbexit: rc: 100

Das Problem lag also in den Berechtigungen für den Ordner / var / lib / mongodb.

sudo chown -R mongodb:mongodb /var/lib/mongodb/
sudo chmod -R 755 /var/lib/mongodb
  • Starten Sie den Server neu

Es wurde behoben, obwohl mir klar wurde, dass dies möglicherweise nicht zu sicher ist (es ist meine eigene Entwicklungsbox, die ich in meinem Fall bin). Nach der Änderung funktionierten sowohl die Datenbank als auch die Authentifizierung.

— Nestor Miljew
quelle
2

In Mycase
In Mongodb Version 2.6.11 ist das Standard-Datenbankverzeichnis/var/lib/mongodb/

  1. $ sudo chown -R id -u/ var / lib / mongodb /

  2. $ sudo chown -R id -u/var/lib/mongodb/mongod.lock

  3. $ sudo /etc/init.d/mongod stop

  4. $ sudo /etc/init.d/mongod start

— Vijay
quelle
sollte `id -u` sein
— marcus
2

Ich habe das gleiche Problem, als ich den mongod-Befehl nach der Installation unter Windows 10 ausgeführt habe. Ich habe den Mongodb-Dienst gestoppt und erneut gestartet. Arbeiten wie ein Zauber

Befehl zum Beenden des Mongodb-Dienstes (in Windows): net stop mongodb

Befehl zum Starten des Mongodb-Servers: mongod --dbpath PATH_TO_DATA_FOLDER

— aditya
quelle
1

Auf einer Fedora 18 mit Mongo 2.2.4-Instanz konnte ich einen ähnlichen Fehler umgehen, indem ich SELinux durch Aufrufen deaktivierte setenforce 0 als root .

Übrigens war dies eine Unternehmensumgebung, keine Amazon EC2-Instanz, aber die Symptome waren ähnlich.

— APS
quelle
1

In meinem Fall wurde das Problem durch Entfernen der Protokolldatei behoben .

sudo rm /log/mongod.log

Obwohl sich die Fehlermeldung speziell auf die Sperrdatei bezieht :

exception in initAndListen: 10309 Unable to create/open lock file: 
/data/mongod.lock errno:13 Permission denied 
Is a mongod instance already running?, terminating
— Ian Mercer
quelle
Dies zeigte mir die richtige Richtung. Auf meinem Server musste ich sudo rm /var/log/mongodb/mongodb.log und sudo rm /tmp/mongodb-27017.sock ausführen.
— Keith John Hutchison
1

Nachdem ich Mongod getötet hatte, hatte ich nur das gleiche Problem: Ich konnte Mongod nicht starten.

$> sudo kill `pidof mongod`

2015-08-03T05:58:41.339+0000 [initandlisten] exception in initAndListen: 10309 Unable to create/open lock file: /data/mongodbtest/replset/data/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating

Nachdem ich die Sperre direkt gelöscht habe, kann ich den Mongod-Prozess neu starten.

$>  rm -rf /data/mongodbtest/replset/data/mongod.lock
— Andy Dong
quelle
1

Folgendes habe ich getan, um das Problem zu beheben:

$ sudo mkdir -p / data / db

$ export PATH = / usr / local / Cellar / mongodb / 3.0.7 / bin: $ PATH

$ sudo chown -R id -u/ data / db

und dann Mongo zu starten ...

$ mongod

— user4660857
quelle
1

Ich hatte das gleiche Problem.

Ich habe es gelöst, indem ich den Selinux-Status mit dem folgenden Befehl in "Zulässig" geändert habe:

setenforce 0
— Maryam Jafari
quelle
0

Kennen Sie ls -laden Benutzer und die Gruppe von / var / log / mongodb. Dann sudo chown -R user:group /data/db laufen Sie jetzt sudo service mongodb start. Überprüfen Sie den Status mitsudo service mongodb status

— Tasneem Haider
quelle
0

Stellen Sie unter Windows sicher, dass die Konsole als Administrator gestartet ist

— Iacobescu Radu
quelle
0

Sie könnten es auf diese Weise versuchen. 1.

sudo chown -R mongod: mongod / data / db

aber manchmal ist dies nicht nützlich. 2 .. Wenn der oben beschriebene Weg nicht sinnvoll ist, können Sie Folgendes versuchen:

mkdir / data / db #als Datenbankspeicherpfad

nohup mongod --dbpath / data / db &

oder Typ:

mongod --dbpath / data / db

um den Ausgabestream zu erhalten

— Wotchin
quelle
In Anbetracht dessen, dass dies eine alte Frage ist und Ihre Antwort nichts hinzufügt, was noch nicht vorhanden ist, sollten Sie sich selbst fragen, ob es wertvoll ist ...
— Nic3500
0

Für mich unter CentOS 6.x:

sudo chown -R mongodb:mongodb <db-path> sudo service mongod restart

Und ich habe eine benutzerdefinierte gesetzt db-pathin /etc/mongod.conf.

— Yangsibai
quelle
0

In Centos Server

das funktioniert bei mir

chown -R mongod:mongod /var/lib/mongo
— Rajiv Sharma
quelle
0

Haben Sie einen ähnlichen Fehler, fest mit all Datensätze zu entfernen (in meinem Fall Verzeichnis journalsund Datei mongo.lock...), nach dem Check - Port mit sudo lsof -i:27017, wenn smth darauf laufenden kill <PID of the process>, und versuchen zu laufen ./mongodwieder

— chavy
quelle
-2

Fix: sudo mongod

Ich hatte das gleiche Problem, indem ich mongod mit sudo-Berechtigungen ausführte , um es zu beheben . Ich komme aus einer Windows-Umgebung und habe nur verwendetmongod den Daemon gestartet. Nun, es sieht so aus, als ob wir die Superuser-Berechtigungen benötigen, um auf / data / db zuzugreifen.

Sie können auch Nicht-Root-Benutzern Lese- und Schreibberechtigungen für diesen Pfad erteilen. Überprüfen Sie die Antworten oben für eine Anleitung!

— Aimuhire
quelle
Das Ausführen von Mongod als Root ist nicht erforderlich und macht das System möglicherweise anfälliger für Exploits
— qbert220,
-2

Jedes Mal, wenn Sie versuchen, Mongod zu starten, geben Sie einfach ein 

sudo mongod

oder wenn Sie dies dauerhaft beheben möchten, versuchen Sie einfach, dem Ordner / data / db eine rwx-Prämission zu geben

 chmod +rwx data/
— Shishir
quelle
Beides ist keine gute Idee. Das erste könnte das System anfälliger für Sicherheits-Exploits machen. Die zweite könnte es nicht privilegierten Benutzern ermöglichen, Ihre Mongo-Datenbanken zu manipulieren
— qbert220
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.