Опитайте и проверете регистрационните файлове на docker, за да видите какво се е случвало, когато контейнерът е спрял, и преминете в режим „Съществуващ“.
Вижте също дали определянето на пълния път за тома би помогнало:
docker run -p 27017:27017 -v /home/<user>/data:/data/db ...
ОП добавя:
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
errno:13 е въпросът за 30.
Този коментар добавя:
Това е проблем със собствеността/разрешението на файла (не е свързан с това изображение на docker), или чрез използване на boot2docker с VB, или на скитническа кутия с VB.
Въпреки това успях да хакна собствеността, като премонтирах споделения обем /Users в boot2docker на uid 999 и gid 999 (които използва mongo docker image) и започна:
$ boot2docker ssh
$ sudo umount /Users
$ sudo mount -t vboxsf -o uid=999,gid=999 Users /Users
Но... mongod се срива поради неподдържан тип файлова система (mmap не работи на vboxsf)
Така че действителното решение би било да опитате DVC:Data Volume Container , защото точно сега документът на mongodb споменава:
MongoDB изисква файлова система, която поддържа
fsync()в директории.
Например, споделените папки на HGFS и Virtual Box не поддържат тази операция.
И така:
монтирането към OSX няма да работи за MongoDB поради начина, по който работят споделените папки на virtualbox.
За DVC (Data Volume Container), опитайте docker volume create :
docker volume create mongodbdata
След това го използвайте като:
docker run -p 27017:27017 -v mongodbdata:/data/db ...
И вижте дали това работи по-добре.
Както споменах в коментарите:
docker volume inspect mongodbdata (вижте docker volume inspect ) ще ви даде своя път (който след това можете да архивирате, ако имате нужда)
