Port is already allocated docker как исправить

asked Sep 12, 2017 at 12:37

The quick fix is ​​a just restart docker:

1. sudo service docker stop
2. sudo service docker start

answered Jan 4, 2021 at 8:03

When I used nginx docker image, I also got this error:

docker: Error response from daemon: driver failed programming external connectivity on endpoint recursing_knuth (9186f7d7f523732b99d3510029cde9679f3f3fe7b7eb5f612d54c4aacea58220): Bind for 0.0.0.0:8080 failed: port is already allocated.

And I solved it using following commands:

$ docker container ls
$ docker stop [CONTAINER ID]

Then, running this docker container(like this) again is ok:

$ docker run -v $PWD/vueDemo:/usr/share/nginx/html -p 8080:80 -d nginx:alpine

You just need to stop the previous docker container.

answered Jul 13, 2021 at 7:36

I have had same problem with docker-compose, to fix it:

1. Killed docker-proxy processe
2. Restart docker
3. Start docker-compose again

answered Apr 27, 2022 at 7:20

docker ps will reveal the list of containers running on docker. Find the one running on your needed port and note down its PID.

Stop and remove that container using following commands:

docker stop PID
docker rm PID

Now run docker-compose up and your services should run as you have freed the needed port.

For anyone having this problem with docker-compose.
When you have more than one project (i.e. in different folders) with similar services you need to run docker-compose stop in each of your other projects.

answered Mar 10, 2021 at 14:00

In my case, there was no process to kill.

Updating docker fixed the problem.

answered Jan 10, 2021 at 21:43

FOR WINDOWS;
I killed every process that docker use and restarted the docker service on services. My containers are working now.
It is about ports that is still in use by Docker even though you are not using on that moment.

answered Feb 11, 2019 at 1:14

Had the same problem. Went to Docker for Mac Dashboard and clicked restart. Problem solved.

For anyone still looking for a solution, just make sure you have binded your port the right way round in your docker-compose.yml

It goes:
- <EXTERNAL SERVER PORT>:<INTERNAL CONTAINER PORT>

answered Mar 2, 2022 at 21:02

my case was dump XD I was exposing port 80 twice

        ports:
            - '${APP_PORT:-80}:80'
            - '${APP_PORT:-8080}:8080'

APP_PORT is defined, thus 80 was exposed twice.

answered Sep 28, 2022 at 14:05

I tried almost all solutions and found out the probable/possible reason/solution. So, If you are using traefik or any other networking server, they internally facilitate proxy for load balacing. That, most use the blueprint as it, works pretty fine. It then passes the load control entirely to nginx or similiar proxy servers. So, stopping, killing(networking server) or pruning might not help.

Solution for traefik with nginx,

sudo /etc/init.d/nginx stop
# or
sudo service nginx stop
# or
sudo systemctl stop nginx

Credits

answered Nov 10, 2022 at 7:39

answered Apr 16, 2022 at 7:25

Hi @shin- ,

I just did a hard reset on my machine and I get:

$ docker-compose up
_collections.so could not be extracted!

After that I have the same issue as posted by @PatrickConnors :

Any ideas?

@budnik Try running docker-compose down to clean up containers and networks, then up again and see if that fixes things.

I ran into the same issue today (with a postgres container), and despite having tried docker-compose down and then up again, the problem still persists.

Both docker-compose ps and docker ps show me an empty output.

I may have found a solution, though:

this is how my postgres service is defined

version: '2.1'

services:

  postgres:
    image: postgres:9.5.4
    env_file:
      - docker-compose.env
    ports:
      - 5432:5432

and in my case the fix was simply to disable the port binding, that is changing the last part as:

Not sure if this is the right solution, nor if it can be generally applied to all use cases.

Might it be an issue with docker-compose itself ?
For reference:

$ docker-compose --version
docker-compose version 1.12.0, build b31ff33

I was having the same issue after updating my docker-compose to 3.3 version.
@lorenzo-pasa solution work locally for me (still need to try in prod)

Below is part of my docker-compose for reference:

nginx:
    image: nginx:1.12.2-alpine
    volumes:
      - .:/usr/share/nginx/app
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
    ports:
      - "80"
    depends_on:
      - web

