How to Fix the Docker Error: ‘bind: address already in use’

Encountering the error message Error starting userland proxy: listen tcp 0.0.0.0:#: bind: address already in use (where # is a specific port number like 3000, 8080, or

9000) is a common hurdle when attempting to start Docker containers, particularly using docker-compose up or docker run commands. This typically occurs when attempting to map a container port to a host port that is already occupied.

This article delves into the reasons behind this port conflict and provides a structured approach with various methods to diagnose and resolve the issue, enabling your containers to start successfully.

Understanding the “Address Already in Use” Error

The fundamental cause of this error is straightforward: a network port on the host machine that a Docker container needs to bind to is already being used by another process. Operating systems permit only one process to listen on a specific IP address and port combination at any given time.

When Docker attempts to establish a proxy for port mapping and finds the host port unavailable, it fails with the “address already in use” message.

The conflicting process could be:

  • Another running Docker container (perhaps from a different project or an orphaned instance).
  • A native web server like Apache, Nginx, or IIS running directly on the host.
  • Other services such as databases (e.g., Redis, MySQL if mapped to the host), development tools, or system processes.
  • Specific operating system features, like macOS’s AirPlay Receiver.
  • Development environment tools, such as PHPStorm’s debugging listener or a locally running Jupyter Notebook server.

Common Sources of Port Occupation

Troubleshooting and Solutions

Resolving this error involves identifying the process occupying the port and then either stopping that process or reconfiguring Docker (or the conflicting application) to use a different port.

Read: How to kill and Find processes listening to port 3000 on Mac

Step 1: Identify the Conflicting Process

