If a service looks newly installed after moving a Compose file to another directory, inspect the volume attached to its current container before concluding that data was deleted. An unchanged file can create a different named volume when its project name changes. Explicit volume names and bind mounts require a different investigation.
The project name connects the directory to the resources
Compose uses a project name to group services, networks, and volumes. Its precedence includes the command’s -p, COMPOSE_PROJECT_NAME, the top-level name, and the project directory name. The default directory is based on the first Compose file and can change with --project-directory. Moving a folder does not by itself establish that the effective project name changed; inspect the actual invocation first.
With a default named-volume declaration of data:, this experiment created followup-a_data and followup-b_data. Both containers mounted their volume at /data. An identical path inside containers is not evidence of identical storage.
A controlled comparison with two projects and a dummy file
On 2026-09-13, a Linux development host separate from production ran Docker Engine 28.3.3, Compose 2.39.4, and BusyBox 1.37.0. It used a dedicated daemon, containers without external networking, and new test volumes. This did not physically move a directory. Explicit -p values isolated the effect of changing the project name.
services:
app:
image: busybox:1.37.0
network_mode: none
command: ["sleep", "300"]
volumes: ["data:/data"]
volumes:
data: {}The following sequence belongs in a separate environment containing only dummy data. Do not target production projects or names already in use. These are standard Docker CLI equivalents; the recorded runner explicitly selected the private socket.
docker compose -p followup-a up -d
docker compose -p followup-b up -d
docker compose -p followup-a exec -T app sh -c 'printf synthetic-marker > /data/marker'
docker compose -p followup-a exec -T app cat /data/marker
docker compose -p followup-b exec -T app cat /data/marker
docker volume inspect followup-a_data
docker volume inspect followup-b_data
docker compose -p followup-a exec -T app cat /data/marker| Check | Observed result | Meaning |
|---|---|---|
| Read in A | Exit 0, synthetic-marker | The file exists in A’s volume |
| Read the same path in B | Exit 1, file absent | B’s volume does not contain that file |
| Actual Mounts | A: followup-a_data, B: followup-b_data | Different named storage is attached |
| Compose project label | followup-a / followup-b | Each volume belongs to a different project |
| Read again in A | Exit 0, synthetic-marker | B’s failure does not imply deletion of A’s data |
B’s failed read was an expected observation and was retained as a failure, not rewritten as success. A still read the same file while B could not. This establishes a different-volume attachment case; it does not diagnose real database corruption, application initialization, or permission errors.
Inspect existing attachments before creating anything
If an application has begun writing into an unfamiliar empty volume, avoid mixing the two datasets while investigating. Privately record the actual container ID, volume name, creation time, and previous invocation. These are read-only commands; substitute verified values for ACTUAL_CONTAINER_ID and ACTUAL_VOLUME_NAME.
docker inspect ACTUAL_CONTAINER_ID --format '{{json .Mounts}}'
docker volume inspect ACTUAL_VOLUME_NAME --format '{{json .Labels}}'
docker compose lsRead Mounts fields Type, Name, Source, and Destination together. Paths and labels can contain internal information; do not publish the full output. Finding the old volume is not permission to attach a production database to two containers at once. Establish a maintenance window, application compatibility, backups, and restore viability before deciding whether to restore the attachment or migrate data.
Not every volume depends on the directory name
An explicit volume name: is used without a project prefix. With external: true, Compose references storage prepared outside its lifecycle and reports an error if it does not exist. A bind mount attaches a host path, so investigate changes in the base of a relative path. These exceptions were checked against official documentation; they were not all exercised by the A/B experiment.
Fixing the project name does not complete a data recovery. Changing projects can also change network and container names, and data already written to the new volume is not merged automatically into the old one. Identify what remains and what was newly created before following the service’s normal recovery procedure.
After the experiment, the A/B containers were stopped and only the two newly created dummy volumes were removed by exact name. No production volume or global cleanup command was used. Volume deletion is not a diagnostic step for a real service. When data appears missing, first establish which storage the application is reading.
Evidence and limits
Docker project-name precedence and Compose volume name and external were checked on 2026-09-13. A/B values and exit codes are actual observations from the separate development environment. Real database recovery, implicit directory-name changes, bind mounts, and external-volume combinations were not tested.