Impossible de créer / ouvrir le fichier de verrouillage: /data/mongod.lock errno: 13 Autorisation refusée

187

Comment faire pour que mongo utilise un lecteur monté sur ec2? Je ne comprends vraiment pas. J'ai attaché un volume sur ec2 formaté le lecteur en tant que root et démarrer en tant que root et pourtant en tant que root, je ne peux pas accéder? Je cours sur Ubuntu 12.04. Aucun autre mongo ne court

Je vois que mongo a créé un dir 'db' dans / data ie / data / db

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

Ci-dessous, si je redémarre lorsque je supprime un fichier de verrouillage ...

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
Tampa
la source
1
On dirait que mongod s'est mal arrêté la dernière fois qu'il a été exécuté et n'a pas été en mesure de nettoyer le fichier mongod.lock qu'il a créé. Ce fichier existe pour empêcher plusieurs instances de mongod de fonctionner sur le fichier. Si vous supprimez le fichier et essayez à nouveau d'exécuter mongod, vous ne devriez avoir aucun problème
ACE
2
Voir la question mise à jour. Même problème si supprimer le fichier de verrouillage
Tampa
Semble toujours être un problème avec le fichier de verrouillage, quelles sont les autorisations sur le répertoire dans lequel se trouve le fichier de verrouillage? TBH Je n'ai vu cela que dans 2 cas: 1) le fichier de verrouillage existe déjà et 2) mongod n'a pas les autorisations pour créer le fichier de verrouillage à l'emplacement souhaité.
ACE
1
Vous devez vous assurer que l'utilisateur mongo a accès,, chown mongodb:mongodb on /var/lib/monogdbégalement au répertoire de données.
Hans N.Hjort

Réponses:

117

J'avais le même problème sur une instance Ubuntu ec2. Je suivais cet article Amazon à la page 7:

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

Le chemin Mongodb dans a /etc/mongodb.confété défini sur /var/lib/mongodb(emplacement d'installation principal et fonctionnement). Quand je suis passé à /data/db(volume EBS), j'obtenais «errno: 13 Permission refusée».

  1. D'abord j'ai couru sudo service mongodb stop .
  2. Ensuite, j'avais l'habitude ls -lade voir à quel groupe et propriétaire mongodb était assigné /var/lib/mongodb(chemin existant) et j'ai changé le /data/db(nouveau chemin) avec chownet chgrppour correspondre. (exemple: sudo chown -R mongodb:mongodb /data/db)
  3. Ensuite , je mis à jour le chemin etc/mongodb.confvers /data/dbet supprimé les anciens fichiers mongo dans le /var/lib/mongodbrépertoire.
  4. Puis j'ai couru sudo service mongodb startet j'ai attendu environ une minute. Si vous essayez de vous connecter immédiatement au 27017, vous ne pourrez pas le faire.
  5. Après une minute de vérification /data/db(volume EBS) et mongo devrait avoir placé un journal, mongod.lock, local.ns, local.0, etc. Sinon, essayez de sudo service mongodb restartvérifier une minute plus tard.

Je viens de passer plus d'une heure avec ça. Changer le groupe et supprimer les anciens fichiers n'est probablement pas nécessaire, mais c'est ce qui a fonctionné pour moi.

Ceci est une excellente vidéo sur le montage d'un volume ebs sur une instance ec2:

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

Randy Swanson
la source
8
Je luttais avec ce problème et je me suis rendu compte que si vous listiez votre dossier de destination avec ls -lahZ, cela vous donnera le contexte de sécurité, le contexte du dossier de données mongo devrait être défini comme: "sudo chcon -R -u system_u -t mongod_var_lib_t / folder / data "ceci en plus des permissions évidentes et de la combinaison utilisateur: groupe. J'espère que ça aide.
jmdiego
478

J'utilise cette méthode pour résoudre le problème:

sudo chown -R mongodb:mongodb /data/db
Haimei
la source
8
Ajoutez une -Roption et c'est parfait :)
Adrien
7
c'est: sudo chown -R id -u/ data / db pour les non-initiés. :)
rncrtr
8
Il s'avère qu'il y a un problème avec les backticks. Essayez d'exécuter sudo chown $USER /data/dbau lieu de la commande d'origine.
Paymahn Moghadasian
7
C'est en effet la bonne réponse. @Tampa, vous devriez accepter cette réponse. btw - vous n'avez pas besoin du id -Uou des $USERtrucs. mongo a son propre utilisateur / groupe. vous pouvez et devez coder en dur mongodb: mongodb. donc la commande est simplementsudo chown -R mognodb:mognodb /data/db
guy mograbi
11
Qu'est-ce que cela fait réellement? Cela fonctionne, mais j'aimerais comprendre :)
zero_cool
81

Dans mon cas (instance AWS EC2, Ubuntu) a aidé:

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

Et après cela, tout a bien fonctionné.

Belhor
la source
6
C'est la meilleure réponse, il s'agit probablement d'un problème d'autorisations avec l'utilisateur exécutant mongod
davo
2
Oui, c'est la meilleure réponse
Vegan Sv
1
Nous changeons / transférons la propriété de /data/dbàUSERNAME
Saif
52

