Add a volume by recreating a Docker container

Docker does not offer a normal container-update operation that adds a new volume mount to an existing container. Recreate the container with the additional mount. Before doing so, identify any data currently stored at that path and plan how it will move.

Record configuration and protect data

docker inspect myapp

Prefer the original Compose file or deployment definition over reconstructing a command from memory. Include the image identity, command, environment, networks, ports, user, restart policy, health check, and all existing mounts. Inspection output may contain secrets; keep it out of public logs.

Quiesce writes and back up the relevant data. Files in an existing volume are different from files in the old container's writable layer. An empty new volume may be populated from the new container's image directory by default; that does not copy arbitrary changes from the old container.

Recreate with the new mount

This illustrative sequence retains the old container while starting a replacement. Use your actual reviewed configuration:

docker stop myapp
docker rename myapp myapp-old
docker volume create my-new-volume
docker run -d --name myapp \
  -p 8080:80 \
  -e APP_ENV=production \
  --mount type=volume,source=existing-volume,target=/data \
  --mount type=volume,source=my-new-volume,target=/var/log/app \
  myapp:1.2

Confirm existing-volume is really the intended existing volume; a misspelled name can create empty storage. If data must be migrated into the new mount, complete and verify that migration before starting application writes. A database should use its supported backup/restore procedure.

Check health, file ownership, mount contents, and application behavior. Only then remove the retained container with docker rm myapp-old. Retaining it does not provide an independent backup of volumes shared with the replacement.

Preserve exceptional writable-layer changes

docker commit myapp-old myapp:temporary-snapshot can capture applicable container-layer changes for a replacement image. It excludes mounted volume contents and does not reproduce all host-side runtime settings. Carry intended changes back into the Dockerfile or configuration source rather than relying indefinitely on an undocumented snapshot.

--volumes-from myapp-old can reuse eligible volume mounts when creating another container. It is not a complete clone of the old configuration or every mount type: inspect the resulting mounts and do not expect it to reproduce tmpfs, networking, environment, or ports. An explicit mount list is often easier to audit.

Compose and Kubernetes

In Compose, add the service mount and declare its named volume at the top level, then run docker compose up -d app. Compose recreates a changed service container and normally preserves its mounted volume data. Avoid down -v if those volumes must remain, and check that renaming the project or volume has not selected different storage.

In Kubernetes, changing a Deployment's Pod template with a new volumeMount and matching volume normally replaces Pods. Persistent data survives only when the replacement uses the intended PVC and storage lifecycle; adding a mount does not migrate old writable-layer contents automatically.

FAQ

Can I avoid recreation with a mount-namespace trick?

Such modifications are outside Docker's ordinary configuration lifecycle and are difficult to reproduce. Recreating from the deployment definition is the maintainable approach.

Will mounting hide files?

Yes. A mount can obscure existing contents at its destination. Verify what the application will see and what data must be copied before enabling it.

What should be mounted from the start?

Data that must outlive a particular container, such as uploads and database storage. Logs may instead belong on standard output with a managed logging pipeline; choose storage based on how the data is consumed and retained.

See volumes, container commit, and Compose services.