6

Is it possible to mount an overlay fs inside a (privileged) docker container? At least my intuitive approach, which works fine outside of a container, fails:

> mkdir /tmp/{up,low,work,merged} > mount -t overlay overlay -o lowerdir=/tmp/low/,upperdir=/tmp/up/,workdir=/tmp/work/ /tmp/merged/ mount: /tmp/merged: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.

Additional information:

  • Docker version 18.09.1, build 4c52b90
  • Kernel 4.19.0-8-amd64
  • Debian 10 (host and docker-image)
Improve this question

3 Answers 3

Reset to default
5

Found something that worked! Mounting the workdir and upperdir as tmpfs does the trick for me. Like so:

> mkdir /tmp/overlay > mkdir /tmp/{low,merged} > mount -t tmpfs tmpfs /tmp/overlay > mkdir /tmp/overlay/{up,work} > mount -t overlay overlay -o lowerdir=/tmp/low/,upperdir=/tmp/overlay/up/,workdir=/tmp/overlay/work/ /tmp/merged/

I'd still be interested in an explanation why creating an overlay w/o tmpfs fails within a docker container?

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

AFAIK it's because overlayfs only supports a single read/write layer (all other layers must be read-only). As the Docker container itself relies on (a read/write layer of) overlayfs, you can't nest another read/write layer.
5

How to mount an overlayfs inside a docker container:

https://gist.github.com/detunized/7c8fc4c37b49c5475e68ef9574587eee

Basically, you need to run the container with either --privileged or the more secure --cap-add=SYS_ADMIN.

Improve this answer

Comments

1

This is a bit of a guess but I suspect it is because docker is already using overlayfs and overlayfs is refusing to use upperdir as another overlayfs.

I suspect this may be due to whiteout files:

In order to support rm and rmdir without changing the lower filesystem, an overlay filesystem needs to record in the upper filesystem that files have been removed. This is done using whiteouts and opaque directories (non-directories are always opaque).

A whiteout is created as a character device with 0/0 device number. When a whiteout is found in the upper level of a merged directory, any matching name in the lower level is ignored, and the whiteout itself is also hidden.

To delete a file that exists in a lowerdir, overlayfs will create a whiteout file and hides all whiteout files (device number 0,0). This logically means that you cannot create a character device file with number 0,0 inside an overlayfs because that must be hidden by overlayfs itself.

If you were allowed to use an overlayfs as an upperdir it wouldn't be able to create blackout files and therefore wouldn't be able to rm or rmdir any files from the lower layers. Because it can't create a character device file with number 0,0 on another overlayfs.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.