How to make volume on a specific path

Docker Hub
1

Working on server i have no rules to read /var/lib directory and it needs to store volume on a specific path, for example in ~/.docker/volumes/volumename. With some magic I have done it yet one times, but forget how for and couldn’t repeat this action. This comand i use to run docker:

docker run --mount type=volume,dst=/usr/src/TrackR-CNN/models,volume-driver=local,volume-opt=type=none,volume-opt=o=bind,volume-opt=device=/home/maker/.docker/volumes/volumename/ --rm -it dockername

2

You probably don’t need any magic. Did you try

docker run -v /home/maker/.docker/volumes/volumename:/usr/src/TrackR-CNN/models ...

?

3

No, because i understand how to run docker with volumes, but I need to create volume

4

And create in the ~/.docker/volumes for example, but not in the /var/lib/docker.

5

So I don’t understand your question. You have 2 possibilities, either you mount an existing path on your host as a volume, or you create a named volume in Docker. What exactly is your issue with the /home/.../volumename folder?

6

Yes I need to create a named volume
If i will create volume, it could be placed in /var/lib/docker/volumes/volumename
But i have no rules to write to this directory and i need to story my volume in my home folder ~/.docker/volumes for example, but how i need to use docker volume create to make volume on specific path?

7

I have created one time volume where in the field “mountpoint”(from result of “docker volume inspect”) was my local way but i forget how i made this and couldn’t repeat

8

It’s really difficult to understand what you are doing. You speak about named volumes but show commands that create a bind mount. So let’s start with something simple. If you create a named volume with such a compose file, does it work or do you get an error?

---
version: "3"
services:
  web:
    image: httpd
    ports:
      - "8080:80"
    volumes:
      - mydata:/data

volumes:
  mydata:
9

Yes, this volume will be stored in /var/lib/docker/volumes on a host mashine physically. But how to chose place, whitch will be this volume, because I have no rules to work with /var/…
I can run docker and connect volume into docker, this is no problem, Problem is: I need to place(to store physycally) volume not in the /var, but in /home/…

image
image710×275 98 KB

10

The forum search for “docker volume create bind” made me find an old post of mine. Plenty of the search results cover the topic…

Here is the syntax on how to create a local named volume that binds a local folder:
docker volume create --opt type=none --opt o=bind --opt device=/data/volumes/testvol testvol

Just replace the path in device= and maybe use a more meaningful name than I did in the example.
The Mounpoint will always be in /var/lib/docker/volumes/{volume name}/_data; there is no way arround that.

2 Likes
11 
docker volume create <volume name> --opt type=none --opt device=<path to volume> --opt o=bind
12

like many others, I found this thread from Google search. I do not understand what the confusion here is. Its pretty simple, as described by the OP

Many docker-compose.yml for pre-existing third-party projects include the usage of “docker volumes”, as opposed to a normal bind mount.

example;

By default it seems that Docker volumes are stored under /var/lib/docker/volumes

Frankly, this seems like a mistake in the first place, for the reasons described by OP; many users on managed systems do not have write access under /var. Similarly, if you do manage your own server, your OS boot disk that hosts /var is likely not appropriate for high-throughput usage that a Docker Volume is supposedly “ideal” for. AFAICT, its extremely common for a server boot-disk to be a mid-grade mid-capacity SSD, meanwhile all the real “work” on the system is meant to happen on higher capacity NVMe disks meant explicitly for high throughput IO. So naturally, you would want to host you “docker volumes” on the high capacity NVMe disks.

This is exactly what OP is asking for, I think.

Thanks for this, but I am still a little confused by what is being described here.

if I am reading this correctly, this part;

--opt device=/data/volumes/testvol testvol

is creating a docker volume named “testvol” and storing the data for it on the host disk location /data/volumes/testvol

Is the docker volume created this way going to still be the “normal” style of docker volume? Or is it instead creating a bind mount to a directory on the host disk?

The Mounpoint will always be in /var/lib/docker/volumes/{volume name}/_data

I am confused by this statement, are you suggesting that the location of “testvol” inside the container will be at /var/lib/docker/volumes/testvol/_data ? Or are you referring to the host system?

Finally, how are you supposed to configure all of this from within your docker-compose.yml? It seems like the entire point of using docker compose in the first place, is to avoid having to run all these arbitrary one-off commands in the terminal and to have the entire docker config for your project in a scripted and reproducible configuration. In particular it seems like you would likely want your docker volume located in the same directory as your docker-compose.yml, or at least have some pre-defined common location on the host for your projects’ volumes

13

It is a named volume, baked by a bind. It behaves like a volume, in the sense that mechanisms like “copy of first use” apply to this volume as well, and can be listed by docker volume ls. But it also shares the drawbacks of a bind: you need to make sure the access permissions are correct.

In my example, the inode of the host folder /data/volumes/testvol will be bind mounted into the path /var/lib/docker/volumes/testvol/_data (because I called the volume testvol, not because the source folder shares the same name), so both paths point to the same inode. From this location, the very same inode will be bind mounted into the container filesystems target path. This convention allows using the same implementation that exists for nfs or cifs remote shares, without having to implement a different logic just for this case.

It was not part of the op. Still here we go:

volumes:
  testvol:
    driver_opts:
     type: none
     o: bind
     device: /data/volumes/testvol

Volumes used to be immutable. But later version of the docker compose cli plugin, recognize modifications in the volume configuration and ask whether it should re-create it using the new configuration. In this case the named volume, is merely a configuration, holding no data itself.

1 Like