mongodb 3.4.3 Autorisation refusée Erreur wiredtiger_kv_engine.cpp 267 avec Ubuntu 16
J'ai des problèmes pour lancer mongod en tant que service: Comment est-il possible que cela fonctionne lorsque je fais Sudo mongod -f /etc/mongod.conf mais lors du lancement avec le service Sudo mongod start, un message d'erreur s'affiche
Assertion: 28595:13: Permission denied src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 267
Je cours mongodb sur Ubuntu 16
J'ai suivi exactement les instructions de la documentation de mongodb pour l'installation de cette version, s'agit-il d'un bogue? Toutes les suggestions pour résoudre ceci sont appréciées.
Information additionnelle:
Le script de démarrage du service mongodb ressemble à ceci et s’exécute en tant qu’utilisateur mongodb, est-ce que cela pourrait être lié à l’erreur? 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
J'ai des problèmes pour lancer mongod en tant que service: comment est-il possible que cela fonctionne lorsque je fais Sudo mongod -f /etc/mongod.conf mais lors du lancement avec le service Sudo mongod start, une erreur s'est produite dans le journal
La commande Sudo démarre mongod avec les autorisations root (alias accès superutilisateur ). Si vous exécutez mongod en tant que service, l'utilisateur et le groupe sont configurés dans la définition de service (mongodb pour les deux dans votre exemple).
Il n'est pas nécessaire d'exécuter le processus mongod en tant qu'utilisateur root et cela est fortement déconseillé, conformément à la pratique de sécurité courante de Principe du moindre privilège .
Si vous souhaitez tester une configuration à partir de la ligne de commande, vous pouvez utiliser Sudo pour s'exécuter avec un utilisateur spécifié à la place de l'utilisateur par défaut (root).
Par exemple:
Sudo -u mongodb mongod -f /etc/mongod.conf
En général, il est préférable d'utiliser une configuration de service plutôt que d'exécuter mongod manuellement. Avec l'appel manuel, vous devez également vous rappeler d'inclure des paramètres tels que le chemin du fichier de configuration (car il n'y a pas de chemin de configuration par défaut). Sans fichier de configuration, mongod utilise également des options par défaut, telles que dbPath de /data/db.
Assertion: 28595: 13: autorisation refusée src/mongo/db/stockage/wiredtiger/wiredtiger_kv_engine.cpp 267
La cause probable de vos erreurs d'autorisation est d'avoir précédemment lancé mongod en tant qu'utilisateur root. Certains répertoires et fichiers peuvent maintenant appartenir à l'utilisateur root. Par conséquent, l'utilisateur mongodb ne peut pas y accéder. Votre erreur spécifique est liée à l’accès aux fichiers du répertoire de données (c’est-à-dire le storage.dbPath configuré dans mongod.conf).
En supposant que vous n’ayez pas modifié les chemins par défaut dans votre fichier mongod.conf, vous devriez pouvoir ajuster de manière récursive les autorisations pour correspondre aux attentes de la définition mongod.service.
Tout d’abord, assurez-vous d’avoir arrêté votre instance mongod si elle est en cours d’exécution.
Ensuite, ajustez de manière récursive les autorisations sur l'utilisateur et le groupe attendus:
# storage.dbPath
Sudo chown -R mongodb:mongodb /var/lib/mongodb
# systemLog.path
Sudo chown -R mongodb:mongodb /var/log/mongodb
Vous devriez maintenant pouvoir démarrer mongod en tant que service. Si le service ne parvient pas à démarrer, le fichier journal mongod devrait contenir davantage de détails (en supposant que le fichier journal puisse être écrit par l'utilisateur du service mongodb).
J'ai le même problème.
Qu'est-ce qui a été dans /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
Nous voyons donc que quelque chose ne peut pas supprimer le fichier "WiredTigerPreplog.0000000002" dans /var/lib/mongodb/journal/So id vient de donner des autorisations, je viens de le faire:
Sudo chmod 764 /var/lib/mongodb/journal/
Si pas aider, essayez:
Sudo chown -R mongodb:mongodb /var/lib/mongodb/ && Sudo chmod 764 /var/lib/mongodb/journal/
Il y a trois configurations qui déclenchent ce genre de problème:
- L'installation de MongoDB est configurée pour créer des fichiers de base de données sur un chemin donné et ce chemin n'existe pas sur votre système actuel. Ce chemin s'appelle dbpath in mongo.
Dans votre cas, vérifiez si /data/db existe. Si ce n'est pas le cas ou s'il est vide, Mongod essaie le mauvais chemin d'accès. Vous devez le trouver, il se trouve généralement sous /var/lib/mongodb.
Une fois que vous l'avez trouvé, vous pouvez faire deux choses. Commencez par copier tout le fichier à partir de /data/db. Deuxièmement, modifiez votre chemin dbpath sous le fichier mongod.conf, qui se trouve (sous linux) à /etc/mongod.conf. Assurez-vous de démarrer mongod avec le --config spécifiant le fichier de configuration.
- MongoDB n’est pas autorisé à lire un ou plusieurs fichiers ou répertoires correspondant à son dbpath.
chown mongodb:mongodb dbpath -R.
- Il manque WoolTiger.wt pour MongoDB. Cela peut se produire si vous supprimez des fichiers sous le chemin d'accès à la base de données ou en cas de défaillance d'un périphérique. Nous le faisons pour tester une stratégie de récupération, par exemple.
Si vous êtes sûr que dbpath est correct et qu'il n'y a aucune instance de WiredTiger.wt là-bas. Votre base de données est cassée. Il n'y a aucun moyen de garantir l'intégrité si vous perdez ce fichier. Réinstallez mongodb en:
Sudo apt-get purge mongodb-org*
Sudo rm -r dbpath
Sudo apt-get install mongodb-org
Éditez: .__ ou copiez dbpath à partir de l’un de vos réplicas.
Je souhaite ajouter un commentaire à la réponse précédente, mais malheureusement, je ne le peux pas encore.
Je suis complètement d'accord avec l'explication de Stennie. C’est exactement ce qui m’est arrivé… .. J'ai toujours exécuté mongod en tant que service, mais aujourd’hui, à cause de certaines modifications apportées, j’ai essayé d’exécuter le processus avec Sudo mongod --auth --dbpath /data/mongodb/ .. pour tester les autorisations et la base de données. changer de lieu. Après cela, le service Mongodod ne fonctionnait plus, à cause de ce problème d'autorisations.
Je dois dire que la commande Sudo chown -R mongodb:mongodb /data/mongodb/ n'a pas immédiatement résolu le problème comme prévu. J'ai dû redémarrer plusieurs fois, supprimer le fichier mongod.lock sous /data/mongodb/, relancer à nouveau la commande Sudo chown .. et enfin tout s'est bien passé.