wake-up-neo.net

mongodb 3.4.3 Erlaubnis verweigert wiredtiger_kv_engine.cpp 267 Fehler mit Ubuntu 16

Ich habe Probleme, mongod als Dienst zu starten: Wie ist es möglich, dass es funktioniert, wenn ich Sudo mongod -f /etc/mongod.conf mache, aber wenn ich es mit Sudo service mongod start starte, bekomme ich einen Fehler im Log 

Assertion: 28595:13: Permission denied src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 267

Ich laufe Mongodb auf Ubuntu 16

Ich habe genau die Anweisungen in der mongodb-Dokumentation zur Installation dieser Version befolgt. Ist dies ein Fehler? Anregungen zur Lösung dieses Problems werden gebeten. 

Zusätzliche Information:

Das Skript für den Start des mongodb-Dienstes sieht folgendermaßen aus und führt es als Benutzer mongodb aus. Kann dies mit dem Fehler zusammenhängen? lib/systemd/system/mongodb.service:

[Unit]
Description=MongoDB Database Service
Wants=network.target
After=network.target

[Service]
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
User=mongodb
Group=mongodb
StandardOutput=syslog
StandardError=syslog

[Install]
WantedBy=multi-user.target
22
Nickpick

Ich habe Probleme, mongod als Dienst zu starten: Wie ist es möglich, dass es funktioniert, wenn ich Sudo mongod -f /etc/mongod.conf mache, aber beim Starten mit Sudo service mongod start bekomme ich einen Fehler im Protokoll

Der Befehl Sudo startet mongod mit root-Berechtigungen (aka Superuser-Zugriff ). Wenn Sie mongod als Dienst ausführen, werden Benutzer und Gruppe in der Dienstdefinition konfiguriert (in Ihrem Beispiel mongodb).

Es ist nicht erforderlich, den mongod-Prozess als root-Benutzer auszuführen, und dies wird nach der üblichen Sicherheitspraxis von Prinzip des geringsten Privilegs dringend empfohlen.

Wenn Sie eine Konfiguration über die Befehlszeile testen möchten, können Sie Sudo verwenden, um einen angegebenen Benutzer anstelle des Standardbenutzers (Root) auszuführen.

Zum Beispiel:

Sudo -u mongodb mongod -f /etc/mongod.conf 

Im Allgemeinen ist es am besten, eine Dienstkonfiguration zu verwenden, anstatt mongod manuell auszuführen. Beim manuellen Aufruf müssen Sie auch Parameter wie den Pfad der Konfigurationsdatei angeben (da es keinen Standard-Konfigurationspfad gibt). Ohne Konfigurationsdatei verwendet mongod auch Standardoptionen wie dbPath von /data/db.

Behauptung: 28595: 13: Erlaubnis verweigert src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 267

Die wahrscheinliche Ursache für Ihre Berechtigungsfehler ist, dass Sie mongod zuvor als Benutzer root gestartet haben. Einige Verzeichnisse und Dateien gehören möglicherweise dem Root-Benutzer, sodass der Benutzer mongodb nicht auf diese zugreifen kann. Ihr spezifischer Fehler bezieht sich auf den Zugriff auf Dateien im Datenverzeichnis (d. H. Der konfigurierte storage.dbPath in mongod.conf).

Vorausgesetzt, Sie haben die Standardpfade in Ihrer mongod.conf-Datei nicht geändert, sollten Sie in der Lage sein, Berechtigungen rekursiv an das anzupassen, was die mongod.service-Definition erwartet.

Stellen Sie zunächst sicher, dass Sie Ihre mongod-Instanz angehalten haben, wenn sie gerade ausgeführt wird.

Passen Sie dann die Berechtigungen rekursiv an den erwarteten Benutzer und die erwartete Gruppe an:

# storage.dbPath
Sudo chown -R mongodb:mongodb /var/lib/mongodb

# systemLog.path
Sudo chown -R mongodb:mongodb /var/log/mongodb

Jetzt sollten Sie mongod als Dienst starten können. Wenn der Dienst nicht startet, sollte die Protokolldatei mongod weitere Details enthalten (vorausgesetzt, die Protokolldatei kann vom Benutzer des Dienstes mongodb beschrieben werden).

