OneLinersCommand workbench
Verified diagnostic signature

Docker container name already in use: reconcile Compose ownership

The same-event Docker reply says the requested container name is already in use, but this shorter fragment may omit the existing object's ID and state. Recover the full original error before assigning an owner. A Compose project name normally contributes to generated object names; an explicit container_name is a fixed daemon-wide container name, not an automatically isolated namespace for each project. Multiple retained name-conflict URL patterns describe this same failure, not independent Docker Engine faults. Match this output from docker, then continue with sourced, read-only checks.

Confidence
high
Platforms
linux · macos · windows
Verified
2026-10-01
Recognized output

Signature matched locally

Docker container name already in use: reconcile Compose ownership

OneLiners matches this pattern in your browser. Your pasted output is not stored or indexed.

Likely causes

What usually produces this signal

  1. Two approved Compose projects specify the same explicit container_name. Selecting another project name does not automatically rewrite that fixed value. A manual container can also occupy it; project labels and deployment records must be compared rather than assuming everything visible was created by the current stack.
  2. The effective Compose inputs differ from the files the operator reviewed. Extra -f files, project selection and interpolation sources can change the resolved name or service ownership. Printing a complete resolved configuration may expose secrets; first establish the intended inputs and inspect only required metadata.
  3. The colliding name belongs to an earlier service instance or a different deployment coordinator. Missing or unexpected Compose labels are not proof of abandonment. Even matching project/service labels are metadata, not authenticated authorization to mutate the object or evidence that it holds no valuable data.
Safe next checks

Collect evidence before changing the system

01

Compare only the existing object's ID and Compose project/service labels

# Use the full reported ID instead of the name when the original reply includes it.
# Name fallback is a current snapshot, not immutable identity.
docker --context approved_context container inspect --format 'id={{.Id}} name={{.Name}} project={{index .Config.Labels "com.docker.compose.project"}} service={{index .Config.Labels "com.docker.compose.service"}}' app_fixture

Expected signal: Limited output ties the observed object to its exact current ID and name and reports available canonical Compose labels. Compare the values privately with the approved release's project/service record. A different project is a concrete stop signal, while absent labels leave ownership unresolved rather than authorizing cleanup.

Compose labels describe project and service association but are not an access-control boundary. Other tools can create similar metadata. Avoid a full docker inspect dump, which can expose environment values, mounts and operational details. A name-only lookup can observe a newer object than the one that caused the original failure, so correlate its returned ID before making any ownership claim.

02

Review the approved Compose inputs without printing interpolated secrets

docker compose version
# Local read-only rendering of explicit, approved input files; examples only.
docker compose -f approved-compose.yaml -p expected_project config --no-interpolate --no-env-resolution --services
# Privately review container_name expressions and all approved -f inputs.
# Do not print full resolved config, --environment, env files or secret values.

Expected signal: The local service-name list corresponds to the approved input set and supported Compose flags. The owner separately checks any fixed container_name and relevant override sources. This services-only output deliberately does not claim to reveal the final interpolated container name or prove which remote object the deployment owns.

Older Compose versions may not support these options; stop and use the documented read-only equivalent rather than dropping privacy protections. Explicit container_name also prevents scaling that service beyond one container. Default service networking names, project labels and a fixed container name serve different purposes; changing one can affect dependencies and must be reviewed with the intended deployment design.

Reproducible example

Check the input against the result

Input and result

Error response from daemon: container name "app_fixture" is already in use
# Truncated Docker-shaped illustration, not executed Compose output.
# Two separate owned JSON controls compare project metadata for the same synthetic name.
# Executed owned Node 22 HTTP/JSON controls, NOT Docker Engine, Docker CLI or Compose:
owned_labels_control: observed_project=other_project intended_project_match=false
separate_control: observed_project=expected_project intended_project_match=true
compose_executed=false labels_prove_authorization=false lifecycle_writes=0

Two actual owned GET replies supplied constructed inspection-shaped labels. The comparison rejected another project and accepted the expected string in a separate control. This does not reproduce Compose name generation, configuration interpolation or authenticated ownership. The controls never relabel a real object; no Compose parser, Docker daemon or workload operation ran.

Evidence-led recovery

Correct only the demonstrated cause

Have both relevant owners reconcile the intended project, service and naming policy. Prefer a reviewed deployment design with unambiguous generated or intentionally distinct names, preserving service discovery, health checks and dependent routing. Do not remove another project's object, run down --remove-orphans or edit live labels to make a collision appear resolved.

Verify: The approved input set and selected daemon yield one intended project/service-to-ID association during the normal release. Verify existing dependents and retained data with their owners. A matching label alone, a services-only configuration listing or a successful local render is not proof that the intended remote workload was repaired.

Stop if: The object maps to another project, multiple file/interpolation sources remain unexplained, a label is being treated as authorization, or the proposed name change could break service discovery, scaling expectations or data retention.

Related signals

Other output patterns from this error family

Docker named-container conflict: inspect the reported ownerThe identified Docker daemon refused a new container because an existing object owns the requested name. A created or stopped container can still own a name; a running-only list cannot establish that the name is free. This is a container-object identity conflict, not an image-name collision, an occupied host port or proof that the existing workload is unhealthy. Preserve the reported container ID and actual daemon destination. The message's remove-or-rename suffix is guidance, not authorization to destroy or change the reported object.Docker remove-or-rename hint: preserve identity before reconciliationThe identified Docker reply contains the remove-or-rename hint associated with a container-name conflict. The suffix does not identify the owner by itself and is not a command or approval to delete anything. Retrieve the complete original reason, name, container ID and daemon context before choosing a repair. It describes the same native name conflict as the other retained fragments; a generic job note containing these words is insufficient Docker evidence. Later observations are separate snapshots, not an atomic reservation of the name.