I had this and also stuff like Cannot start service mysql: network 4b8e7a23e3724fd351e428be30cdf7a9294d142ac23959ca9092278fc81e96c1 not found. I resolved them by using --build --force-recreate flags for the up command.

This 👇 works for me!!

docker-compose down
docker rm -fv $(docker ps -aq)
sudo lsof -i -P -n | grep 5432

• For Mac

• Linux

ERROR: for iky_gateway Cannot start service iky_gateway: b’driver failed programming external connectivity on endpoint iky_gateway (47d83edbbc1568eae6d26f5e75931797b7e23c6528ff7cc8140f50811fb44922): Error starting userland proxy: Bind for 0.0.0.0:8080 failed: port is already allocated’

I’ve tried docker-compose down, didn’t fix it.

Another solution that may be helpful to future readers is: double-check your docker-compose.yml file and check to make sure you don’t have 2 items attempting to run on port 8080.

If you do have 2 items configured to run on port 8080 you can get «port already allocated» error message for the service/container that is not causing the problem — which will cause you confusion when you try and kill the service/container and get no resolution to the error message.

@Rub21’s solution worked for me, except kill -9 {pid} kept restarting the process. This was because I had MySQL Server running. On OSX I had to:

1. System Preferences
2. Search for mysql
3. Press the Stop MySQL Server button

I removed port binding and it worked for me, instead of doing
mysql:
ports:
— 3306:3306
i had to change to
mysql:
ports:
— 3306
and all was good.

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
Then remove any existing data e.g docker volume rm docker_db_data
docker-compose up

Same problem here. I am using docker version 17.05.0-ce, build 8965be, with docker-compose 1.13.0 and 1.22.0. The compose-yml file is 3.2.

With apologies to @KazibweStephen , this is not a useful solution. You are telling docker-compose to pick an abritrary port for clients to connect to the container’s mysql service. You might as well tell mysql not to listen to any port or just remove the port configuration altogether.

I have tried various solutions above, including rebooting the server. No other containers are running, and there are no conflicts in the yml file. I recall that this worked in a much older version of docker/compose. netstat -anp on the host shows nothing listening on the ports.

If I completely reomve the ports sections, the processes start up OK. I then use nsenter ... netstat to verify the container is listening in on the correct port (in its namespace). I then check with netstat to verify there is no conflict on the default namespace. I can then use a utility such as nc to listen on the same port.

I can see no reason vis-a-vis the documentation why the configuration does not work. The conclusion is there is something wrong with docker-compose’s proxy setup.

Unbelievable. I had, in fact, a tiny error which caused the problem. My configuration needed two ports, and one of these had a typo, replicating the other. facepalm

netstat | grep 5432?

Hi, when I run this, I got this message..

98808d86b49cff5d stream 0 0 98808d86b6dd9be5 0 0 0 /tmp/.s.PGSQL.5432. Can you please help me what to do ? Thanks

and in my case the fix was simply to disable the port binding, that is changing the last part as:

Not sure if this is the right solution, nor if it can be generally applied to all use cases.

Might it be an issue with docker-compose itself ?
For reference:

$ docker-compose --version
docker-compose version 1.12.0, build b31ff33

This fix worked for me.

docker-compose -version
docker-compose version 1.23.1, build b02f1306

I had a slightly different situation, posting here to record another case of this happening.

When using a docker-compose.yml and docker-compose.override.yml file, which both contain a port mapping, where the host port is the same for both mappings, but the container port differs, then this causes docker to try and allocate the host port twice.

docker-compose.yml:

docker-compose.override.yml:

Perhaps this is an issue on its own, creating overriding mappings results in duplicate binding attempts. This situation is specifically narly because nothing is listening on the port until you attempt to bring the containers online. Which fails and therefor shuts down the entire composition, which results in the port becoming un-allocated again.

The solution of @lorenzo-pasa worked for me! I’m using docker-compose and nginx, running ubuntu OS, thanks dude.

I am curious: why is this issue closed, while numerous people still seem to encounter a problem(including myself)? Is the official fix to never write (for instance) 8080:8080 and to always write instead simply 8080? Just to be clear this is not a complaint I am sincerely curious.

