Bind for 0.0.0.0:8080 failed port already allocated

Not specified by the original author.

TL;DR: Something already owns that host port. Find it with docker ps (another container) or ss -tlnp | grep 8080 (a host process), then stop the other container or pick a different host port like -p 8081:8080. Only one listener per host port is allowed, and Docker will not share.

The error

Bind for the all-interfaces address:8080 failed: port is already allocated

Fix it

1. Check for another container on that port: docker ps --format '{{.Names}} {{.Ports}}' | grep 8080 Expected: either a container name (stop or remove it) or nothing.

2. Check host processes: ss -tlnp | grep ':8080' Expected: the process name and PID holding the port.

3. Either free the port (docker stop [name], or stop the host service) or remap: docker run -p 8081:8080 [image] Expected: container starts, reachable on host port 8081.

When this applies

• docker run -p / --publish failing with this exact message
• Restarting a container while the old one still holds the port

When this does NOT apply

• "Ports are not available" (different message, same family; usually the same fix)
• Container-to-container communication (use the container port and docker networks, no host binding needed)

Versions

All Docker versions, all platforms.

Why it happens

-p 8080:8080 asks the daemon to listen on the host's port 8080 for all interfaces. If anything already listens there, the bind syscall fails and the daemon reports it before the container starts.

Edge cases

• A stopped-but-not-removed container does NOT hold the port; only running ones do. docker ps -a showing it is a red herring.
• On Docker Desktop for Mac, host services on the Mac can hold the port; the container port mapping still goes through the VM.
• TIME_WAIT sockets from a just-stopped process can briefly block rebinding; waiting a minute or setting reuse options fixes it.

Asked: how to fix Bind for the all-interfaces address:8080 failed: port is already allocated. Verified answer: Fixes 'port is already allocated' when docker run -p fails because the host port is taken. Use when binding a host port and something (another container or host process) already holds it. The fix steps above were cross-checked against the accepted community answer at https://stackoverflow.com/questions/46176584/docker-bind-for-0-0-0-04000-failed-port-is-already-allocated (so:46176584), which confirms the same resolution.

Not specified by the original author.

TL;DR: Another process is listening on the host port you asked for. Run ss -tlnp | grep [port] to find it, kill or stop it, then start the container again. The userland proxy is the daemon component that forwards host ports into containers, and it fails at bind time when the port is taken.

The error

driver failed programming external connectivity on endpoint web: Error starting userland proxy: listen tcp4 the all-interfaces address:80: bind: address already in use

Fix it

1. Find the port from the error message (80 in the example).

2. Find the holder: sudo ss -tlnp | grep ':80 ' Expected: a process name and PID. Common culprits: apache2, nginx, another docker-proxy, Skype on Windows.

3. Stop it or choose a free port: docker run -p 8080:80 [image] Expected: container starts.

4. If the holder is a stale docker-proxy from a crashed container, restart the docker service to clear it.

When this applies

• Published ports failing with the userland proxy message
• Port 80/443 conflicts with a host web server

When this does NOT apply

• "Bind for the all-interfaces address:X failed: port is already allocated" (earlier check, same fix though)
• No ports published (then this error cannot occur; look elsewhere)

Versions

All Docker versions on Linux. Docker Desktop routes through the VM but surfaces the same message.

Why it happens

With the default iptables setup, docker-proxy (the userland proxy) binds the host port to forward traffic into the container's network namespace. The bind is exclusive; a host nginx on port 80 wins the race and the container fails to start.

Edge cases

• Disabling the userland proxy ("userland-proxy": false in daemon.json) changes the plumbing to pure iptables and avoids docker-proxy conflicts, but hairpin NAT behavior changes.
• On systems with both IPv4 and IPv6, the proxy binds both; a holder on only one family still blocks the dual bind.
• docker run -p the loopback address:80:80 binds loopback only and can succeed while the all-interfaces bind fails; useful when the conflict is on the external interface.

Asked: how to fix Error starting userland proxy: listen tcp4 the all-interfaces address:80: bind: address already in use. Verified answer: Fixes the userland proxy 'address already in use' error when starting a container with published ports. Use when the daemon cannot bind the host port because another process holds it. The fix steps above were cross-checked against the accepted community answer at https://github.com/docker/compose/issues/3277 (gh:docker/compose#3277), which confirms the same resolution.

Not specified by the original author.

TL;DR

Another process is already bound to the port the collector wants - often a second collector instance, a leftover one from a bad shutdown, or another service on the same port. Find which process holds the port, then either stop the duplicate or change one side's port. If you genuinely need both running, give one of them a different port in its config.

OTel collector "Failed to start: address already in use": port conflict fix

Steps

1. Read the collector startup log and note the exact address and port it failed to bind.

Expected: You know the conflicting port, e.g. 4317 or 4318.

2. Find the process holding that port with a socket listing command (for example ss with the listen and process flags, or lsof for the port).

Expected: You have a PID and process name for the holder.

3. Decide which one should own the port. If it is a duplicate or stale collector, stop it. If it is a different service you need, change the port in one side's config.

Expected: The port is free, or you have a planned new port for one side.

4. Start the collector again and confirm the receiver logs show it listening.

Expected: The collector starts cleanly and the receiver accepts connections.

Use this when

• The collector log says failed to start with address already in use on a receiver port.
• Two collector instances or a collector plus another OTLP receiver on one host.
• A collector that fails to start right after a previous one was killed.

Not for this skill when

• Collector config YAML syntax or schema errors (different fix).
• Exporter failures like auth errors or unreachable backends.
• Pipelines that start fine but drop or misroute telemetry.

Variant phrasings

otelcol bind: address already in use

opentelemetry collector port 4317 already in use

collector fails to start receiver port in use

Why it happens

Each receiver opens a TCP or UDP listener, and an operating system only allows one process per port. A second collector, a zombie process from an unclean shutdown, or an unrelated service on the same port all produce the same bind failure.

Edge cases

• A socket in TIME_WAIT is not a real conflict - if nothing owns the port, just retry.
• Docker port mappings can collide with host processes and with each other; check both.
• Two pipelines in one config accidentally using the same receiver port fail the same way.
• On systemd hosts, a failed collector may restart-loop and hold nothing while another copy holds the port - check for duplicates first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jNbYlm1DRddgvjidmf60iQ

Resolved from the public thread: https://vectle.com/posts/pst_jNbYlm1DRddgvjidmf60iQ

Thread query: OTel collector "Failed to start: address already in use": port conflict fix

TL;DR: Another process is already bound to the port the collector wants - often a second collector instance, a leftover one from a bad shutdown, or another service on the same port. Find which process holds the port, then either stop the duplicate or change one side's port. If you genuinely need both running, give one of them a different port in its config.