Attempting to run rootless dockerd but missing necessary entries in /etc/subuid

I am trying to run v2022.4 (Build 8407) as a linux container following the steps on Octopus Server Container with Docker Compose.

I want to run scripts inside a container on the Octopus server, so I enabled DIND in file .env:

# Octopus can be run either as the user root or as octopus.

When I run the server, it fails to start the docker daemon:

  sudo docker-compose up octopus-server
  octopus-db is up-to-date
  octopus-server is up-to-date
  Attaching to octopus-server
  octopus-server    | No configuration directory provided. Using default.
  octopus-server    | ======== Writing Configuration File =======
  octopus-server    | **error: attempting to run rootless dockerd but missing necessary entries in /etc/subuid and/or /etc/subgid for 999**

But the server status is reported as healthy.

When I set
then the docker daemon is started successfully.
However, I don’t want the server be running as root for security reasons.

How can I resolve this issue?

BTW: The host system is Ubuntu 20.04.5 LTS and it runs docker in rootful mode.

Good morning @tbraeumer,

Thank you for contacting Octopus Support and welcome to our forums!

I did some digging into this as I am not sure if you can run the Octopus server as rootless, but I believe you can with a tentacle, we have some documentation on running Tentacles rootless here if you wanted to take a look.

Is there any reason you have chosen to run scripts inside that Linux container rather than using an Octopus Worker? Using a worker would be our recommended course of action in this scenario.

I have engaged with our engineers if there is a way you can run Octopus Server rootless and see what they say, they are based in Australia so will not be online until late tonight UK time. There may be a technical reason why we could not run Octopus Server rootless but can run Tentacle, or there may be a way to run Octopus Server rootless, if there is I will let you know.

Reach out in the meantime if you have any more questions but it may be worth looking into workers in the meantime if you are able to use one of those as that would be a better option for you to run scripts on.

Kind Regards,

Dear Clare,

thank you for your quick response.

Is there any reason you have chosen to run scripts inside that Linux container rather than using an Octopus Worker?

I am currently evaluating OctopusDeploy on a test server, and I didn’t want to spend the time to set up another machine (worker node). I understand that in a real setup it is better to have the workers running on a dedicated machine or cluster, but at the moment I don’t see a need for it.

Nevertheless, the Octopus GUI offers the option to run steps on Octopus Server inside a container and it is mentioned there that “Octopus Server will need Docker installed” (see screenshot attached).
So, I was wondering if this can be accomplished in case Octopus Server itself is running in a container (which I also chose because it can be set up very quickly for testing purpose).

Kind regards,

Hi @tbraeumer!

Just jumping in for Clare on this one, as she’s wrapped up for the day.

Looking at the Dockerfile that we build the Octopus Server container from, it looks like this should be working, but something may have broken when we updated our baselayer recently. I’ll do some further investigation now and see if we can get to the bottom of this.

We’ll be in touch once we know more, but in the meantime, you could potentially look at using an external worker, if running the container as root is not an option.

Hi @Justin_Walsh ,

as a workaround, I have set up an Octopus Worker running in a container.
It connects to the Octopus Server which is also running in a container.

This way, I am able to run the server in non-root mode using the following settings:


However, the worker can only run as root and I set the environmental variable:


So, the “root problem” has just been moved from the server to the worker (in case the worker container is compromised, the host system could be attacked).

But for evaluation purpose, this solution is fine for me.

Anyway, it seems the option DISABLE_DIND=N is incompatible with the non-root mode - both for server and for worker.

Thanks @tbraeumer!

I’ve escalated this to our product engineering team who manages these docker images. The problem stemming from the fact we don’t add the octopus user to the subuid/subgid files - it’s currently on the backlog, and the team will get this fixed up at the earliest opportunity.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.