Mongod se plaint de l'absence de dossier/data/db
J'utilise mon nouveau Mac pour la première fois aujourd'hui. Je suis le guide de démarrage sur le site mongodb.org jusqu'à l'étape où l'on crée le répertoire/data/db. Au fait, j'ai utilisé la route homebrew.
Donc, j'ouvre un terminal, et je pense que je suis à ce que vous appelez le répertoire personnel, car lorsque je fais "ls", je vois les dossiers de Desktop Application Films Music Pictures Documents et Library.
Alors j'ai fait un
mkdir -p /data/db
d'abord, il est dit que l'autorisation est refusée. J'ai continué à essayer différentes choses pendant une demi-heure et finalement:
mkdir -p data/db
travaillé. et quand je "ls", il existe un répertoire de données et un dossier de base de données.
alors je tire mongod et il se plaint de ne pas trouver des données/db
Ai-je fait quelque chose de mal?
Maintenant j'ai fait la
Sudo mkdir -p /data/db
et quand je fais un "ls", je vois le répertoire data et le répertoire db. à l'intérieur du répertoire db cependant, il n'y a absolument rien dedans et quand je lance maintenant Mongod
Sun Oct 30 19:35:19 [initandlisten] exception in initAndListen: 10309 Unable to create/open lock file: /data/db/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating
Sun Oct 30 19:35:19 dbexit:
Sun Oct 30 19:35:19 [initandlisten] shutdown: going to close listening sockets...
Sun Oct 30 19:35:19 [initandlisten] shutdown: going to flush diaglog...
Sun Oct 30 19:35:19 [initandlisten] shutdown: going to close sockets...
Sun Oct 30 19:35:19 [initandlisten] shutdown: waiting for fs preallocator...
Sun Oct 30 19:35:19 [initandlisten] shutdown: lock for final commit...
Sun Oct 30 19:35:19 [initandlisten] shutdown: final commit...
Sun Oct 30 19:35:19 [initandlisten] shutdown: closing all files...
Sun Oct 30 19:35:19 [initandlisten] closeAllFiles() finished
Sun Oct 30 19:35:19 [initandlisten] shutdown: removing fs lock...
Sun Oct 30 19:35:19 [initandlisten] couldn't remove fs lock errno:9 Bad file descriptor
Sun Oct 30 19:35:19 dbexit: really exiting now
EDIT Obtenir un message d'erreur pour
Sudo chown mongod:mongod /data/db
chown: mongod: Invalid argument
Merci tout le monde!
Vous avez créé le répertoire au mauvais endroit
/ data/db signifie qu'il se trouve directement dans le répertoire racine '/', alors que vous avez créé 'data/db' (sans le /) principal, probablement juste dans un autre répertoire, tel que le répertoire racine '/ root'.
Vous devez créer ce répertoire en tant que root
Soit vous devez utiliser Sudo, par exemple. Sudo mkdir -p /data/db
Ou vous devez faire su - pour devenir superutilisateur, puis créer le répertoire avec mkdir -p /data/db
Remarque:
MongoDB propose également une option permettant de créer le répertoire de données à un autre emplacement, mais ce n'est généralement pas une bonne idée, car cela complique légèrement les choses telles que la récupération de base de données, car vous devez toujours spécifier manuellement le chemin d'accès à la base de données. Je ne recommanderais pas cela.
Modifier:
le message d'erreur que vous obtenez est "Impossible de créer/ouvrir le fichier de verrouillage: /data/db/mongod.lock errno: 13 Autorisation refusée". Le répertoire que vous avez créé ne semble pas avoir les autorisations et la propriété appropriées -- il doit être accessible en écriture à l'utilisateur qui exécute le processus MongoDB.
Pour voir les autorisations et la propriété du répertoire '/ data/db /', procédez comme suit: (Voici à quoi devraient ressembler les autorisations et la propriété)
$ ls -ld /data/db/
drwxr-xr-x 4 mongod mongod 4096 Oct 26 10:31 /data/db/
Le côté gauche 'drwxr-xr-x' indique les autorisations pour l'utilisateur, le groupe et les autres. 'mongod mongod' indique à qui appartient le répertoire et à quel groupe appartient ce répertoire qui appartient à . Les deux sont appelés «mongod» dans ce cas.
Si votre répertoire '/ data/db' ne dispose pas des autorisations et de la propriété ci-dessus, procédez comme suit:
Commencez par vérifier quel utilisateur et groupe votre utilisateur mongo a:
# grep mongo /etc/passwd
mongod:x:498:496:mongod:/var/lib/mongo:/bin/false
Vous devriez avoir une entrée pour mongod dans/etc/passwd, car c'est un démon.
Sudo chmod 0755 /data/db
Sudo chown -R 498:496 /data/db # using the user-id , group-id
Vous pouvez également utiliser le nom d'utilisateur et le nom de groupe, comme suit: .__ (ils peuvent être trouvés dans/etc/passwd et/etc/group)
Sudo chown -R mongod:mongod /data/db
cela devrait le faire fonctionner ..
Dans les commentaires ci-dessous, certaines personnes ont utilisé ceci:
Sudo chown -R `id -u` /data/db
Sudo chmod -R go+w /data/db
ou
Sudo chown -R $USER /data/db
Sudo chmod -R go+w /data/db
L'inconvénient est que $ USER est un compte qui a un shell de connexion . Les démons devraient idéalement ne pas avoir de shell pour des raisons de sécurité, c'est pourquoi vous voyez/bin/false dans le grep du fichier de mots de passe ci-dessus.
Cochez ici pour mieux comprendre la signification des autorisations de répertoire:
http://www.perlfect.com/articles/chmod.shtml
Vous pouvez également consulter l'un des didacticiels que vous pouvez trouver via Google: "UNIX pour débutants"
Après avoir obtenu la même erreur que Nik
chown: id -u: argument incorrect
J'ai découvert que c'était apparemment dû à l'utilisation du mauvais type de guillemets (aurait dû être backquotes) Forums Ubuntu
Au lieu de cela, je viens d'utiliser
Sudo chown $ USER/data/db
comme alternative et maintenant mongod a les permissions nécessaires.
Cela fonctionne pour moi, trouvé dans les commentaires:
Sudo chown -R $USER /data/db
Créez le dossier.
Sudo mkdir -p /data/db/
Donnez-vous la permission pour le dossier.
Sudo chown `id -u` /data/db
Ensuite, vous pouvez exécuter mongod sans Sudo. Fonctionne sur OSX Yosemite
Pour corriger cette erreur sous OS X, j'ai redémarré et arrêté le service:
$ brew services restart mongodb
$ brew services stop mongodb
Ensuite, j'ai exécuté mongod --config /usr/local/etc/mongod.conf, et le problème avait disparu.
L'erreur semblait se produire après la mise à niveau du paquet homebrew de mongodb.
Installation via brassage sur Mac où YOUR_USER_NAME et staff est le groupe
Sudo mkdir -p /data/db
Sudo chmod +x+r+w /data/db/
Sudo touch /data/db/mongod.lock
Sudo chown YOUR_USER_NAME:staff /data/db
Sudo chmod +x+r+w /data/db/mongod.lock
Sudo chown YOUR_USER_NAME:staff /data/db/mongod.lock
Si vous exécutez mongo sans argument, cela suppose que vous utilisez la machine de production et que vous utilisez les emplacements par défaut.
pour utiliser votre propre base de données (dev ou juste une autre):
./bin/mongod --dbpath ~/data/db
J'ai surmonté le même problème en créant les dossiers/data/db avec mon gestionnaire de fenêtres. J'ai d'abord essayé de le faire via le terminal et pour créer un dossier dans le répertoire racine, je devais utiliser Sudo.
Je viens d'aller dans le répertoire racine à l'aide du Finder et j'ai créé un nouveau dossier avec "Nouveau dossier". Totalement travaillé pour moi.
Note: J'utilise OSX.
Votre commande aura créé la structure de répertoires dans le dossier actuel, et non dans le répertoire racine de votre ordinateur (c'est-à-dire le / manquant).
La première commande était correcte, mais comme vous essayez de créer un dossier dans /, qui est un répertoire protégé, vous devez le préfixer avec Sudo, qui est l'abréviation de "superuser do". On vous demandera alors votre mot de passe.
Donc, la commande complète serait:
$ Sudo mkdir -p /data/db
Vous devez créer/ data/db... qui est un répertoire appelé/data/dans votre racine (c'est-à-dire/) et un sous-dossier appelé/db/...
Vous obtenez des erreurs d'autorisation parce que vous devez utiliser Sudo pour créer un répertoire dans votre répertoire racine sous MacOS, Sudo vous permet d'exécuter des commandes en tant qu'administrateur.
Alors, lancez ça à la place ...
$ Sudo mkdir -p /data/db
Cela vous demandera un mot de passe, c'est le même mot de passe que vous utilisez pour modifier les paramètres du système (cette petite boîte de dialogue qui s'ouvre lorsque vous essayez de modifier des éléments dans Préférences Système pour ecample) et probablement le même que celui que vous utilisez pour vous connecter.
J'ai fait
brew install mongodb
sur 2018-02-01 et cela m’a donné mongodb version 3.6.2.
Invité par le réponse de orluke ci-dessus, j'ai juste essayé
$ brew services restart mongodb
et tout a germé dans la vie. Mon appel mongoose.createConnection() a fait ce que je voulais. Le GUI MongoDB Compass , la version de la communauté, se connecterait. J'ai utilisé Compass pour examiner la collection local.startup_log. Celui-ci contenait un document, le journal de moi commençant tout juste le service mongoDB, et qui avait
cmdLine:Object
config:"/usr/local/etc/mongod.conf"
et en effet il y avait un tel fichier:
$ more /usr/local/etc/mongod.conf
systemLog:
destination: file
path: /usr/local/var/log/mongodb/mongo.log
logAppend: true
storage:
dbPath: /usr/local/var/mongodb
net:
bindIp: 127.0.0.1
et il y avait un répertoire /usr/local/var/mongodb avec beaucoup de fichiers obscurs. Cela semble être ainsi que l'installation fonctionne maintenant.
Je ne sais pas si brew services restart configure le service pour qu'il s'exécute au moment de la connexion. Alors j'ai fait
brew services stop mongodb
brew services start mongodb
et espéré que cela redémarre après le redémarrage. Et, en effet, il l'a fait. En fait, maintenant, je pense que la bonne chose à faire après l'installation initiale est
brew services start mongodb
et cela devrait démarrer le service et le redémarrer après le redémarrage.
J'ai eu ce problème avec une configuration existante Mongodb. Je ne sais toujours pas pourquoi cela s'est passé, mais pour une raison quelconque, le processus Mongod n'a pas pu trouver le fichier mongod.config . Parce qu'il n'a pas pu trouver le fichier de configuration, il a essayé de trouver les fichiers de base de données dans/data/db , un dossier qui n’existait pas. Cependant, le fichier de configuration étant toujours disponible, je me suis assuré que le processus disposait d'autorisations sur le fichier de configuration et exécutais le processus mongod avec l'indicateur --config comme suit:
mongod --config /etc/mongod.conf
Dans le fichier de configuration lui-même, j'avais ce paramètre:
storage:
dbPath: /var/lib/mongodb
Et voici comment le processus pourrait retrouver le vrai dossier DB.
Vous essayez de créer un répertoire auquel vous n'avez pas accès root.
Pour tester mongodb, je viens d'utiliser un répertoire de mon répertoire utilisateur comme:
cd
mkdir -p temp/
mongod --dbpath .
Cela créera une base de données Mongo dans temp/depuis votre répertoire de travail actuel
Juste un petit mot:
Si vous avez essayé d’exécuter mongod sans modifier d’abord les autorisations, vous aurez probablement un fichier mongod.lock (et quelques autres fichiers) dans le répertoire/data/db. Même après avoir modifié les autorisations du répertoire/data/db pour donner accès à votre $ USER, vous continuerez à obtenir le message "Impossible de créer/ouvrir le fichier verrou: /data/db/mongod.lock errno: 13 Permission refusée " Erreur. Exécutez ls -al/data/db et vous verrez probablement que les autorisations pour les fichiers individuels sont toujours définies sur root pour l'utilisateur, et non sur votre $ USER. Vous devez supprimer le fichier mongod.lock, ainsi que les autres. Ensuite, lorsque vous exécutez à nouveau Mongod, tout devrait fonctionner et vous pouvez vérifier que les autorisations de fichiers correspondent aux autorisations de répertoire en exécutant à nouveau ls -al.
Jusqu'à cette date, je pensais aussi que nous devions créer ce dossier/data/db pour lancer la commande mongod.
Mais récemment, j'ai essayé de démarrer mongod avec la commande de service. Cela a fonctionné pour moi et il n'y avait pas besoin de créer le répertoire/data/db.
service mongod start
Pour vérifier l’état de Mongod, vous pouvez exécuter la commande suivante.
service mongod status
Tapez "id" sur le terminal pour voir les identifiants utilisateur disponibles que vous pouvez donner, Puis tapez simplement
"Sudo chown -R idname / data/db"
Cela a fonctionné pour moi! J'espère que cela résoudra votre problème.
J'ai continué à avoir l'erreur suivante lorsque j'ai essayé de démarrer mongodb.
"shutting down with code:100"
J'utilisais la commande suivante:
./mongod --dbpath=~/mongo-data
La solution pour moi était que je n'avais pas besoin du signe "=" et que cela causait l'erreur. Alors j'ai fait
./mongod --dbpath ~/mongo-data
Je voulais juste jeter cela là-bas parce que l'erreur ne précise en aucun cas que c'est le problème. J'ai presque supprimé le contenu du répertoire ~/mongo-data pour voir si cela aidait. Je suis heureux de me rappeler que parfois, les arguments de Cli n'utilisent pas le signe "=".
Cette solution résout mon problème
Faire un répertoire comme
Sudo mkdir -p/data/db
Cela fera un répertoire nommé comme base de données et que d'essayer de démarrer avec des commandes
Sudo Mongod
Si vous obtenez une autre erreur ou un problème avec le démarrage de Mongod, vous pouvez trouver le problème en tant que
Échec de la configuration du programme d’écoute: SocketException: adresse déjà utilisée Si vous trouvez qu’une autre erreur que vous devez tuer le processus en cours d’exécution en tapant sur terminal en tant que
ps ax | grep mongod
Sudo kill ps_number
et trouvez le port courant de Mongodod et tuez le processus . Un autre moyen est de créer un port spécifique lors du démarrage de Mongod en tant que
Sudo mongod --port 27018
Dans les versions plus actuelles de MongoDB, j’ai la version 3.2.10, elle est stockée par défaut dans
/var/lib/mongodb