Tente verificar os logs do docker para ver o que estava acontecendo quando o contêiner parou e vá para o modo "Existed".
Veja também se especificar o caminho completo para o volume ajudaria:
docker run -p 27017:27017 -v /home/<user>/data:/data/db ...
O OP acrescenta:
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
Um errno:13 é sobre o assunto 30.
Este comentário acrescenta:
É um problema de propriedade/permissão de arquivo (não relacionado a esta imagem do docker), usando boot2docker com VB ou uma caixa vagrant com VB.
No entanto, consegui hackear a propriedade, remontando o volume compartilhado /Users dentro do boot2docker para uid 999 e gid 999 (que é o que a imagem do docker mongo usa) e consegui iniciar:
$ boot2docker ssh
$ sudo umount /Users
$ sudo mount -t vboxsf -o uid=999,gid=999 Users /Users
Mas... o mongod trava devido ao tipo de sistema de arquivos não ser suportado (mmap não funciona no vboxsf)
Portanto, a solução real seria tentar um DVC:Data Volume Container , porque agora o doc do mongodb menciona:
MongoDB requer um sistema de arquivos que suportefsync()em diretórios.
Por exemplo, as pastas compartilhadas do HGFS e do Virtual Box não suportam esta operação.
Então:
a montagem no OSX não funcionará para o MongoDB devido à maneira como as pastas compartilhadas do virtualbox funcionam.
Para um DVC (Data Volume Container), tente
docker volume create :docker volume create mongodbdata
Em seguida, use-o como:
docker run -p 27017:27017 -v mongodbdata:/data/db ...
E veja se isso funciona melhor.
Como cito nos comentários:
Um
docker volume inspect mongodbdata (veja docker volume inspect ) fornecerá seu caminho (que você pode fazer backup se precisar) 