Il vous suffit de donner accès à votre /data/dbdossier.

Tapez sudo chown -R <USERNAME> /data/db, remplacez <USERNAME>par votre nom d'utilisateur.

Vous pouvez trouver votre nom d'utilisateur en tapant whoami.

Julien Bouteloup
la source
12

J'ai installé mongodb avec EBS sur un EC2 avec Ubuntu 14.04 en suivant ce tutoriel:

http://docs.mongodb.org/ecosystem/platforms/amazon-ec2/

Mais au lieu du chown suggéré, j'ai fait:

sudo chown -R mongodb:mongodb /data /log /journal

Pour résoudre le problème

Evers
la source
2
Oui, il semble que le propriétaire doit être "mongodb" au lieu de "root" quelque chose.
Imskull
10

J'ai eu un problème similaire, la raison réelle était qu'il y avait déjà une session mongod en cours d'exécution depuis ma précédente tentative.

L'Iran

killall mongod

et tout le reste s'est déroulé comme prévu.

killallLa commande enverrait un signal TERM à tous les processus avec un UID réel. Donc, cela tue toutes les instances en cours d'exécution de mongod afin que vous puissiez démarrer la vôtre.

Venky Soorisetty
la source
C'est littéralement la réponse la plus courte et la seule réponse qui a résolu mon problème après d'innombrables heures ... merci!
moomoochen
Heureux que cela ait aidé! :) J'aimerais qu'il y ait un moyen d'aider les gens à trouver cette réponse plus facilement.
Venky Soorisetty
7

À partir d'aujourd'hui, j'ai essayé de me frayer un chemin dans le fichier pour créer / ouvrir le fichier de verrouillage: /data/db/mongod.lock errno: 13 Autorisation refusée Une instance de mongod est-elle déjà en cours d'exécution?, Se terminant , et j'ai essayé toutes les réponses publiées ci-dessus sur résoudre ce problème, donc rien n'a fonctionné en ajoutant

sudo chown -R mongodb: mongodb / data / db

Sauf si j'ai ajouté mon autorisation d'utilisateur actuel au chemin de l'emplacement en

sudo chown $ USER / data / db

J'espère que cela aide quelqu'un. De plus, je viens d'installer Mongo DB sur mon pi. À votre santé!

Abdullah
la source
C'est la vraie solution au problème
Sahil Nagpal
6

J'ai eu un problème similaire et j'ai suivi toutes les instructions ci-dessus concernant le changement de propriétaire en utilisant sudo chown, etc. J'avais encore une instance de mongodb en arrière-plan après les changements. Fonctionnement

ps auxw | grep mongo 

m'a montré d'autres tâches utilisant mongo en arrière-plan qui n'étaient pas fermées correctement. J'ai ensuite exécuté kill sur tous ceux en cours d'exécution, puis j'ai pu démarrer mon serveur.

Eugène G
la source
6

Pour les utilisateurs de mac:
Exécutez ls -ld / data / db / La
sortie doit être quelque chose comme drwrx-xr-x 20 singh wheel 680 21 juil 05:49 / data / db /
singh est le propriétaire et wheel est le groupe auquel il appartient .
Exécutez sudo chown -R singh: wheel / data / db
Run mongod

amanSingh
la source
5

La suppression du fichier mongodb.lock n'était pas le problème dans mon cas. Je l'ai fait et j'ai eu une erreur concernant le port utilisé: [initandlisten] listen (): bind () failed errno: 98 Adresse déjà utilisée pour le socket: 0.0.0.0:27017. J'ai trouvé une autre solution ici: impossible de démarrer le serveur local mongodb avec des instructions pour tuer le processus:

  1. Découvrez sur netstat quel processus exécute le port mongodb (27017)

    sudo netstat -tulpn | grep :27017

    La sortie sera: tcp 0 0 0.0.0.0:27017 0.0.0.0:* LISTEN 1412 / mongod

  2. Tuez le processus approprié.

    sudo kill 1412 (remplacez 1412 par votre ID de processus trouvé à l'étape 1)

Et j'ai réussi à redémarrer mongodb avec succès. Je crois que le mien fonctionnait toujours après un arrêt inapproprié.

Casey Murray
la source
4

Pour ceux d'entre vous qui rencontrent cette erreur sous Windows à l'aide du Gestionnaire des tâches, arrêtez l'instance de «mongod.exe» en cours d'exécution. Une fois que cela est fait, supprimez définitivement le fichier mongo.lock et exécutez mongod.exe. Cela devrait fonctionner parfaitement après cela.

b_kik
la source
4

Mon mongo (3.2.9) a été installé sur Ubuntu et mon fichier journal comportait les lignes suivantes:

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 JE CONTRÔLE [initandlisten] dbexit: rc: 100

Le problème était donc dans les autorisations sur le dossier / var / lib / mongodb.

sudo chown -R mongodb:mongodb /var/lib/mongodb/
sudo chmod -R 755 /var/lib/mongodb
  • Redémarrez le serveur

Correction du problème, même si je me rends compte que ce n'est peut-être pas trop sécurisé (c'est ma propre boîte de développement, je suis dans mon cas), peu après le changement, la base de données et l'authentification ont fonctionné.