@Ezwen agree
I tried out all of the suggestions posted above but still running in errors.
I’m running PHPstorm and try to Xdebug my application in a dockerbox. When starting the my dockerbox i am using docker-compose up with a

ports:
— «9001:9001»

which exposes the port correctly. (vpnkit.exe is a part of Docker)

I see that vpnkit.exe is listening to port 9001. So when I now try to start my Xdebug in PHPstorm it comes up with the error message

I don’t know why I can’t tell the PHPstorm debugger to listen to port 9001 while it is always used by vpnkit.exe when I start my docker container?

Thanks, @lorenzo-pasa ! That was exactly my problem and your solutions worked. I tried a lot of stuff to solve this with no result. Thank you, again!

I ran into the same issue today (with a postgres container), and despite having tried docker-compose down and then up again, the problem still persists.

Both docker-compose ps and docker ps show me an empty output.

I may have found a solution, though:

this is how my postgres service is defined

version: '2.1'

services:

  postgres:
    image: postgres:9.5.4
    env_file:
      - docker-compose.env
    ports:
      - 5432:5432

and in my case the fix was simply to disable the port binding, that is changing the last part as:

Not sure if this is the right solution, nor if it can be generally applied to all use cases.

Might it be an issue with docker-compose itself ?
For reference:

$ docker-compose --version
docker-compose version 1.12.0, build b31ff33

For me the issue was another docker container was still running in the background from a different project.

I fixed by running:

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)

I have a same issue as @maritaria mentioned about.

@freesoft It’s probably best to open a new issue for this.

I tried everything here but nothing seems to work then i did this:

sudo lsof -i -P -n | grep 5432

kill all the processes
sudo kill

then it worked for me.

Had the same issue with

 Version:           18.09.3
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        774a1f4
 Built:             Thu Feb 28 06:53:11 2019
 OS/Arch:           linux/amd64
 Experimental:      false

One of the docker-proxy processes was hanging, so killing it and systemctl restart docker solved the issue.

I ran docker system prune (be cautious with this command) and then restarted docker, it worked for me.

If you’re on WSL2, check to see if Hyper-V is enabled or not. If it isn’t, just enable it, that’ll do.

I removed port binding and it worked for me, instead of doing
mysql: ports: — 3306:3306
i had to change to
mysql: ports: — 3306
and all was good.

Solution above was what I needed, thanks a lot @KazibweStephen

I combined the answers of everybody.

docker-compose down
docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
systemctl restart docker
docker-compose up

Changing the port from

to

ports:
    - "10080:80"
    - "10443:443"

in the docker-compose.yml file helped me solve this issue.

One potential solution for this is you don’t always need to have an external port binding in your docker-compose.yml file:

Should be sufficient for postgres, as you only really want container <=> container interactions for development. (You shouldn’t be shipping your DB in a container tho for production environments).

Worked for me

docker-compose down
docker network prune
sudo service docker restart
docker-compose up

Thanks! Pruning the network after docker-compose down was the thing that I missed by trying the previous answers.

@drauscher

@Ezwen agree
I tried out all of the suggestions posted above but still running in errors.
I’m running PHPstorm and try to Xdebug my application in a dockerbox. When starting the my dockerbox i am using docker-compose up with a

ports:

• «9001:9001»

which exposes the port correctly. (vpnkit.exe is a part of Docker)

I see that vpnkit.exe is listening to port 9001. So when I now try to start my Xdebug in PHPstorm it comes up with the error message

I don’t know why I can’t tell the PHPstorm debugger to listen to port 9001 while it is always used by vpnkit.exe when I start my docker container?

Have you had a solution for this problem? I just run into it the xdebug was working fine until yesterday evening then in storm:
Can't start listening for connections from 'xdebug': Port 21003 is busy
and restart the containers:
Cannot start service backend: Ports are not available: listen tcp 0.0.0.0:21003: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
literally i changed nothing one run worked the other started to fail.

compose file:

backend:
image: backend
links:
— «bc2db»
depends_on:
— bc2db
ports:
— «21443:443»
— «2180:80»
— «21000:8000»
— «21003:9003»
…
gateway:
image: gateway
links:
— «bc2db»
depends_on:
— bc2db
ports:
— «23443:443»
— «2380:80»
— «23003:9003»

