Replies: 2 comments
-
Unfortunately, this is not a complete fix... Automatic1111 runs now, but the extension Adetailer appears to be trying to communicate with the API over the old 7860 port. Looking a bit more at the docker-compose.yml file I see in the line, middle of the script, where the command line options are given. Mine had: |
Beta Was this translation helpful? Give feedback.
-
This is weird, I run Win10 and WSL2 and never had this problem.
or you can just run
This is weird, if you combine it with the previous command you should be able to see in the browser.
maybe this is something configurable in the extension, especially if it starts a separate server. not sure about this. |
Beta Was this translation helpful? Give feedback.
-
I started seeing this error when trying to launch the Docker Compose script for the auto profile:
Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:7860 -> 0.0.0.0:0: listen tcp 0.0.0.0:7860: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
I'm on WSL2 Ubuntu 20.04, so I thought "Oh, I must have something running on that port". Nope, checking via:
sudo lsof -i :7860
showed nothing on that port. Checking docker, no containers were even running on the host.
The actual issue? Win10, the WSL2 host chose to reserve that port for some unknown deominc reason, as seen by running this in a Power Shell window:
netsh interface ipv4 show excludedportrange protocol=tcp
That power shell command displays a series of system reserved port ranges, and 7860 is run in the middle of them.
The fix is to edit the docker-compose.yml file and change line 5's definition of the WEBUI_PORT. In my case, the nearest open port is 7974, so I made my line 5 look like:
- "${WEBUI_PORT:-7974}:7860"
And then run the docker compose script as usual, but when visiting the site you'll need to use port 7974 on your browser's address bar, like this:
http://localhost:7974/
Beta Was this translation helpful? Give feedback.
All reactions