36
Stennie

Habe das gleiche Problem.

Was war in /var/log/mongodb/mongod.log:

2017-05-13T13:46:41.152+0700 E STORAGE  [initandlisten] WiredTiger error (13) [1494658001:152518][15821:0x7fb843803cc0], connection: /var/lib/mongodb/journal/WiredTigerPreplog.0000000002: file-remove: unlink: Permission denied
2017-05-13T13:46:41.159+0700 I -        [initandlisten] Assertion: 28595:13: Permission denied src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 267

So sehen wir, dass die Datei "WiredTigerPreplog.0000000002" in /var/lib/mongodb/journal/ nicht entfernt werden kann.

Sudo chmod 764 /var/lib/mongodb/journal/

Wenn nicht helfen, probiere es aus:

Sudo chown -R mongodb:mongodb /var/lib/mongodb/ && Sudo chmod 764 /var/lib/mongodb/journal/
7
FreeStyler

Es gibt drei Setups, die diese Art von Problem auslösen:

  1. Die MongoDB-Installation ist so konfiguriert, dass Datenbankdateien unter einem bestimmten Pfad erstellt werden. Dieser Pfad ist auf Ihrem aktuellen System nicht vorhanden. Dieser Pfad wird in Mongo als dbpath bezeichnet.

Überprüfen Sie in Ihrem Fall, ob /data/db vorhanden ist. Wenn dies nicht der Fall ist oder wenn es leer ist, versucht mongod den falschen Datenbankpfad. Sie müssen es finden, normalerweise unter /var/lib/mongodb.

Sobald Sie es gefunden haben, können Sie zwei Dinge tun. Kopieren Sie zuerst die gesamte Datei von dort nach /data/db. Zweitens ändern Sie Ihren Datenbankpfad unter der Datei mongod.conf, die sich unter Linux in /etc/mongod.conf befindet. Stellen Sie sicher, dass Sie mongod mit dem --config starten, der die Konfigurationsdatei angibt.

  1. MongoDB hat keine Berechtigung zum Lesen einer oder mehrerer Dateien oder Verzeichnisse, die seinem Datenbankpfad entsprechen. 

chown mongodb:mongodb dbpath -R.

  1. In MongoDB fehlt WiredTiger.wt. Dies kann passieren, wenn Sie Dateien unter dem Datenbankpfad entfernen oder wenn ein Gerätefehler vorliegt. Wir machen es zum Beispiel, um eine Wiederherstellungsstrategie zu testen.

Wenn Sie sicher sind, dass dbpath korrekt ist und es keine Instanz von WiredTiger.wt gibt. Ihre Datenbank ist defekt Es gibt keine Möglichkeiten, die Integrität sicherzustellen, wenn Sie diese Datei verlieren. Installieren Sie Mongodb von:

Sudo apt-get purge mongodb-org*

Sudo rm -r dbpath

Sudo apt-get install mongodb-org

Bearbeiten Sie: Oder kopieren Sie dbpath von einer Ihrer Repliken.

4
Pobe

Ich möchte an die vorige Antwort einen Kommentar anhängen, kann es aber leider noch nicht.

Ich stimme der Erklärung von Stennie vollkommen zu. Es ist genau das, was mir passiert ist. Ich habe mongod immer als Dienst ausgeführt, aber heute, da einige Änderungen, die ich vorgenommen habe, versucht habe, den Prozess mit Sudo mongod --auth --dbpath /data/mongodb/ auszuführen, um Berechtigungen und Datenbank zu testen Standort ändern Danach wurde der Mongod-Dienst aufgrund dieses Berechtigungsproblems nicht mehr ausgeführt.

Ich muss sagen, dass der Befehl Sudo chown -R mongodb:mongodb /data/mongodb/ das Problem nicht sofort wie erwartet behoben hat. Ich musste mehrmals neu starten, die mongod.lock-Datei unter /data/mongodb/ entfernen, den Sudo chown-Befehl erneut ausgeben .. und schließlich ist alles gut gegangen.

0
jakodev