Nestor Milyaev
la source
2

Dans Mycase Dans mongodb
version 2.6.11, le répertoire de base de données par défaut est/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
la source
devrait être `id -u`
marcus
2

J'ai eu le même problème lorsque j'ai exécuté la commande mongod après l'avoir installée sur Windows10. J'ai arrêté le service mongodb et l'ai redémarré. Travailler comme un charme

Commande pour arrêter le service mongodb (dans Windows): net stop mongodb

Commande pour démarrer le serveur mongodb: mongod --dbpath PATH_TO_DATA_FOLDER

aditya
la source
1

Sur une instance de Fedora 18 avec Mongo 2.2.4, j'ai pu contourner une erreur similaire en désactivant SELinux en appelant en setenforce 0tant que root.

BTW, c'était un environnement d'entreprise, pas une instance Amazon EC2, mais les symptômes étaient similaires.

GSP
la source
1

Dans mon cas, le problème a été résolu en supprimant le fichier journal .

sudo rm /log/mongod.log

Bien que le message d'erreur se réfère spécifiquement au fichier de verrouillage :

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
la source
Cela m'a orienté dans la bonne direction. SUR mon serveur, j'ai dû faire sudo rm /var/log/mongodb/mongodb.log et sudo rm /tmp/mongodb-27017.sock.
Keith John Hutchison
1

Après avoir tué mongod, j'ai eu le même problème: je ne pouvais pas démarrer mongod.

$> 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

Après avoir supprimé le verrou directement, je peux redémarrer le processus mongod.

$>  rm -rf /data/mongodbtest/replset/data/mongod.lock
Andy Dong
la source
1

Voici ce que j'ai fait pour résoudre le problème:

$ sudo mkdir -p / data / db

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

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

et puis pour commencer mongo ...

$ mongod

user4660857
la source
1

J'ai eu le même problème.

Je l'ai résolu en changeant le statut de selinux en permissif avec la commande ci-dessous:

setenforce 0
Maryam Jafari
la source
0

Faire ls -laconnaître l'utilisateur et le groupe de / var / log / mongodb. Ensuite sudo chown -R user:group /data/db , exécutez maintenant sudo service mongodb start. Vérifiez l'état avecsudo service mongodb status

Tasneem Haider
la source
0

Sous Windows, assurez-vous que la console est démarrée en tant qu'inistrateur

Iacobescu Radu
la source
0

Vous pouvez essayer par ces moyens. 1er.

sudo chown -R mongod: mongod / data / db

mais à certains moments, ce n'est pas utile. 2ème. si la méthode ci-dessus n'est pas utile, vous pouvez essayer de le faire:

mkdir / data / db # comme chemin de stockage de la base de données

nohup mongod --dbpath / data / db &

ou tapez:

mongod --dbpath / data / db

pour obtenir le flux de sortie

Wotchin
la source
Considérant que c'est une vieille question, et que votre réponse n'ajoute rien qui ne soit déjà là, vous devriez vous demander si elle a de la valeur ...
Nic3500
0

Pour moi sur CentOS 6.x:

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

Et j'ai mis une coutume db-pathdans /etc/mongod.conf.

Yangsibai
la source
0

Dans Centos Server

cela fonctionne pour moi

chown -R mongod:mongod /var/lib/mongo
Rajiv Sharma
la source
0

Vous avez une erreur similaire, corrigée en supprimant tous les enregistrements (dans le répertoire journalset le fichier de mon cas mongo.lock...), après ce port de vérification avec sudo lsof -i:27017, si smth s'exécute dessus kill <PID of the process>, et essayez de ./mongodrecommencer

chavy
la source
-2

Réparer: sudo mongod

J'ai eu le même problème, exécuter mongod avec les privilèges sudo l'a corrigé. Venant d'un environnement Windows, j'ai utilisé justemongod pour démarrer le démon, et bien il semble que nous ayons besoin des privilèges de superutilisateur pour accéder à / data / db.

Vous pouvez également accorder aux utilisateurs non root des autorisations de lecture et d'écriture sur ce chemin. Vérifiez les réponses ci-dessus pour un guide!

aimuhire
la source
Exécuter mongod en tant que root n'est pas nécessaire et peut rendre le système plus vulnérable aux exploits
qbert220
-2

Chaque fois que vous essayez de démarrer mongod, tapez simplement

sudo mongod

ou si vous voulez définitivement résoudre ce problème, essayez simplement de donner la prémission rwx au dossier / data / db

 chmod +rwx data/
Shishir
la source
Ni l'un ni l'autre ne sont une bonne idée. Le premier pourrait rendre le système plus vulnérable aux exploits de sécurité. La seconde pourrait permettre aux utilisateurs non privilégiés de falsifier vos bases de données mongo
qbert220