Prøv at tjekke docker-logfilerne for at se, hvad der foregik, da containeren stoppede, og gå i "Eksisteret"-tilstand.
Se også, om det ville hjælpe at angive den fulde sti til volumen:
docker run -p 27017:27017 -v /home/<user>/data:/data/db ...
OP tilføjer:
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
En errno:13 er, hvad nummer 30 handler om.
Denne kommentar tilføjer:
Det er et filejerskab/tilladelsesproblem (ikke relateret til dette docker-billede), enten ved brug af boot2docker med VB eller en omstrejfende boks med VB.
Ikke desto mindre lykkedes det mig at hacke ejerskabet, genmonterede /Users delte volumen inde i boot2docker til uid 999 og gid 999 (som er hvad mongo docker image bruger) og fik det til at starte:
$ boot2docker ssh
$ sudo umount /Users
$ sudo mount -t vboxsf -o uid=999,gid=999 Users /Users
Men... mongod går ned på grund af filsystemtype, der ikke understøttes (mmap virker ikke på vboxsf)
Så den faktiske løsning ville være at prøve en DVC:Data Volume Container , fordi lige nu nævner mongodb doc:
MongoDB kræver et filsystem, der understøtter fsync() på mapper.
For eksempel understøtter HGFS og Virtual Boxs delte mapper ikke denne handling.
Så:
monteringen til OSX vil ikke fungere for MongoDB på grund af den måde, virtualbox delte mapper fungerer på.
For en DVC (Data Volume Container), prøv docker volume create :
docker volume create mongodbdata
Brug det derefter som:
docker run -p 27017:27017 -v mongodbdata:/data/db ...
Og se, om det virker bedre.
Som jeg nævner i kommentarerne:
En docker volume inspect mongodbdata (se docker volume inspect ) vil give dig sin sti (som du derefter kan sikkerhedskopiere, hvis du har brug for det)