Add or change options like Volume (Bind Mount) of existing container without restarting Docker service

[scscgit]

Description

Currently, to add a Volume or a Bind Mount to an existing container (or change it), you must either

• container stop, commit, container rm, and run with all volumes (including old ones); and then take care of all the cleanup, which isn't obvious either.

or

• Edit "MountPoints" (or "Mounts") in config.v2.json under /var/lib/docker (not editable via Docker Desktop!) and restart the Docker daemon service (likely stopping it before edit to avoid concurrent edits)

Obviously, neither option scales (especially with automation) if you want to use Docker for real life use-cases where you don't just randomly stop containers to make modifications, introduce export risks, or stop all of your containers for every change in one of them. Sometimes you just need to expose a new path to a container ad-hoc, other times you're moving directories around in your system. I'm asking for a CLI command that applies such a delta on one container (at most suspending that single container if there is no other way), of course eventually including a Docker Desktop UI support for it.

There are places with well-known documentation (workarounds) for this like:

• https://stackoverflow.com/questions/28302178/how-can-i-add-a-volume-to-an-existing-docker-container
• https://www.baeldung.com/linux/docker-container-add-volume

and it doesn't seem to be officially recognized as a usability problem yet. Hopefully Docker plans to become a serious and user-friendly tool we can rely on to hold all third party executables relied on by our system setup, and not just a tool for Linux server admins who set-and-forget services without ever having to manage them as their users (with ordinary needs of a home computer, e.g. moving sub-directories between host's partitions).

Typical use-cases I believe should also be supported include:

• Extracting entire container's sub-directory content, moving it to a new volume point; or the opposite, integrating one's files back to the container; like an atomic operation (supplying virtual reads from previous place until the process is finished; or at least freezing container).
• Conversion between Volume and Bind Mount without restarting container.
• In UI, having images (or containers) documenting "suggested" or currently used paths on container's filesystem, encapsulating common use-cases to signal which of the (often hard-coded) paths have been mapped yet (typically data, logs, config...), making it easy to toggle this without hoping you won't make mistakes if you aren't image author (e.g. what if you move files with different permissions, breaking the behavior). Removing a container typically makes you lose all information about which paths you want to bind, including history (so you literally have to keep notepads with start scripts if you want to be responsible).
• Binding nested paths back to the container (image): e.g. /data/outside except /data/outside/internal.

We may also need to change other options, for example available GPUs --gpus device=0...

One important use-case is also related to upgrading containers whenever the image's latest tag changes. There is absolutely no user friendly way to upgrade containers at the moment. One of the issues is the container having volumes bound, for which you need to somehow extract required CLI parameters to write a new run command with the new image (while making sure you stop the old container). If you forget to bind all mount paths exactly the same way, your new container will misbehave, and you have to delete it to re-create it again... If you reuse existing volumes, an incomplete configuration may even cause a permanent data loss (e.g. if half of your configuration directories are missing, and some breaking auto-upgrade occurs). An in-place upgrade of container's image that keeps the same container name would be what most of us find lacking. (Instead of making a new container with a different name and then annoyingly renaming them all, the old name should be reused and the old container could possibly be renamed to something like "_0.2.0-old" as a backup to allow a downgrade. Note that if the tag is latest, there is absolutely no way of retrieving the release version number... Other than maybe Docker Hub REST API call?)

My installation:

• Docker version: 26.1.4, API version: 1.45, Context: desktop-linux
• Docker Desktop 4.31.1, Windows 10, WSL2 (frequently restarting wslservice.exe after it hangs)