Pruebe y verifique los registros de la ventana acoplable para ver qué estaba pasando cuando el contenedor se detuvo y pasó al modo "Existido".
Vea también si sería útil especificar la ruta completa para el volumen:
docker run -p 27017:27017 -v /home/<user>/data:/data/db ...
El OP agrega:
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
Un errno:13 es de lo que trata el número 30.
Este comentario agrega:
Es un problema de propiedad/permiso del archivo (no relacionado con esta imagen acoplable), ya sea usando boot2docker con VB o un cuadro vagabundo con VB.
Sin embargo, logré hackear la propiedad, volviendo a montar el volumen compartido /Users dentro de boot2docker a uid 999 y gid 999 (que es lo que usa la imagen de mongo docker) y conseguí que comenzara:
$ boot2docker ssh
$ sudo umount /Users
$ sudo mount -t vboxsf -o uid=999,gid=999 Users /Users
Pero... mongod falla debido a que el tipo de sistema de archivos no es compatible (mmap no funciona en vboxsf)
Entonces, la solución real sería probar un DVC:Contenedor de volumen de datos , porque en este momento el documento mongodb menciona:
MongoDB requiere un sistema de archivos que soporte fsync() en directorios.
Por ejemplo, las carpetas compartidas de HGFS y Virtual Box no admiten esta operación.
Entonces:
el montaje en OSX no funcionará para MongoDB debido a la forma en que funcionan las carpetas compartidas de virtualbox.
Para un DVC (contenedor de volumen de datos), intente docker volume create :
docker volume create mongodbdata
Entonces úsalo como:
docker run -p 27017:27017 -v mongodbdata:/data/db ...
Y mira si eso funciona mejor.
Como menciono en los comentarios:
Un docker volume inspect mongodbdata (ver docker volume inspect ) le dará su ruta (que luego puede hacer una copia de seguridad si lo necesita)
