I need to run a couchbase docker container. The community edition is fully sufficient, and I can successfully start it using this image with the command

docker run -d --name db -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 couchbase

However when going towards the real environment, the docker container will be started with an anonymous user, causing couchbase to never start up. The analogous docker command looks like this:

docker run --user nobody:0 -d --name db -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 couchbase

This leads reliably to these log messages on the container's stdout:

Starting Couchbase Server -- Web UI available at http://<ip>:8091
and logs available in /opt/couchbase/var/lib/couchbase/logs
runsv couchbase-server: fatal: unable to open supervise/lock: access denied
runsv couchbase-server: fatal: unable to open supervise/lock: access denied
runsv couchbase-server: fatal: unable to open supervise/lock: access denied

I already tried chmodding and chowning all files in /opt/couchbase such that the group 0 has access - but the error message stays the same. Meanwhile I believe it is not couchbase itself but the runsv command that cannot access a file. Unfortunately I have no clue which absolute path it is trying to access or which privileges it needs.

How can I make the couchbase docker container compatible with this --user nobody:0 command line option?

I need to run a couchbase docker container. The community edition is fully sufficient, and I can successfully start it using this image with the command

docker run -d --name db -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 couchbase

However when going towards the real environment, the docker container will be started with an anonymous user, causing couchbase to never start up. The analogous docker command looks like this:

docker run --user nobody:0 -d --name db -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 couchbase

This leads reliably to these log messages on the container's stdout:

Starting Couchbase Server -- Web UI available at http://<ip>:8091
and logs available in /opt/couchbase/var/lib/couchbase/logs
runsv couchbase-server: fatal: unable to open supervise/lock: access denied
runsv couchbase-server: fatal: unable to open supervise/lock: access denied
runsv couchbase-server: fatal: unable to open supervise/lock: access denied

I already tried chmodding and chowning all files in /opt/couchbase such that the group 0 has access - but the error message stays the same. Meanwhile I believe it is not couchbase itself but the runsv command that cannot access a file. Unfortunately I have no clue which absolute path it is trying to access or which privileges it needs.

How can I make the couchbase docker container compatible with this --user nobody:0 command line option?

• docker
• couchbase

1 Answer 1

The scenario I am in is somewhat exotic, but reading my own question over and over again I finally found a solution. Yes, the error message is coming from runsv due to wrong file permissions, and they need all to be fixed. So I need to create my own container using this Dockerfile:

FROM couchbase

USER 0
ADD run /etc/service/couchbase-server/run

RUN chmod -vR g=u /opt/couchbase && chgrp -vR 0 /opt/couchbase
RUN chmod -vR g=u /etc/service && chgrp -vR 0 /etc/service

USER 1000

As the run script requires to be executed by either root or the user couchbase (which is not the case in my setup) I had to add an alternative version that looks like this:

#!/bin/sh

# If HOME is set, Erlang requires that it be a writable directory.
# We can't guarantee that as it depends on which UID the container
# is started as. The couchbase-server script will handle it being
# unset, though, so do that for safety.
unset HOME

exec 2>&1

echo "I am $0 running as user $(id)"

# Create directories where couchbase stores its data
cd /opt/couchbase
mkdir -p var/lib/couchbase \
         var/lib/couchbase/config \
         var/lib/couchbase/data \
         var/lib/couchbase/stats \
         var/lib/couchbase/logs \
         var/lib/moxi

# If container is running as root, ensure contents of /opt/couchbase/var are
# owned by the 'couchbase' user. If running as 'couchbase', don't attempt to
# claim ownership, but instead warn when encountering unwritable paths.
# Skip "inbox" as it may contain readonly-mounted things like k8s certs.
container_user=$(id -u)
if [ "${container_user}" = "0" ]; then
    find var -path var/lib/couchbase/inbox -prune -o -print0 | \
      xargs -0 chown --no-dereference couchbase:couchbase
else
    find var -path var/lib/couchbase/inbox -prune -o \! -writable -print0 | \
      xargs -0 -I {} echo "Warning: '/opt/couchbase/{}' is not writable by userid '${container_user}'"
fi
unset container_user

if [ "$(id -u)" != "0" ]; then
  exec /opt/couchbase/bin/couchbase-server -- -kernel global_enable_tracing false -noinput
else
  exec chpst -ucouchbase  /opt/couchbase/bin/couchbase-server -- -kernel global_enable_tracing false -noinput
fi

Use docker build ..., then you can run the image as you would any couchbase. But this image can also withstand being executed using docker run -u nobody:0 ...