web-dev-qa-db-ja.com

mongodb 3.4.3許可は、ubuntu 16でwiredtiger_kv_engine.cpp 267エラーを拒否しました

サービスとしてmongodを起動するのに問題があります:Sudo mongod -f /etc/mongod.confを実行すると動作する可能性がありますが、Sudo service mongod startで起動するとログにエラーが表示されます

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

私はubuntu 16でmongodbを実行しています

そのバージョンのインストールについては、mongodbのドキュメントの指示に正確に従いましたが、これはバグですか?これを解決する方法を提案していただければ幸いです。

追加情報:

Mongodbサービスの起動スクリプトは次のようになり、ユーザーmongodbとして実行されますが、これはエラーに接続できますか? 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
29
Nickpick

サービスとしてmongodを起動するのに問題があります:Sudo mongod -f /etc/mongod.confを実行すると動作する可能性がありますが、Sudo service mongod startで起動するとログにエラーが表示されます

Sudoコマンドは、mongodパーミッション(別名 スーパーユーザーアクセス )でrootを開始します。 mongodをサービスとして実行する場合、ユーザーとグループはサービス定義で構成されます(例では両方ともmongodb)。

mongodプロセスをrootユーザーとして実行する必要はありません。これは、 最小特権の原則 の一般的なセキュリティ慣行に従って推奨されません。

コマンドラインから設定をテストしたい場合、デフォルトの(root)ユーザーの代わりにSudoを使用して指定したユーザーで実行できます。

例えば:

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

一般的に、mongodを手動で実行するのではなく、サービス構成を使用するのが最善です。手動呼び出しでは、構成ファイルのパスなどのパラメーターを含めることも忘れないでください(デフォルトの構成パスはありません)。構成ファイルがない場合、mongodは、/data/dbdbPathなどのデフォルトオプションも使用します。

アサーション:28595:13:許可が拒否されましたsrc/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 267

許可エラーの原因としては、mongodrootユーザーとして以前に起動したことが考えられます。一部のディレクトリとファイルは現在rootユーザーが所有している可能性があるため、mongodbユーザーはそれらにアクセスできません。特定のエラーは、データディレクトリ内のファイルへのアクセスに関連しています(つまり、storage.dbPathで構成されたmongod.conf)。

mongod.confファイルのデフォルトのパスを変更していないと仮定すると、mongod.service定義が期待するものに一致するようにパーミッションを再帰的に調整できるはずです。

まず、mongodインスタンスが現在実行されている場合は停止していることを確認してください。

次に、予想されるユーザーとグループのアクセス許可を再帰的に調整します。

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

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

これで、mongodをサービスとして開始できるはずです。サービスの開始に失敗した場合は、mongodログファイルに詳細が含まれている必要があります(ログファイルがmongodbサービスユーザーによって書き込み可能であると仮定)。

47
Stennie

同じ問題があります。

/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

だから、/ var/lib/mongodb/journal /にあるファイル「WiredTigerPreplog.0000000002」を削除できないことがわかるので、idが許可を与えただけでした。

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

助けにならなければ、試してください:

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

この種の問題を引き起こす3つのセットアップがあります。

  1. MongoDBインストールは、指定されたパスにデータベースファイルを作成するように構成されており、このパスは現在のシステムに存在しません。このパスは、mongoでは dbpath と呼ばれます。

あなたの場合、/data/dbが存在するかどうかを確認してください。そうでない場合、または空の場合、mongodは間違ったdbpathを試行しています。あなたはそれを見つける必要があります、それは通常/var/lib/mongodbの下にあります。

見つかったら、2つのことができます。まず、そこからすべてのファイルを/data/dbにコピーします。次に、/etc/mongod.confにある(Linuxでは)mongod.confファイルの下でdbpathを変更します。構成ファイルを指定する--configでmongodを必ず起動してください。

  1. MongoDBには、dbpathに対応する1つ以上のファイルまたはディレクトリを読み取る権限がありません。

chown mongodb:mongodb dbpath -R

  1. MongoDBにはWiredTiger.wtがありません。これは、dbpathの下にあるファイルを削除した場合、またはデバイスに障害がある場合に発生する可能性があります。たとえば、リカバリ戦略をテストするために行います。

Dbpathが正しいこと、およびWiredTiger.wtのインスタンスが存在しないことが確実な場合。データベースが壊れています。このファイルを紛失した場合、整合性を確保する方法はありません。以下によってmongodbを再インストールします。

Sudo apt-get purge mongodb-org*

Sudo rm -r dbpath

Sudo apt-get install mongodb-org

編集:または、レプリカの1つからdbpathをコピーします。

6
Pobe

前の回答にコメントを追加したいのですが、残念ながらまだできません。

私はステニーの説明に完全に同意します。それはまさに私に起こったことです。私は常にmongodをサービスとして実行していますが、今日、いくつかの変更を加えたため、Sudo mongod --auth --dbpath /data/mongodb/ ..を使用してプロセスを実行し、認証とdbの場所の変更をテストしようとしました。その後、この権限の問題により、mongodサービスは実行されなくなりました。

コマンドSudo chown -R mongodb:mongodb /data/mongodb/は、期待どおりにすぐに問題を解決しなかったと言わざるを得ません。何回か再起動し、mongod.lockの下の/data/mongodb/ファイルを削除し、Sudo chownコマンドを再発行する必要がありました。そして、すべてがうまくいきました。

0
jakodev