Essayez de vérifier les journaux Docker pour voir ce qui se passait lorsque le conteneur s'est arrêté et passez en mode "Existed".
Voir aussi si la spécification du chemin complet du volume peut aider :
docker run -p 27017:27017 -v /home/<user>/data:/data/db ...
L'OP ajoute :
docker logs mongo
exception in initAndListen: 98
Unable to create/open lock file: /data/db/mongod.lock
errno:13 Permission denied
Is a mongod instance already running?
terminating 2016-02-15T06:19:17.638+0000
I CONTROL [initandlisten] dbexit: rc: 100
An errno:13 est le sujet du numéro 30.
Ce commentaire ajoute :
Il s'agit d'un problème de propriété/autorisation de fichier (non lié à cette image docker), soit en utilisant boot2docker avec VB ou une boîte vagrant avec VB.
Néanmoins, j'ai réussi à pirater la propriété, remontant le volume partagé /Users à l'intérieur de boot2docker sur uid 999 et gid 999 (qui sont ce que mongo docker image utilise) et je l'ai fait démarrer :
$ boot2docker ssh
$ sudo umount /Users
$ sudo mount -t vboxsf -o uid=999,gid=999 Users /Users
Mais... mongod se bloque car le type de système de fichiers n'est pas pris en charge (mmap ne fonctionne pas sur vboxsf)
La solution réelle serait donc d'essayer un DVC :Data Volume Container , car pour le moment, la documentation mongodb mentionne :
MongoDB nécessite un système de fichiers prenant en charge
fsync()
sur les répertoires.
Par exemple, les dossiers partagés de HGFS et Virtual Box ne prennent pas en charge cette opération.
Donc :
le montage sur OSX ne fonctionnera pas pour MongoDB en raison du fonctionnement des dossiers partagés de virtualbox.
Pour un DVC (Data Volume Container), essayez docker volume create
:
docker volume create mongodbdata
Utilisez-le ensuite comme :
docker run -p 27017:27017 -v mongodbdata:/data/db ...
Et voyez si cela fonctionne mieux.
Comme je le mentionne dans les commentaires :
Un docker volume inspect mongodbdata
(voir docker volume inspect
) vous donnera son chemin (que vous pourrez ensuite sauvegarder si besoin)