All of which are working except the xdebug. All the solution what were mentioned here have been tried none of them works for me. The confusion is this was working in one secundes and suddenly stopped everything in the next one.

In my case I had this problem because there were two replicas in my compose file:

version: '3'
services:
    web:
        build: .
        ports:
            - "5000:5000"
        deploy:
            replicas: 2

When I’ve changed a number of replicas to one, docker-compose up started working

I don’t see why this issue has been closed. Pruning networks or forcefully restarting docker daemon is a workaround for a bug — it’s not that the bug went away, it’s just people embraced workarounds.

This happens quite often on multiple machines and looks like a bug, though not an easy to reproduce one

I had the same problem two times now….
I tried the solutions of above, but none seemed to help me. I restarted and it did not work. Hence I shut my MAC fully down and manually restarted it. Finally docker-compose up worked without any problems.
-> Sometimes restarting is a simple but effective solution

I don’t see why this issue has been closed. Pruning networks or forcefully restarting docker daemon is a workaround for a bug — it’s not that the bug went away, it’s just people embraced workarounds.

This happens quite often on multiple machines and looks like a bug, though not an easy to reproduce one

Yes, My thought also is same as you.
As we can see. many developers got this problem.
I think this problem has to solve as programmatically.

For me the issue was another docker container was still running in the background from a different project.

I fixed by running:

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)

Doing this, then restarting docker engine & docker-compose up worked for me.

For me the issue was another docker container was still running in the background from a different project.
I fixed by running:

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)

Doing this, then restarting docker engine & docker-compose up worked for me.

That’s not really a solution in a production environment :-/

For me the issue was another docker container was still running in the background from a different project.
I fixed by running:

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)

Doing this, then restarting docker engine & docker-compose up worked for me.

That’s not really a solution in a production environment :-/

Fortunately I’ve never encountered this error on my production environment, only on my local dev env (macos).

Thanks @olfamoussaoui, that work for me

if you are using Windows you need to run the following command:
docker-compose down
netstat -ano | findstr :port ( as example netstat -ano | findstr :18080)
taskkill /pid the_pid_of_the_port /f
docker-compose up
And that’s it 😄

what worked for me:

docker-compose down
docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
launchctl list | grep docker
launchctl stop com.docker.docker.<number>

so I’m not sure if this is a fluke, but for some reason after I quit Spotify it seemed to work. I’ve tried most of the solutions above before that

docker-compose down docker stop $(docker ps -a -q) docker rm $(docker ps -a -q) launchctl list | grep docker launchctl stop com.docker.docker.<number>

Yes, this works but make sure you know what ‘launchctl’ does (it stops docker but that doesn’t clear up the problem per se as starting/stopping docker alone did not stop the error from reappearing). The important part is the ‘docker rm’ because it seems to remove the port allocation that docker is perceiving (likely deleting some reference in docker). For example, this ‘docker-compose.yml’ of mine (below) suddenly stopped launching with the error that port 5665 was already allocated even with no containers running in my system. docker compose down/stop/rm seemed to clear whatever was making docker think the port was already allocated.

version: "3"
services:
  postgres:
    image: postgres:13
    container_name: graphstruct_db
    volumes:
      - ./graphstruct:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=graphstruct_data
    ports: 
      - 5665:5432
volumes:
  graphstruct:

I’m having this issue in Docker Compose version v2.6.0

Mentioned in #9117

If you use windows and if non of them worked, Delete your relevant container in Docker. Then right click on docker tray icon at the bottom right of the screen and close docker. Try run again.

I ran into the same issue today (with a postgres container), and despite having tried docker-compose down and then up again, the problem still persists.

Both docker-compose ps and docker ps show me an empty output.

I may have found a solution, though:

this is how my postgres service is defined

version: '2.1'

services:

  postgres:
    image: postgres:9.5.4
    env_file:
      - docker-compose.env
    ports:
      - 5432:5432

and in my case the fix was simply to disable the port binding, that is changing the last part as:

Not sure if this is the right solution, nor if it can be generally applied to all use cases.

Might it be an issue with docker-compose itself ? For reference:

$ docker-compose --version
docker-compose version 1.12.0, build b31ff33

You saved my day