cannot get bash prompt: Error response from daemon: Container foo is not running

Question

A basic jetty container:

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                                  NAMES
7c10b0ca16bd        jetty               "/docker-entrypoint.…"   21 seconds ago      Up 18 seconds       8080/tcp, 0.0.0.0:80->800/tcp, 0.0.0.0:443->8443/tcp   jetty01

can easily get a bash terminal as:

docker exec -ti jetty01 bash

created as so:

docker run -d \
    --name jetty01 \
    -d \
    -p 80:800 \
    -p 443:8443 \
    jetty

but, this approach fails with the basex from docker hub:

docker exec -ti basexhttp bash
Error response from daemon: Container 52b5337d7e6a22964310afb0be5f79ace38993173218fae8d9dcd858e4681142 is not running

created as:

docker run -d \
    --name basexhttp \
    --publish 1984:1984 \
    --publish 8984:8984 \
    --volume "$HOME/basex/data":/srv/basex/data \
    --volume "$HOME/basex/repo":/srv/basex/repo \
    --volume "$HOME/basex/webapp":/srv/basex/webapp \
    basex/basexhttp:latest

How do I get a root bash terminal?

How do I start the basex container? I tried:

docker start 52b5337d7e6a22964310afb0be5f79ace38993173218fae8d9dcd858e4681142

still nothing listed. But, docker ps -a shows:

CONTAINER ID        IMAGE                    COMMAND                  CREATED             STATUS                     PORTS               NAMES
52b5337d7e6a        basex/basexhttp:latest   "/usr/local/bin/mvn-…"   10 minutes ago      Exited (1) 2 minutes ago                       basexhttp

although it doesn't show in docker ps because it's not running.

Answer 1

Whoever created basex/basexhttp:latest does not seem to know Docker very well. They copied files necessary to a directory that was later configured as a volume, which means it can only be bound to an anonymous volume, otherwise files inside will be removed. They left source code inside the image, they used a single stage build with maven:3-jdk-8-alpine as base image, which means the final image has many unnecesary things installed. They left the entrypoint from the base image intact, which I guess is why they needed to create an empty /srv/.m2 directory and set it as Maven config dir for the image to start. It switches user from root to basex, which causes permission problems with bind mounts. Generally it's a mess.

I see two ways to successfully run this image:

First:

docker run -d \
    --name basexhttp \
    --publish 1984:1984 \
    --publish 8984:8984 \
    --entrypoint "" \
    basex/basexhttp:latest /usr/local/bin/basexhttp 

This uses only anonymous volumes and clears that unnecessary entrypoint.

You can stop it with docker stop basexhttp and then remove it with docker rm -v basexhttp. That -v is important - it removes the volumes - unless you memorize their very long IDs and which was mounted which you won't be able to reuse them anyway, so you may as well remove them from your system.

Second:

mkdir -p $HOME/basex/data
mkdir -p $HOME/basex/repo
mkdir -p $HOME/basex/webapp
chmod a+w basex
sudo chown -R 1984:1984 $HOME/basex
docker run -d \
    --name basexhttp \
    --publish 1984:1984 \
    --publish 8984:8984 \
    --volume "$HOME/basex/data":/srv/basex/data \
    --volume "$HOME/basex/repo":/srv/basex/repo \
    --volume "$HOME/basex/webapp":/srv/basex/webapp \
    --entrypoint "" \
    basex/basexhttp:latest bash -c "cp -r /usr/src/basex/basex-api/src/main/webapp/WEB-INF /srv/basex/webapp && exec /usr/local/bin/basexhttp"

This creates the necessary directories and sets their permissions so that both your user on the host and user.

You can stop it as in the previous example and remove with docker rm basexhttp. This time -v is not necessary, as there are no anonymous volumes.

You can verify that the contaienr is running correctly by executing:

docker exec -ti basexhttp basexclient

Username and password are both admin.