[feature] Allow mounting sub-directories of named volumes

[zacharysells]

Similar to how bind mounts let you mount subfolders i.e -v /host/path:/container/path, is it possible for the same functionality to be available for named volumes? i.e -v namedvolume/path:/container/path. Right now in order to mount a named volume, you must mount the entire volume.

I apologize in advance if this has been discussed somewhere already, but I couldn't find anything saying this isn't doable.

[cirocosta]

This would be super useful for me as well 👍 Sorry for my shallow knowledge but, what would be the difficulties in this? Making sure there's no "chroot escape -a-like"?

[ravjanga]

Even I am looking for this similar feature, but couldnt find any useful links explaining how to achieve this. Kubernetes has this support via sub-path notation.

[spatialvlad]

Having ability to specify sub-directory from a named volume would be really helpful.
Some containers require mounting multiple volumes, while these multiple volumes logically fit well to a sub-directories in a single named volume.

E.g. https://hub.docker.com/r/tvial/docker-mailserver/ container requires 3 volumes by default:

my-mail-server:
     volumes:
     - maildata:/var/mail
     - mailstate:/var/mail-state
     - ./config/:/tmp/docker-mailserver/

Ideally, I would like to create one named volume, e.g. using RexRay volume driver named rex_mail and then mount sub-directories of this volume in the service. One of the options could be mounting at the service level, like this:

my-mail-server:
     volumes:
     - rex_mail/maildata:/var/mail
     - rex_mail/mailstate:/var/mail-state
     - rex_mail/config:/tmp/docker-mailserver/

Or maybe as an alternative way (e.g. if it will be easier from the point of view of backwards compatibility), to handle this at the top level for volumes, creating mappings between named volume sub-directories and new volumes to use at the service level. E.g. something like this:

volumes:
     rex_maildata:
          external:
              name: rex_mail
             src: /maildata
     rex_mailstate:
         external:
             name: rex_mail
             src: /mailstate
     rex_mailconfig:
         external:
             name: rex_mail
             src: /config

And then at the service level to use these sub-directories as:

my-mail-server:
     volumes:
     - rex_maildata:/var/mail
     - rex_mailstate:/var/mail-state
     - rex_mailconfig:/tmp/docker-mailserver/

There are multiple reasons why the ability to mount name volume only once and map various sub-directories in it to various directories in the container is important:

1. Typically volumes at hosting providers (E.g. AWS, Digital Ocean) have a minimum size of about 1Gb, which is an overkill for many directories that need to be mapped.
2. Storing all data needed for a container in one volume makes it easier to use it, backup, restore, etc.
3. Most hosting providers impose restrictions on the number of volumes you can mount on a host. E.g. at Digital Ocean you can mount up to 5 volumes to a droplet. Creating a separate named volume for each folder a container needs can very easily make it not possible to run several containers on the same host. This is especially important when running in Docker Swarm mode, since it's hard to tell which container will start on which host (and how many volumes should be mounted on the host).

[cpuguy83]

This could be added to the new mount syntax. Not too keen on supporting this with the old -v foo:/bar syntax... not sure it would even work with it.

[cpuguy83]

Basically add a new field here called Subpath that could be taken into account.

There are likely some implications in supporting this that will limit future possibilities that which need to be explored...

[ghost]

A 👍 from me also - posted a duplicate ticket here: docker/compose#5367 (comment).

The ability to create a volume and build complex subfolder / file mappings (maybe supporting conditions) would be amazing.

[y2kpr]

@cpuguy83 taking your suggestion, I made a sample implementation of this feature. I checked that it works with a local copy of the cli. It works similar to how @spatialvlad described it.

Take a look at the code changes here and let me know if this design is acceptable.

If anyone would like to try it out with the cli, you can do so with this cli and running this sample command:
docker run -it --name test --mount source="testvol",target=/app,volume-subpath=/test alpine

[ryanmickler]

@y2kpr I like the design. nice work.

[cpuguy83]

@y2kpr Thanks! Looks good, but needs tests.
Also need to check for symlink traversal issues.

[y2kpr]

Thanks for the feedback! I will try to submit a PR with checks for symlink traversal and tests by this weekend.

[thaJeztah]

Design looks good (from the description above); we should indeed have tests for various scenarios (single container using multiple paths from the same volume, multiple containers using the same, or different paths from a volume etc., possibly "corner cases" where paths overlap inside the container)

[Mathiasdm]

@y2kpr have you been able to continue on the PR?

[y2kpr]

@Mathiasdm I just have some testing left to do. I was on vacation for a while and I get back tomorrow. I am planning to finish it by this weekend

[y2kpr]

Over the weekend I tried to write some unit tests but had no success. Being very new to the code base and without many reference unit tests around the code I added, I am having trouble mocking things correctly (especially in the daemon).

I would like someone who is more familiar with the code base to take it from here or guide me on how to do the unit tests (@cpuguy83 know anyone?). Unfortunately, I do not have enough time to tinker with it and figure it out on my own.

Once the unit tests are done, the integration tests (if we want some) are straightforward. I just need to add some CLI commands after updating the docker CLI.

[cpuguy83]

@y2kpr I guess it would depend on what exactly you are going to unit test and what your implementation looks like.
We should definitely have an integration test, but there should be no need to update the CLI in moby/moby. We only currently accept integration API tests (see integration/ dir), not CLI.

[thaJeztah]

@y2kpr were you still working on this?

[y2kpr]

@thaJeztah Unfortunately, I will not be able to work on it at least until summer (mid may)

[davclark]

