You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
I try to start a docker container without passing the host port. I expect the docker will automatically assign a free port and run the container. That's the case most of the time. After some time though the automatic assigned port (which with every run is incremented +1) happens to be not available.
The behavior now when I run e.g.: docker run -d -p 27017 mongo
that docker starts the container without any error or warning: 73d28c33cfb7 mongo:latest "docker-entrypoint.s…" 2 hours ago Up 2 hours 0.0.0.0:49169->27017/tcp squa_mongodb_637498526118689048_fd3c7e4adda39eec651287ad30
I try to connect to the image but I got an connection error. The error message is to be found in the docker log file: [14:52:37.339][GoBackendProcess ][Error ] msg="unable to expose port TCP 0.0.0.0:49169 -> 127.0.0.1:49169: listen tcp 0.0.0.0:49169: bind: An attempt was made to access a socket in a way forbidden by its access permissions."
When I try to run the command with explicit port: docker run -d -p 49169:27017 mongo
It fails already while creating with the same message from the log.
Steps to reproduce the issue:
Make sure the next port that will be automatically assigned by docker is already taken/not available
Run the docker run -d -p 27017 IMAGE_NAME
Try to connect to the exposed port
I'm aware that the process of determining an free port may be not trivial. But I think the current behavior is incorrect. I think the correct behavior would be:
crash and inform me on the moment of creation that the port is taken
try next until got a free port, break when timeout reached
I'm also concerned how the auto port range is set and when does it resets. In my case a workaround was to completely uninstall docker and (that's important) delete everything docker related from ProgramData/Program Files/AppData. Only then the counter was reseted.
Just to be clear- we use this behavior in Squadron to spin up containers with resources for integration tests. It happened on developer pc that was running large amount of unit tests so hundreds if not thousands of containers were sinned until this happened. But either way it's an issue.
Output of docker version:
Client: Docker Engine - Community
Cloud integration: 1.0.7
Version: 20.10.2
API version: 1.41
Go version: go1.13.15
Git commit: 2291f61
Built: Mon Dec 28 16:14:16 2020
OS/Arch: windows/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.2
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: 8891c58
Built: Mon Dec 28 16:15:28 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.4.3
GitCommit: 269548fa27e0089a8b8278fc4fc781d7f65a939b
runc:
Version: 1.0.0-rc92
GitCommit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Output of docker info:
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
scan: Docker Scan (Docker Inc., v0.5.0)
Server:
Containers: 7
Running: 3
Paused: 0
Stopped: 4
Images: 16
Server Version: 20.10.2
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
Default Runtime: runc
Init Binary: docker-init
containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b
runc version: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
init version: de40ad0
Security Options:
seccomp
Profile: default
Kernel Version: 4.19.104-microsoft-standard
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 24.84GiB
Name: docker-desktop
ID: 27ZQ:PHKD:H2HX:M6O2:HVZD:6BFD:XUUQ:JXZF:BZ3S:UUGL:YPNS:NJ3T
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No blkio weight support
WARNING: No blkio weight_device support
WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Additional environment details (AWS, VirtualBox, physical, etc.):
OS Name Microsoft Windows 10 Pro
Version 10.0.19042 Build 19042
The text was updated successfully, but these errors were encountered:
@Carael
I ran into this problem. I originally thought it had something to do with our dev tooling (Visual Studio 2022). The details of my story can be found here: microsoft/DockerTools#326
A highlight from my issues is that VS 2022 uses the -P flag which makes matters worse because you don't know something went wrong until a browser opens. Identifying a specific port early on shows the error bind: An attempt was made to access a socket in a way forbidden by its access permissions. as was previously mentioned causes the build to fail before the browser auto-launches.
Another highlight, I noticed there is a port range 49152 - 49869 (not 100% solid range) that the ports report back with this error. When I run netstat -aon - I did not see ports in use by any process that I was trying to use in that range. So it makes me think that "in-use" might not be the same as "forbidden by its access permissions", purely conjecture on my part.
Description
I try to start a docker container without passing the host port. I expect the docker will automatically assign a free port and run the container. That's the case most of the time. After some time though the automatic assigned port (which with every run is incremented +1) happens to be not available.
The behavior now when I run e.g.:
docker run -d -p 27017 mongo
that docker starts the container without any error or warning:
73d28c33cfb7 mongo:latest "docker-entrypoint.s…" 2 hours ago Up 2 hours 0.0.0.0:49169->27017/tcp squa_mongodb_637498526118689048_fd3c7e4adda39eec651287ad30
I try to connect to the image but I got an connection error. The error message is to be found in the docker log file:
[14:52:37.339][GoBackendProcess ][Error ] msg="unable to expose port TCP 0.0.0.0:49169 -> 127.0.0.1:49169: listen tcp 0.0.0.0:49169: bind: An attempt was made to access a socket in a way forbidden by its access permissions."
When I try to run the command with explicit port:
docker run -d -p 49169:27017 mongo
It fails already while creating with the same message from the log.
Steps to reproduce the issue:
I'm aware that the process of determining an free port may be not trivial. But I think the current behavior is incorrect. I think the correct behavior would be:
I'm also concerned how the auto port range is set and when does it resets. In my case a workaround was to completely uninstall docker and (that's important) delete everything docker related from ProgramData/Program Files/AppData. Only then the counter was reseted.
Just to be clear- we use this behavior in Squadron to spin up containers with resources for integration tests. It happened on developer pc that was running large amount of unit tests so hundreds if not thousands of containers were sinned until this happened. But either way it's an issue.
Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.):
OS Name Microsoft Windows 10 Pro
Version 10.0.19042 Build 19042
The text was updated successfully, but these errors were encountered: