20

What are the .dockerenv and .dockerinit files in the root of my container's filesystem? How are they used? Is there any documentation on these files?

root@18ceee4f9041:/# ls -al /
total 72
drwxr-xr-x.  21 root root 4096 Jan  4 20:45 .
drwxr-xr-x.  21 root root 4096 Jan  4 20:45 ..
-rwxr-xr-x.   1 root root    0 Jan  4 20:45 .dockerenv
-rwxr-xr-x.   1 root root    0 Jan  4 20:45 .dockerinit

Other people have asked similar questions, but I can find no answers:

I'm asking because I'm working on a bug in my docker-executing tool called scuba. You can pass --user to docker run to set the UID of the process in a container, but it has no entry in /etc/passwd, so I was investigating options for creating the user during container startup.

(Cross-posted at Stack Overflow, where it may be closed.)

Improve this question

2 Answers 2

Reset to default
15

AFAIK there is no official documentation about them.

Those files where only used by the old and deprecated LXC execution driver. They were hacks required by docker when using LXC to run the containers.

The .dockerinit was a sort of init process. It was the binary run by the lxc-attach command called when starting a container. It was the responsible to setup the environment, the user and the working directory and then run your entrypoint/cmd.

The .dockerenv contained the environment variables defined inside the container. They were used to setup the environment variables properly after the lxc-attach. This file was read by the .dockerinit process.

The new libcontainer/runc driver (the driver enabled by default) does not use these files. You will find them empty in your containers. In fact, the LXC support has been recently removed from the docker development branch.

So maybe these files will eventually disappear in the future, although currently are widely used by applications to detect the presence of docker.

Improve this answer
8
  • 3
    A small inaccuracy: According to the source code, they’re mount points, specified in Docker’s core, not specific to the LXC driver.
    – Daniel B
    Jan 5, 2016 at 9:28
  • 1
    Yes, you are right. Those files are part of a list of mount points created as empty files in the Docker core when creating the root FS. But those two specific files/mountpoints are only used by LXC.
    – zuazo
    Jan 5, 2016 at 9:49
  • Thank you for this. Could you please see my edit regarding "scuba"? Also, could you elaborate on "It was the responsible to setup... the user" ? This is relevant to my issue.
    – Jonathon Reinhart
    Jan 5, 2016 at 10:14
  • 1
    Thanks a lot @zuazo. I ended up working around the issue by creating a user in the container which matches the uid of the invoking user on the host. See JonathonReinhart/scuba#11.
    – Jonathon Reinhart
    Jan 5, 2016 at 18:22
  • 2
    It comes to 2020 and /.dockerenv still exists in every docker container.
    – ttimasdf
    Aug 17, 2020 at 12:33
8

In order to find out, whether their code is running inside a docker environment, it was popular to test for the existence of either the /.dockerinit or the /.dockerenv file.

Since the dockerinit file has been removed in newer versions, the best idea should now be to check the existence of the dockerenv file.

A sample implementation of such a check from our code:

if ! [ -f /.dockerenv ] ; then
  echo "Not running inside docker, exiting to avoid data damage." >&2
  exit 1
fi
Improve this answer
2
  • 1
    According to another answer here, testing for .dockerenv is not reliable either. Isn't there a more solid way to test for whether code is inside docker?
    – jayarjo
    Apr 30, 2020 at 8:31
  • If you rely on that, why not add your own layer to put it there, in case your base image lacks it?
    – Ville Laitila
    Jun 8, 2021 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.