What does 'rw' mean when bind mounting a directory

Question

When starting a container and specifying a volume you can optionally append a third field that's a comma separated list of options like rw.

docker run -v /some-host/path:/some-container/path:rw

This same options are applicable in the docker.compose.yml

services:
  myService:
    image: some/image
    volumes:
      - /some-host/path:/some-container/path:rw

I thought that specifing rw would mean that the container would be able to read from and write to that directory (regardless of user). Contrary to my belief, when the host directory doesn't exist, docker creates it as drwxr-xr-x 2 root root no matter what I specify. The application in the container is not running on root though, so it tries to write to the mounted drive and get's Permission denied.

I've dug through the docker documents, even found this github issue describing the same issue, but can't find anything definitive that explains expected behavior.

So what exactly does rw(read/write) mean when specified as a third option for bind mounted directories?

Answer 1

As DavidMaze says in the comments

in the same way that / on your host is mounted read-write but isn’t world-writable on every file; if it were mounted read-only nobody could write any file.

And the docs:

If neither 'rw' or 'ro' is specified then the volume is mounted in read-write mode.

And

If you supply an absolute path for the host-dir, Docker bind-mounts to the path you specify.

The directory is "mounted" as rw by default. So think that to write in a directory it is not enough a rw mount, you also need file permissions on it. In the other hand, having full files permissions is not enough if the directory is mounted as read only. Think it as two layers permissions.

Also:

There is clear value in the ability to make bind mounts read-only, though. Containers are one example: an administrator may wish to create a container in which processes may be running as root. It may be useful for that container to have access to filesystems on the host, but the container should not necessarily have write access to those filesystems.