Probeer docker-logboeken te controleren om te zien wat er aan de hand was toen de container stopte en ga naar de modus "Bestaand".
Kijk ook of het specificeren van het volledige pad voor het volume zou helpen:
docker run -p 27017:27017 -v /home/<user>/data:/data/db ...
De OP voegt toe:
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
Een errno:13 is waar nummer 30 over gaat.
Deze opmerking voegt toe:
Het is een probleem met eigendom/toestemming van bestanden (niet gerelateerd aan deze docker-image), ofwel met boot2docker met VB of een zwervende box met VB.
Desalniettemin slaagde ik erin om het eigendom te hacken, het opnieuw koppelen van het /Users gedeelde volume in boot2docker naar uid 999 en gid 999 (wat de mongo docker-afbeelding gebruikt) en kreeg het om te beginnen:
$ boot2docker ssh
$ sudo umount /Users
$ sudo mount -t vboxsf -o uid=999,gid=999 Users /Users
Maar... mongod crasht omdat het bestandssysteemtype niet wordt ondersteund (mmap werkt niet op vboxsf)
De daadwerkelijke oplossing zou dus zijn om een DVC:Data Volume Container . te proberen , omdat op dit moment de mongodb-doc vermeldt:
MongoDB vereist een bestandssysteem dat
fsync()ondersteunt op mappen.
Bijvoorbeeld, de gedeelde mappen van HGFS en Virtual Box ondersteunen deze bewerking niet.
Dus:
de koppeling naar OSX werkt niet voor MongoDB vanwege de manier waarop de gedeelde mappen van virtualbox werken.
Voor een DVC (Data Volume Container), probeer docker volume create :
docker volume create mongodbdata
Gebruik het dan als:
docker run -p 27017:27017 -v mongodbdata:/data/db ...
En kijk of dat beter werkt.
Zoals ik in de opmerkingen vermeld:
Een docker volume inspect mongodbdata (zie docker volume inspect ) zal je het pad geven (dat je dan kunt back-uppen als je dat nodig hebt)