This feature would be incredibly useful for the kinds of transparent/reproducible computational science workflows that we're supporting at Gigantum. None of us are Go experts (and certainly not Docker codebase experts), but we would be interested in knowing how we could best support getting this feature landed.

I'd be happy to take a crack at writing some API integration tests, or it might be more productive to put a bounty on finishing this up. It seems like this is the closest thing to a starting point, and I only see surface testing there - not any inspection to see if the data contained in volumes is correct.

I welcome any feedback, in particular from @y2kpr as this is your patch! In the meantime, I'll see about cloning your clone, and applying the changes recommended by @cpuguy83.

[shr00mie]

popping in to add my support for this feature.

at the moment, it seems like the mickey mouse verbose solution is to define each of the subdirectories as unique volumes. would be AWESOME to just define the parent and use namedvolume/subdir for the various service volumes.

love you long time.

[victorvianna]

This feature would make this much easier.

[majgis]

@y2kpr and @davclark, I see statements above from both of you about getting back to this PR. Any ETA? I'm stirring the pot, because this feature would help with what my team is trying to accomplish. If there are no immediate plans to bring this feature to completion, I'm interested in throwing my time at the problem starting next week, if my assistance would be welcome.

[davclark]

Sorry to have just gone silent... Currently, I'm evaluating dotmesh as an alternative to using stock docker volumes. So this is less relevant to us. Given the lack of input and my lack of knowledge about Docker, I was reluctant to put too much time into this. Please keep this thread updated with any activity. I'm happy to review or help develop tests, just want to make sure it's a reasonable use of time!

[thelamer]

This would greatly reduce the complexity of many compose setups and more importantly allow people to use volumes with off the shelf containers instead of forking them off for customization.
In a perfect world people would be able to initiate all the changes they need with env vars, and the core applications they are using would support .d/ style directories that dynamically load anything in mounted to that directory.
Unfortunately Databases and webservers do not always have a stock config or automatically appended config files directories which leaves us stuck with docker host level folder mounts for mounting single files into complex changing config folders of the containers.

From a Docker design standpoint you want the application using a Docker volume isolated in Docker easy to spin up and easy to destroy without having to mess with the host's local filesystem.

[sethidden]

If you REALLY want to do this ONLY ONCE

version: "3.5"
services:
  calibre-web:
    image: linuxserver/calibre-web:arm64v8-latest
    container_name: calibre-web

    # SOLUTION START
    # "data/admin/files/CALIBRE" is specific to my usecase
    volumes:
     # https://github.com/ec-/Quake3e/blob/2c96f6d58619a29589bac577288497964c943a3e/code/qcommon/q_math.c#L569
      -  /var/lib/docker/volumes/docker_nextcloud/_data/data/admin/files/CALIBRE:/books:rw
    # SOLUTION END
    ports:
      - 8083:8083
    restart: unless-stopped

[bkraul]

[53c70r]

Podman can do this.

[bkraul]

Podman can do this.

Ain't that a shame tho?

[onursoyer]

@53c70r
Would you be so kind to share an example of how to do this in podman?

[owenthewizard]

How do we not have this feature in 2023? Where are the maintainers?

[thaJeztah]

@owenthewizard Because it's not easy to implement in a secure way (e.g. Kubernetes has had multiple advisories in this area), and part of this was why previous attempts to implement this stranded. Maintainers help maintain the project, but do so either in their own time, or time granted by their employers, which (in most cases) won't be full time on open source projects. There's always gonna be more feature requests and bug fixes than maintainers, so work must be prioritised, which means not every feature request can be worked on (if at all).

This project is open source, so if features are important to you, read the CONTRIBUTING.md on how to contribute.

The good news on this one, is that work is in progress again (but still things to discuss/review) #45687

[owenthewizard]

Of course I understand that open source projects are usually on a volunteer basis, but this is Docker, who in addition to recently raising their prices is sponsored by many corporate entities.
Thank you for linking the PR, without it it seemed like this feature request had no movement for years.

[bkraul]

This project is open source, so if features are important to you, read the CONTRIBUTING.md on how to contribute.

Sadly I am not the expert here, but one question with that. What is the use of contributing with PRs that seek to address the issues, if the maintainers, due to the reasons you explained above, will never get to merge them? Is forking and ultimate fragmentation of the project the only way?

[cpuguy83]

Maintainers have said repeatedly we'll accept a change but it needs to address security concerns as it's not as simple as grabbing the sub-path.

There is an open pr and it does look pretty good, but still need to give it a full review.

[Hadatko]

+1

[dazinator]

All I can say at this point is: Pretty Please? :-p

[anthonyl6]

Please? + 1

[dazinator]

@thaJeztah Super happy this is merged!
I am not looking for any precise value but as an excited user of

• Windows: docker desktop
• Ubuntu 20.04.6 LTS - Installed docker using apt install -y docker.io

Is there a rough estimate / timescale as to when the next release might appear with these changes? I know docker desktop will notify me but I am more wondering about planning update of some linux boxes! :-)

[tianon]

It was merged after the 25 release, so unfortunately it's going to have to wait for the 26.x release cycle. 👍

[ruffsl]

@tianon , is #45687 only extending the docker daemon API?
Should we be watching else ware to know when tools like the CLI or compose add support?

[vvoland]

CLI already supports it (starting from v26.0.0-rc1): docker/cli#4331

(and you can already install it from the test channel)

Compose support is still WIP (it needs to move to v26 first).

[vvoland]

v26.0.0 is released, so you can already try out this feature.

[dazinator]

Seeing this appear in windows docker desktop update today!