The first step is to determine exactly which application is listening on the problematic port. Different commands can be used depending on the operating system. Note that administrative privileges (using sudo on Linux/macOS) are often required to get complete process information.

  • Linux/macOS using netstat:
    sudo netstat -pna | grep #

    (Replace # with the actual port number, e.g., 3000)

    This command lists network connections and listening ports, showing the process ID (PID) and name associated with the port.

  • Linux/macOS using lsof (List Open Files):
    sudo lsof -i -P -n | grep #

    (Replace # with the actual port number, e.g., 9000)

    This is another powerful command to find which process is using a specific network port.

  • Linux using alternative netstat flags:
    netstat -nlp | grep #

    or

    netstat -tulnp | grep #

    (Replace # with the actual port number, e.g., 8888 or 8080)

    These variations also display listening ports and associated PIDs/program names.

  • Windows using netstat:
    netstat -aof | findstr :#

    (Replace # with the actual port number, e.g., 3000)

    This command lists connections and includes the PID. You can then cross-reference the PID in Task Manager.

Once the PID and/or process name is identified, proceed with one of the following solutions.

Read: How to Fix Cannot connect to the Docker daemon at unix:/var/run/docker.sock

Solution Group 1: Addressing the Conflicting Process

Terminate the Process (Use with Caution)

If the conflicting process is not essential, it can be terminated.

  • Linux/macOS: Use the kill command with the PID found. The -9 flag forces termination.
    sudo kill #PID#

    or for forceful termination:

    sudo kill -9 #PID#

    (Replace #PID# with the actual process ID)

    A combined command using lsof:

    kill -9 $(lsof -t -i tcp:#)

    or with sudo:

    sudo kill -9 `sudo lsof -t -i:#`

    (Replace # with the port number, e.g., 8000)

  • Windows: Use Task Manager (find the process by PID and end task) or the taskkill command in Command Prompt/PowerShell (requires PID).

Note: Some processes might restart automatically if managed by a service manager (like systemd or launchd). In such cases, stopping the service itself is necessary.

Read: How to Fix ‘docker: not found’; in Jenkins Docker Container Pipelines

Stop Specific Host Services

Often, common services running directly on the host cause port conflicts.

  • Apache Web Server (Linux):
    sudo service apache2 stop

    or

    sudo /etc/init.d/apache2 stop

    If Apache is not needed, consider removing it (e.g., sudo apt remove apache2 on Debian/Ubuntu).

  • Nginx Web Server (Linux):
    sudo service nginx stop

    or

    sudo nginx -s stop
  • Combined Apache/Nginx Stop:
    sudo service apache2 stop; sudo service nginx stop; sudo nginx -s stop;
  • Redis Server (Linux): If Redis is running as a service, killing the process might not be sufficient as it may restart. Stop the service instead:
    sudo service redis-server stop
  • Grafana (Windows Service): If Grafana was installed as a binary and started, it might run as a system service. Use the Windows Services manager (services.msc) to find the “Grafana” service and stop it.
  • MongoDB (macOS via Homebrew):
    sudo brew services stop mongodb-community
  • Windows Network Address Translation (Winnat): In some Windows scenarios, temporarily stopping and restarting the WinNAT service can resolve port allocation issues:
    net stop winnat
    # Attempt docker-compose up here
    net start winnat

macOS AirPlay Receiver Conflict (Port 5000)

On macOS Monterey and later, the native AirPlay Receiver service often occupies port 5000, used by many development servers. Killing the ‘ControlCenter’ process is ineffective as it restarts automatically.

  • Go to System Preferences > Sharing.
  • Uncheck the AirPlay Receiver option in the list of services. This will release port 5000.

Development Tool Conflicts

  • PHPStorm Debug Listener: If the conflict involves port 9000 (a common Xdebug port), check if PHPStorm’s debug listener is active and turn it off via its toolbar icon if not needed.
  • Jupyter Notebook: If Jupyter is using the required port (e.g., 8888), you can reconfigure it. Edit or create the config file ~/.jupyter/jupyter_notebook_config.py and set a different port:
    c.NotebookApp.port = 9999 # Or any other available port

    If the config file doesn’t exist, generate it first:

    jupyter notebook --generate-config
  • PHP-FPM: If a locally installed PHP-FPM service conflicts (often on port 9000), find its configuration file (e.g., /usr/local/etc/php//php-fpm.d/www.conf), change the port in the listen = 127.0.0.1:9000 directive, and then restart the PHP-FPM service.

Read: Setting Timezones in Docker Containers

Solution Group 2: Managing Docker Containers

Stop or Remove Conflicting Containers

The conflict might originate from another Docker container.

  • Within the same project (docker-compose.yml): If you previously ran docker-compose up and didn’t stop the containers, use:
    docker-compose down

    This stops and removes containers defined in the current directory’s compose file.

  • Caution with image removal: Using docker-compose down --rmi all will also remove the Docker images associated with the services. Use this carefully.
  • Any container on the system: Find running containers using docker ps. Identify the container using the conflicting port and stop it:
    docker stop #CONTAINER_ID_OR_NAME#

    (Replace #CONTAINER_ID_OR_NAME# with the actual ID or name)

  • Remove All Containers: If unsure which container is causing the issue, or to clean up orphaned containers, forcefully remove all stopped and running containers (use with caution, this affects all containers on your system):
    docker rm -fv $(docker ps -aq)

    or

    docker rm -f $(docker ps -aq)

    (You might need sudo before the docker commands depending on your setup).

  • Check compose environment state: Use docker-compose ps to view containers managed by the current compose file and docker-compose stop to stop a specific service.

Solution Group 3: Reconfiguring Ports and Networks

Modify Docker Port Mappings

If the conflicting host process is essential, change the port mapping for the Docker container instead.

  • In docker-compose.yml: Modify the ports section. Change the host port (the part before the colon) to an available port.
    services:
      my_service:
        image: some_image
        ports:
          - "#NEW_HOST_PORT#:#CONTAINER_PORT#" # e.g., - "8881:80" instead of "8080:80"

    (Replace #NEW_HOST_PORT# with an unused port and #CONTAINER_PORT# with the container’s internal port)

  • In docker run command: Change the host port in the -p flag.
    docker run -d -p #NEW_HOST_PORT#:#CONTAINER_PORT# some_image

    (e.g., -p 1522:1521 instead of -p 1521:1521)

Correct Docker Configuration Errors

  • Duplicate Port Mappings: Check your docker-compose.yml or docker run command carefully. Ensure you are not attempting to map the same host port twice for the same service or container. For example, having both - "3306:3306" and - "127.0.0.1:3306:3306" in a compose file for the same service will cause a conflict. Remove the duplicate entry. Similarly, avoid repeating flags like -p 80:80 -p 127.0.0.1:80:80 in a `docker run` command.
  • Docker Compose Network Conflicts: In complex setups with custom networks, dynamic IP assignment might lead to conflicts if containers start in an unexpected order and one grabs an IP intended for another service with a static assignment. Consider assigning static IPv4 addresses explicitly to all services within the custom network configuration in your `docker-compose.yml`.
    services:
      service1:
        networks:
          custom_net:
            ipv4_address: 10.10.100.2
      service2:
        networks:
          custom_net:
            ipv4_address: 10.10.100.3 # Assign IPs to avoid conflicts
    
    networks:
      custom_net:
        ipam:
          config:
            - subnet: 10.10.100.0/24
  • Network Mode: In specific cases, changing network_mode from the default bridge to host in `docker-compose.yml` might be considered, but be aware this bypasses Docker’s network isolation and directly exposes the container’s network stack on the host interface, which has security implications and can cause its own port conflicts.

Solution Group 4: Restarting Services

Restart the Docker Daemon

Sometimes, Docker’s internal state or its proxy process might be stuck. Restarting the Docker service can resolve transient issues.

  • Linux (systemd):
    sudo systemctl restart docker
  • Linux (older init systems):
    sudo service docker restart
  • Docker Desktop (macOS/Windows): Use the UI option to restart Docker.

Restart the Host Machine

As a final measure, if none of the above solutions work, restarting the computer can clear underlying issues or terminate stubborn processes that were missed. While not ideal, it sometimes resolves inexplicable port conflicts.

Verification

After applying a potential solution, attempt to start your Docker container again using the original command (e.g., docker-compose up or docker run ...). If the error message does not reappear and the container starts successfully, the issue is resolved.

You can also re-run the identification commands (netstat or lsof) before starting the container to confirm that the problematic port is indeed free.

Conclusion

The “bind: address already in use” error in Docker indicates a port conflict on the host machine. The resolution path involves identifying the process currently using the required port and then deciding whether to terminate that process, stop the associated service, reconfigure the conflicting application to use a different port, or modify the Docker configuration to map to an alternative host port. Systematically checking running processes, native services, other containers, and Docker configurations will typically lead to a swift resolution.

 

Seb da Silva

Seb brings a practical, end-user-focused perspective to the IT world, drawing from years of experience in technical support and IT consulting for small businesses. He covers a wide range of topics including Windows and Linux desktop customization, hardware reviews and troubleshooting, software comparisons, mobile device integration, and general IT best practices for home users and professionals alike. David excels at translating technical jargon into clear, easy-to-understand advice.