All of the tests indicates it doesn’t. When you try to mount a folder into a Docker container, Docker tries to create it if it is not there. When your user doesn’t have permission to create the source path, you normally get “permission denied”. Since Docker usually runs as root even if your user is not root, Docker would still create the folder unless you ar using rootless Docker. In that case Docker is not running as root, so you could get “permission denied”.
Somemetimes the root filesystem is read-only, so you don’t get “permission denied” but “filesystem is read-only”. This is how you can reproduce it (and how I did):
truncate --size 2G disk.img
mount -o ro ./disk.img ./mount-test
docker run --rm -it -v $PWD/mount-test/subfolder:/host ubuntu ls -l /host
Since I created a virtual disk and mounted as read-only, I got the same error as you.
/mnt1 is not an existing folder in Linux by default. If you created it, it must be somwhere else, not where Docker can see it.
This is why I asked for your Docker version, because depending on the installation method, you can have different docker daemons. A snap package cannot see everything on the host (at least not by default). Originally you installed
docker.io, and docker-ce after that, but something is still not right here.
An other issue could be remote connection. When your Docker client is on your machine, but the daemon is on a remote server. Or in a virtual machine. This is how Docker Desktop works.
I am talking about the Docker host, yes. Although the docker host can be a emote server or a VM as I mentioned it in the previous paragraph.
We just did This is why I asked you to run the docker commands, but I will add an other test command in the next test, because I didn’t think of remote servers previously.
Please, run the folowing commands and share the outputs:
snap list | grep docker
docker context ls
ls -la /
Make sure you run each command in the same terminal on the same host.