Spróbuj sprawdzić dzienniki dokera, aby zobaczyć, co się dzieje, gdy kontener się zatrzymał i przejść do trybu „Istnieje”.
Zobacz także, czy pomogłoby określenie pełnej ścieżki woluminu:
docker run -p 27017:27017 -v /home/<user>/data:/data/db ...
OP dodaje:
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
Problem 30 dotyczy errno:13.
Ten komentarz dodaje:
Jest to problem z własnością/uprawnieniami do pliku (niezwiązany z tym obrazem dockera), albo przy użyciu boot2docker z VB, albo włóczęgi z VB.
Niemniej jednak udało mi się zhakować własność, ponownie montując udostępniony wolumin /Users wewnątrz boot2docker do uid 999 i gid 999 (które są używane w obrazie docker mongo) i gotowe:
$ boot2docker ssh
$ sudo umount /Users
$ sudo mount -t vboxsf -o uid=999,gid=999 Users /Users
Ale... mongod ulega awarii z powodu nieobsługiwanego typu systemu plików (mmap nie działa na vboxsf)
Tak więc rzeczywistym rozwiązaniem byłoby wypróbowanie DVC:kontener woluminów danych , ponieważ w tej chwili dokument mongodb wspomina:
MongoDB wymaga systemu plików, który obsługuje fsync() na katalogach.
Na przykład udostępnione foldery HGFS i Virtual Box nie obsługują tej operacji.
A więc:
montowanie do OSX nie zadziała dla MongoDB z powodu sposobu, w jaki działają foldery współdzielone virtualbox.
W przypadku DVC (kontenera woluminów danych) spróbuj docker volume create :
docker volume create mongodbdata
Następnie użyj go jako:
docker run -p 27017:27017 -v mongodbdata:/data/db ...
I zobacz, czy to działa lepiej.
Jak wspominam w komentarzach:
docker volume inspect mongodbdata (zobacz docker volume inspect ) poda swoją ścieżkę (którą możesz następnie wykonać w razie potrzeby)
