Anonymous readonly volumes

[AndreKR]

Description

This feels like a bug but since there's a dedicated message saying that it isn't supported I guess it can be classified as a feature request.

When I try to create a volume that is both anonymous and readonly like this:

docker run --mount 'target=/ms,volume-driver=rclone,volume-opt=remote=ms:,readonly' ...

I get:

docker: Error response from daemon: invalid mount config for type "volume": must not set ReadOnly mode when using anonymous volumes.

I don't understand what one has to do with the other.

Using a readwrite volume is bad for the usual reasons and using a named volume is bad because as far as I know those are not automatically removed when the container is removed.

[cpuguy83]

How are you going to put data into the volume?

[AndreKR]

In my case it's an rclone mount volume and the remote already has data.

[sylmarch]

I have the same issue.

I want to mount into the container a NFS volume as read-only.
This volume contains data that are generated by other processes.
The container should only read data in this volume → it should not modify them. So R/W rights should not be set for security purpose and to avoid human/developer wrong behavior.

The NFS mount / NFS volume should be set only when this container is started and then, automatically unmount / destroyed when the container is destroyed.

Note that this behavior works if I remove the readonly options in the --mountoption of the docker run command.

Currently, my tricky workaround is to create the volume with docker volume create ... command before starting the container and destroying it when the container is stopped with docker volume rm .... I must declare a systemd service that is using directives ExecStartPre, ExecStart, and ExecStop.

It will be great to support readonly option for anonymous volumes unless there is a valid reason to forbid this behavior?

[neersighted]

I think the original intention behind forbidding this is it being a sort of nonsense condition with the local driver, and the intention being that anything that was meant to be pre-populated with content would be exposed as a named volume by the volume driver.

It sounds like some volume drivers have adopted unnamed volumes with other ways to locate their content, e.g. via the remote=ms: example (in a perfectly idiomatic world, one might expect the rclone driver to read the remote from the name, so you'd have a volume with a source=ms:).

In a world where volume-opt has been co-opted like this, this may make sense. I'm not sure what the future of volume drivers is, given the entire plugin interface is being looked at with some skepticism these days, but if we do keep it as-is, this restriction likely should be relaxed.

[AndreKR]

FWIW, I too have abandoned the volume driver approach in newer installations and instead I now configure the rclone mount via fstab:

ms: /mnt/ms rclone ro,nofail,_netdev,x-systemd.automount,args2env,vfs_cache_mode=full,vfs_cache_max_size=500M,vfs_cache_max_age=999y,config=/etc/rclone.conf,cache_dir=/var/cache/rclone,allow_other 0 0

and then mount this into the container: docker run ... -v /mnt/ms:/ms:ro ...

It works just as well, if not better. Issues with the mount can be analyzed independently of issue with the container and just like the volume driver plugin, it only requires one more piece of configuration, but in a well-expected place.

[srstsavage]

I'm also hitting this with a remote NFS volume which already contains data. If this restriction is artificial can we consider lifting it?