JBoss - ExportException: Port already in use: 1098 - windows
I'm getting the following error when I try to start JBoss
10:10:43,298 INFO [WebService] Using RMI server codebase: http://127.0.0.1:8083/
10:10:43,938 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=Naming state=Create mode=Manual requiredState=Installed
java.rmi.server.ExportException: Port already in use: 1098; nested exception is:
java.net.BindException: Address already in use: JVM_Bind
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:249)
at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:184)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116)
at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:180)
at java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject.java:293)
at java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject.java:256)
However When I try to see what ports are being listened to. I don't see that port!
H:\>netstat -a -n -o
Active Connections
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 824
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:1521 0.0.0.0:0 LISTENING 2036
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 752
TCP 0.0.0.0:7717 0.0.0.0:0 LISTENING 2944
TCP 0.0.0.0:8081 0.0.0.0:0 LISTENING 1564
TCP 0.0.0.0:31038 0.0.0.0:0 LISTENING 1436
TCP 127.0.0.1:1038 0.0.0.0:0 LISTENING 2036
TCP 127.0.0.1:1052 0.0.0.0:0 LISTENING 2620
TCP 127.0.0.1:5998 127.0.0.1:5999 ESTABLISHED 4036
TCP 127.0.0.1:5999 127.0.0.1:5998 ESTABLISHED 4036
TCP 127.0.0.1:6000 127.0.0.1:6001 ESTABLISHED 4036
TCP 127.0.0.1:6001 127.0.0.1:6000 ESTABLISHED 4036
TCP 142.174.27.74:139 0.0.0.0:0 LISTENING 4
TCP 142.174.27.74:13148 142.174.12.84:445 ESTABLISHED 4
TCP 142.174.27.74:13253 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13255 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13258 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13259 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13260 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13261 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13262 142.174.134.33:8080 ESTABLISHED 4036
TCP 142.174.27.74:13263 142.174.134.33:8080 ESTABLISHED 4036
UDP 0.0.0.0:445 *:* 4
UDP 0.0.0.0:8081 *:* 1564
UDP 0.0.0.0:8082 *:* 1564
UDP 0.0.0.0:19508 *:* 1244
UDP 127.0.0.1:123 *:* 948
UDP 127.0.0.1:1025 *:* 580
UDP 127.0.0.1:1046 *:* 524
UDP 127.0.0.1:1056 *:* 784
UDP 127.0.0.1:1213 *:* 2888
UDP 127.0.0.1:1257 *:* 2404
UDP 127.0.0.1:2172 *:* 3736
UDP 127.0.0.1:2310 *:* 2188
UDP 142.174.27.74:123 *:* 948
UDP 142.174.27.74:137 *:* 4
UDP 142.174.27.74:138 *:* 4
H:\>
any ideas?
Thanks,
Tam
Try TCPView (TCPView v3.05). I get this "port already in use" quite a lot, and TCPView always usually catches the culprit.
Go to jboss-service.xml under conf folder and change the port for RMI from 1098 to 8099 8099
Restart the server .
We ran into this problem some time ago as well, not just with JBoss, but also MySQL.
I wrote about it in more detail here:
Windows TCP Port Conflicts above 1024
What it comes down to is that Windows uses the port range between 1000 and 5000 for so called "ephemeral" ports. This means that it assigns ports from this range for processes that request a random port.
On Windows 2000/2003 Server installations as well as on Windows XP Pro you can reserve port ranges (even if they only cover a single port) for your applications. Effectively they are not reserved for anything specific, but just excluded from the dynamic allocation. To do so, create or edit the following registry value (type REG_MULTI_SZ/Multi-String Value):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ReservedPorts
In this value specify port ranges in the format xxxx-yyyy with xxxx and yyyy being the lowest and highest port of the range to be reserved. To reserve a single port, just use the same values for both (e. g. 1099).
I guess that port is still in use. You can find that using:
netstat -ao
and
netstat -b
If you can't use that port, find another port and change it in the following XML file:
conf/bindings-beans/META-INF/bindings-jboss-beans.xml
The JBoss 5 has a new ServiceBindingManager which uses bean injection to assign ports at runtime. Changing the port here may do the trick for you.
You can also use a different ports configuration and override the ports by a factor.
Based on the ports mentioned in the file referenced by Sam, and the registry key referenced by Daniel Schneller, the following should do the trick for JBoss EAP 5:
1090-1090 1098-1102 1161-1162 3528-3528 4444-4448 4457-4457 4712-4714 5445-5446 8080-8083 8443-8443
Translated in a .reg file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"ReservedPorts"=hex(7):31,00,30,00,39,00,30,00,2d,00,31,00,30,00,39,00,30,00,\
20,00,31,00,30,00,39,00,38,00,2d,00,31,00,31,00,30,00,32,00,20,00,31,00,31,\
00,36,00,31,00,2d,00,31,00,31,00,36,00,32,00,20,00,33,00,35,00,32,00,38,00,\
2d,00,33,00,35,00,32,00,38,00,20,00,34,00,34,00,34,00,34,00,2d,00,34,00,34,\
00,34,00,38,00,20,00,34,00,34,00,35,00,37,00,2d,00,34,00,34,00,35,00,37,00,\
20,00,34,00,37,00,31,00,32,00,2d,00,34,00,37,00,31,00,34,00,20,00,35,00,34,\
00,34,00,35,00,2d,00,35,00,34,00,34,00,36,00,20,00,38,00,30,00,38,00,30,00,\
2d,00,38,00,30,00,38,00,33,00,20,00,38,00,34,00,34,00,33,00,2d,00,38,00,34,\
00,34,00,33,00,00,00,00,00
The root cause is that JBOSS was not peoperly shut down.
If you are using Windows,
go to task manager and kill the JBOSS processes.
Reserve the port 1098-1099 in registry.
Restart the oracle service if running, then start the JBOss.
This error is also thrown by Jboss if your default IP address changes due to some problem
means
121...89 to 121...90 Just check it and replace it with a newer IP address. It will work.
Related
Log4j2 socket appender inside a docker container throw connection refused
I have a springboot app running on docker container. In my app there is a log4j.xml file with socket appender. <Socket name="Socket" host="172.17.0.1" port="5100"> <JsonLayout compact="true" eventEol="true" /> </Socket> In my host server (Ubuntu server) its listing port 5100 by logstash. Out put of "netstat -tulpn" command in host is as below. Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:8280 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:5100 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:5001 0.0.0.0:* LISTEN - But when the springboot server up its getting connection refused error. 2021-07-30 05:20:47,646 main ERROR TcpSocketManager (TCP:172.17.0.1:5100) caught exception and will continue: java.net.ConnectException: Connection refused (Connection refused) at java.base/java.net.PlainSocketImpl.socketConnect(Native Method) I tried with "host.docker.internal" also and its not working. Can anyone let me know what is the problem with this please?
As you can see from your netstat output, Logstash is listening on 127.0.0.1:5100 only. That means it cannot be accessed from within Docker. You have to make it listen on 172.17.0.1:5100 or 0.0.0.0:5100.
Elasticsearch: How to know HTTP port number used when default 9200 is already in use
In the Elasticsearch documentation is specified the following regarding to the http.port configuration: http.port Port to bind to for incoming HTTP requests. Accepts a single value or a range. If a range is specified, the node will bind to the first available port in the range. Defaults to 9200-9300. Let's say that Elasticsearch automatically selects the port 9202 because the 9200 is already in use. How does a Java client application know which port was selected and has to be used to create a RestHighLevelClient object? Is there a way to query a another service that could provide the port number information? Thanks in advance. Update After the first answer I've tried to reproduce the steps in a Windows machine (production environment) by executing the following: > tasklist | findstr "elasticsearch" elasticsearch-service-x64 2232 Services 0 537,764 K > netstat -aon | find /i "2232" TCP 0.0.0.0:9200 0.0.0.0:0 LISTENING 2232 TCP 0.0.0.0:9300 0.0.0.0:0 LISTENING 2232 TCP 127.0.0.1:9200 0.0.0.0:0 LISTENING 2232 TCP 127.0.0.1:9300 0.0.0.0:0 LISTENING 2232 TCP 127.0.0.1:49201 127.0.0.1:49202 ESTABLISHED 2232 TCP 127.0.0.1:49202 127.0.0.1:49201 ESTABLISHED 2232 TCP 127.0.0.1:49203 127.0.0.1:49204 ESTABLISHED 2232 TCP 127.0.0.1:49204 127.0.0.1:49203 ESTABLISHED 2232 TCP 127.0.0.1:49205 127.0.0.1:49206 ESTABLISHED 2232 TCP 127.0.0.1:49206 127.0.0.1:49205 ESTABLISHED 2232 ... TCP 127.0.0.1:49275 127.0.0.1:49276 ESTABLISHED 2232 TCP 127.0.0.1:49276 127.0.0.1:49275 ESTABLISHED 2232 TCP [::1]:9200 [::]:0 LISTENING 2232 TCP [::1]:9300 [::]:0 LISTENING 2232 The result shows several lines where the 9200 port (http.port) is used: TCP 0.0.0.0:9200 0.0.0.0:0 LISTENING 2232 TCP 127.0.0.1:9200 0.0.0.0:0 LISTENING 2232 TCP [::1]:9200 [::]:0 LISTENING 2232 If I had to parse that result to get the port number, which of those IP addresses should I look for? or simply does not matter?
RestHighLevelClient is thread-safe and it's instantiated by the application at startup time or when the first request is executed. How is it being done "under the hood" maybe you can check in RestClientBuilder.java here. Not sure about the question, but if you are not sure which port ES is using you can check it [root#myserver ~]# service elasticsearch status elasticsearch (pid 5384) is running... ## netstat on pid [root#myserver~]# netstat -plunt | grep 5384 tcp 0 0 ::ffff:10.100.14.146:9300 :::* LISTEN 5384/java tcp 0 0 ::ffff:10.100.14.19:9200 :::* LISTEN 5384/java tcp 0 0 ::ffff:127.0.0.1:9200 :::* LISTEN 5384/java
Cannot bind to some ports due to permission denied
For the last 3 months or so I'm having random errors where I can't bind a specific port where our Identity server is running on my local development workstation. At first I thought it's my broken machine, so I reset everything, which kinda fixed the issue for 2 months and now it is back. In the meanwhile other developers saw the same issue. All of us who experience the issue are running Windows 10, but not everyone with Windows 10 has that issue. Restarting windows after it was shut down with shutdown /s /f /t 0 is the only reliable solution to open up the port again. After I restart normally (due to windows updates or similar) the issue comes up again an I need to shut down windows with that command. I wrote a small f# script to test which ports are affected. The exact error message I get is An attempt was made to access a socket in a way forbidden by its access permissions When I looked for it, the suggested solutions where to restart the machine, but that seems more like a work around, not a real solution. I've also found https://stackoverflow.com/a/10461978/621366 - but netstat -o doesn't list the port, neither does the tool TCPView. All of us are pretty sure that the port isn't occupied by anything. I also tried running netstat in an administrator console and similar commands inside bash on windows, but couldn't find anything. I can't even connect to the port via telnet, it says nothing is listening on the port. those ports in question are for instance: 49670 - 49689 49710 - 49749 49760 - 49779 49811 - 49830 49843 - 49882 50197 - 50216 None of us modified anything on the windows firewall or has any additional anti virus tools installed except the windows 10 default ones. So everything should be on default values. And it also worked normally for ~10 months before it broke the first time and afterwards for 2 months. In both cases after some windows updates where installed. The last time it was a bios update (probably due to the meltdown / spectre issues?). Also trying to open up the ports explicitly on the firewall didn't help. According to this answer https://stackoverflow.com/a/23982901/621366 TCPView and netstat shouldn't miss any occupied ports, but even when I enable showing unconnected endpoints in TCPView, I don't see any of the ports where I get permission denied when trying to bind them. Here a screen from the occupied ports (I marked the bordering occupied ports which are right before or after the group of permission-denied-ports) UPDATE: I've noticed that it always seems to be 160 or 180 (exact numbers) of ports which have permission denied in the ranges of 40,000+ This seems oddly coincidental to me, so obviously something is occupying the ports on purpose, but what? I can't seem to find anything in the windows event logs (although I wouldn't know what to look for exactly) and none of those ports shows up any any of my firewall rules. Also shutting down docker for windows doesn't make any difference and when a colleague mentioned that for them it's enough to restart docker for windows (in the UI go to Reset->Restart) and right now for me, even restarting with the shutdown command doesn't work anymore. UPDATE 2: The output of netstat -ano run from an administrator powershell: Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1152 TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:2179 0.0.0.0:0 LISTENING 4696 TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING 6616 TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:5432 0.0.0.0:0 LISTENING 11100 TCP 0.0.0.0:7680 0.0.0.0:0 LISTENING 7056 TCP 0.0.0.0:17500 0.0.0.0:0 LISTENING 9668 TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING 784 TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING 1628 TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING 2028 TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING 3560 TCP 0.0.0.0:49800 0.0.0.0:0 LISTENING 856 TCP 0.0.0.0:49821 0.0.0.0:0 LISTENING 892 TCP 0.0.0.0:50000 0.0.0.0:0 LISTENING 11100 TCP 0.0.0.0:50001 0.0.0.0:0 LISTENING 11100 TCP 0.0.0.0:51000 0.0.0.0:0 LISTENING 11100 TCP 10.0.75.1:139 0.0.0.0:0 LISTENING 4 TCP 10.0.75.1:445 10.0.75.2:44848 ESTABLISHED 4 TCP 127.0.0.1:843 0.0.0.0:0 LISTENING 9668 TCP 127.0.0.1:944 0.0.0.0:0 LISTENING 688 TCP 127.0.0.1:944 127.0.0.1:50968 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:50970 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:50973 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:50977 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:50981 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:50990 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:50992 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:50996 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:51005 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:51007 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:51009 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:51015 TIME_WAIT 0 TCP 127.0.0.1:944 127.0.0.1:51017 ESTABLISHED 688 TCP 127.0.0.1:4380 0.0.0.0:0 LISTENING 11024 TCP 127.0.0.1:6942 0.0.0.0:0 LISTENING 9296 TCP 127.0.0.1:17600 0.0.0.0:0 LISTENING 9668 TCP 127.0.0.1:49668 127.0.0.1:49669 ESTABLISHED 688 TCP 127.0.0.1:49669 127.0.0.1:49668 ESTABLISHED 688 TCP 127.0.0.1:50076 127.0.0.1:50077 ESTABLISHED 8828 TCP 127.0.0.1:50077 127.0.0.1:50076 ESTABLISHED 8828 TCP 127.0.0.1:50173 127.0.0.1:50174 ESTABLISHED 9668 TCP 127.0.0.1:50174 127.0.0.1:50173 ESTABLISHED 9668 TCP 127.0.0.1:50175 127.0.0.1:50176 ESTABLISHED 9668 TCP 127.0.0.1:50176 127.0.0.1:50175 ESTABLISHED 9668 TCP 127.0.0.1:50197 127.0.0.1:50198 ESTABLISHED 9668 TCP 127.0.0.1:50198 127.0.0.1:50197 ESTABLISHED 9668 TCP 127.0.0.1:50335 127.0.0.1:50336 ESTABLISHED 6424 TCP 127.0.0.1:50336 127.0.0.1:50335 ESTABLISHED 6424 TCP 127.0.0.1:50346 127.0.0.1:50347 ESTABLISHED 11100 TCP 127.0.0.1:50347 127.0.0.1:50346 ESTABLISHED 11100 TCP 127.0.0.1:51011 127.0.0.1:51012 ESTABLISHED 9296 TCP 127.0.0.1:51012 127.0.0.1:51011 ESTABLISHED 9296 TCP 127.0.0.1:51013 127.0.0.1:51014 ESTABLISHED 9296 TCP 127.0.0.1:51014 127.0.0.1:51013 ESTABLISHED 9296 TCP 127.0.0.1:51016 0.0.0.0:0 LISTENING 9296 TCP 127.0.0.1:51017 127.0.0.1:944 ESTABLISHED 8828 TCP 127.0.0.1:63342 0.0.0.0:0 LISTENING 9296 TCP 127.94.0.1:946 0.0.0.0:0 LISTENING 688 TCP 127.94.0.2:946 0.0.0.0:0 LISTENING 688 TCP 127.94.0.3:946 0.0.0.0:0 LISTENING 688 TCP 127.94.0.4:946 0.0.0.0:0 LISTENING 688 TCP 169.254.105.83:139 0.0.0.0:0 LISTENING 4 TCP 192.168.0.107:139 0.0.0.0:0 LISTENING 4 TCP 192.168.0.107:49415 111.221.29.134:443 ESTABLISHED 4316 TCP 192.168.0.107:49417 111.221.29.127:443 ESTABLISHED 4316 TCP 192.168.0.107:50185 162.125.66.3:443 CLOSE_WAIT 9668 TCP 192.168.0.107:50246 52.70.31.26:443 CLOSE_WAIT 9668 TCP 192.168.0.107:50253 35.177.204.73:443 ESTABLISHED 2804 TCP 192.168.0.107:50254 35.177.204.73:443 ESTABLISHED 2804 TCP 192.168.0.107:50256 35.177.204.73:443 ESTABLISHED 2804 TCP 192.168.0.107:50257 158.85.224.175:443 ESTABLISHED 10836 TCP 192.168.0.107:50258 13.69.14.160:443 ESTABLISHED 8620 TCP 192.168.0.107:50310 66.102.1.188:443 ESTABLISHED 11184 TCP 192.168.0.107:50329 157.240.20.15:443 ESTABLISHED 10836 TCP 192.168.0.107:50331 111.221.29.74:443 ESTABLISHED 10072 TCP 192.168.0.107:50332 162.125.18.133:443 ESTABLISHED 9668 TCP 192.168.0.107:50351 40.77.226.194:443 ESTABLISHED 8620 TCP 192.168.0.107:50460 66.102.1.189:443 ESTABLISHED 10836 TCP 192.168.0.107:50470 66.102.1.189:443 ESTABLISHED 10836 TCP 192.168.0.107:50501 192.30.253.125:443 ESTABLISHED 11184 TCP 192.168.0.107:50513 40.77.226.194:443 ESTABLISHED 8620 TCP 192.168.0.107:50529 87.98.218.198:443 ESTABLISHED 12540 TCP 192.168.0.107:50530 172.217.21.46:443 ESTABLISHED 10836 TCP 192.168.0.107:50616 172.217.21.46:443 ESTABLISHED 10836 TCP 192.168.0.107:50630 162.125.18.133:443 ESTABLISHED 9668 TCP 192.168.0.107:50641 172.217.21.37:443 ESTABLISHED 10836 TCP 192.168.0.107:50645 162.125.66.4:443 CLOSE_WAIT 9668 TCP 192.168.0.107:50668 87.98.218.198:443 ESTABLISHED 12540 TCP 192.168.0.107:50703 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50709 192.30.253.125:443 ESTABLISHED 11184 TCP 192.168.0.107:50744 87.98.218.198:443 ESTABLISHED 12540 TCP 192.168.0.107:50828 162.125.66.3:443 CLOSE_WAIT 9668 TCP 192.168.0.107:50830 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50831 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50832 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50834 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50835 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50836 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50837 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50839 192.30.253.125:443 ESTABLISHED 11184 TCP 192.168.0.107:50844 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50847 192.30.253.124:443 ESTABLISHED 11184 TCP 192.168.0.107:50857 192.30.253.124:443 ESTABLISHED 11184 TCP 192.168.0.107:50863 162.125.34.137:443 CLOSE_WAIT 9668 TCP 192.168.0.107:50865 172.217.21.46:443 TIME_WAIT 0 TCP 192.168.0.107:50866 172.217.21.46:443 ESTABLISHED 10836 TCP 192.168.0.107:50910 35.186.213.138:443 TIME_WAIT 0 TCP 192.168.0.107:50923 172.217.21.46:443 ESTABLISHED 10836 TCP 192.168.0.107:50925 40.117.190.72:443 ESTABLISHED 4040 TCP 192.168.0.107:50927 172.217.21.42:443 ESTABLISHED 11184 TCP 192.168.0.107:50949 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50950 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50951 151.101.0.133:443 ESTABLISHED 11184 TCP 192.168.0.107:50954 192.30.253.124:443 ESTABLISHED 11184 TCP 192.168.0.107:50959 40.117.190.72:443 TIME_WAIT 0 TCP 192.168.0.107:50969 192.30.253.113:22 TIME_WAIT 0 TCP 192.168.0.107:50978 87.98.218.198:443 ESTABLISHED 12540 TCP 192.168.0.107:50984 151.101.1.69:443 ESTABLISHED 11184 TCP 192.168.0.107:50985 192.0.73.2:443 ESTABLISHED 11184 TCP 192.168.0.107:50986 104.16.112.18:443 ESTABLISHED 11184 TCP 192.168.0.107:50991 198.252.206.25:443 ESTABLISHED 11184 TCP 192.168.0.107:50993 192.168.0.10:3910 TIME_WAIT 0 TCP 192.168.0.107:50994 192.168.0.10:3910 TIME_WAIT 0 TCP 192.168.0.107:50997 23.210.254.37:443 ESTABLISHED 912 TCP 192.168.0.107:50998 23.210.254.37:443 ESTABLISHED 912 TCP 192.168.0.107:50999 23.210.254.37:443 ESTABLISHED 912 TCP 192.168.0.107:51001 23.210.254.37:443 ESTABLISHED 912 TCP 192.168.0.107:51006 40.117.190.72:443 ESTABLISHED 11992 TCP 192.168.0.107:51008 40.69.218.62:443 ESTABLISHED 7056 TCP 192.168.0.107:51010 172.217.21.46:443 ESTABLISHED 11184 TCP [::]:135 [::]:0 LISTENING 1152 TCP [::]:445 [::]:0 LISTENING 4 TCP [::]:2179 [::]:0 LISTENING 4696 TCP [::]:5357 [::]:0 LISTENING 4 TCP [::]:7680 [::]:0 LISTENING 7056 TCP [::]:17500 [::]:0 LISTENING 9668 TCP [::]:49664 [::]:0 LISTENING 784 TCP [::]:49665 [::]:0 LISTENING 1628 TCP [::]:49666 [::]:0 LISTENING 2028 TCP [::]:49667 [::]:0 LISTENING 3560 TCP [::]:49800 [::]:0 LISTENING 856 TCP [::]:49821 [::]:0 LISTENING 892 TCP [::1]:5432 [::]:0 LISTENING 11100 TCP [::1]:50000 [::]:0 LISTENING 11100 TCP [::1]:50001 [::]:0 LISTENING 11100 TCP [::1]:51000 [::]:0 LISTENING 11100 UDP 0.0.0.0:53 *:* 5620 UDP 0.0.0.0:3702 *:* 2084 UDP 0.0.0.0:3702 *:* 2084 UDP 0.0.0.0:5050 *:* 6616 UDP 0.0.0.0:5353 *:* 11184 UDP 0.0.0.0:5353 *:* 11184 UDP 0.0.0.0:5353 *:* 11184 UDP 0.0.0.0:5353 *:* 3080 UDP 0.0.0.0:5353 *:* 11184 UDP 0.0.0.0:5353 *:* 11184 UDP 0.0.0.0:5353 *:* 11184 UDP 0.0.0.0:5353 *:* 11184 UDP 0.0.0.0:5355 *:* 3080 UDP 0.0.0.0:17500 *:* 9668 UDP 0.0.0.0:49670 *:* 2084 UDP 0.0.0.0:57329 *:* 5620 UDP 0.0.0.0:57330 *:* 5620 UDP 0.0.0.0:59529 *:* 8620 UDP 0.0.0.0:60605 *:* 11184 UDP 10.0.75.1:137 *:* 4 UDP 10.0.75.1:138 *:* 4 UDP 10.0.75.1:1900 *:* 2620 UDP 10.0.75.1:61326 *:* 2620 UDP 127.0.0.1:1900 *:* 2620 UDP 127.0.0.1:60816 *:* 4616 UDP 127.0.0.1:61328 *:* 2620 UDP 169.254.105.83:137 *:* 4 UDP 169.254.105.83:138 *:* 4 UDP 169.254.105.83:1900 *:* 2620 UDP 169.254.105.83:61330 *:* 2620 UDP 172.30.146.241:67 *:* 5620 UDP 172.30.146.241:68 *:* 5620 UDP 172.30.146.241:1900 *:* 2620 UDP 172.30.146.241:61329 *:* 2620 UDP 192.168.0.107:137 *:* 4 UDP 192.168.0.107:138 *:* 4 UDP 192.168.0.107:1900 *:* 2620 UDP 192.168.0.107:61327 *:* 2620 UDP [::]:3702 *:* 2084 UDP [::]:3702 *:* 2084 UDP [::]:5353 *:* 11184 UDP [::]:5353 *:* 11184 UDP [::]:5353 *:* 3080 UDP [::]:5353 *:* 11184 UDP [::]:5355 *:* 3080 UDP [::]:49671 *:* 2084 UDP [::]:57331 *:* 5620 UDP [::]:59529 *:* 8620 UDP [::1]:1900 *:* 2620 UDP [::1]:61323 *:* 2620 UDP [fe80::30eb:ad8f:f94a:b774%26]:1900 *:* 2620 UDP [fe80::30eb:ad8f:f94a:b774%26]:61324 *:* 2620 UDP [fe80::718c:22bb:fd97:c06c%23]:1900 *:* 2620 UDP [fe80::718c:22bb:fd97:c06c%23]:61322 *:* 2620 UDP [fe80::85d0:3b5c:7746:6953%5]:1900 *:* 2620 UDP [fe80::85d0:3b5c:7746:6953%5]:61325 *:* 2620 The f# code I used to test for open ports: open System.Net open System.Net.Sockets let ipAddress = IPAddress([| (byte)0; (byte)0; (byte)0; (byte)0 |]) let ipEndpoint portNumber = (IPEndPoint(ipAddress, portNumber), portNumber) let getPorts = seq { for i in 1 .. 65535 -> i } let checkIfPortAvailable (endpoint, portNumber) = use listener = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp) try listener.Bind(endpoint) (portNumber, true, null) with | ex -> (portNumber, false, ex) [<EntryPoint>] let main argv = getPorts |> Seq.map ipEndpoint |> Seq.map checkIfPortAvailable |> Seq.where (fun (_, works, _) -> not works) |> Seq.where (fun (_, _, ex) -> ex.Message.Contains("An attempt was made to access a socket in a way forbidden by its access permissions")) |> Seq.iteri (fun index (port, _, _) -> printfn "%5d: %d" index port) 0 and the output when executing the application (it was executed right after the netstat command): 0: 445 1: 5357 2: 7680 3: 49670 4: 49671 5: 49672 6: 49673 7: 49674 8: 49675 9: 49676 10: 49677 11: 49678 12: 49679 13: 49680 14: 49681 15: 49682 16: 49683 17: 49684 18: 49685 19: 49686 20: 49687 21: 49688 22: 49689 23: 49710 24: 49711 25: 49712 26: 49713 27: 49714 28: 49715 29: 49716 30: 49717 31: 49718 32: 49719 33: 49720 34: 49721 35: 49722 36: 49723 37: 49724 38: 49725 39: 49726 40: 49727 41: 49728 42: 49729 43: 49730 44: 49731 45: 49732 46: 49733 47: 49734 48: 49735 49: 49736 50: 49737 51: 49738 52: 49739 53: 49740 54: 49741 55: 49742 56: 49743 57: 49744 58: 49745 59: 49746 60: 49747 61: 49748 62: 49749 63: 49750 64: 49751 65: 49752 66: 49753 67: 49754 68: 49755 69: 49756 70: 49757 71: 49758 72: 49759 73: 49770 74: 49771 75: 49772 76: 49773 77: 49774 78: 49775 79: 49776 80: 49777 81: 49778 82: 49779 83: 49780 84: 49781 85: 49782 86: 49783 87: 49784 88: 49785 89: 49786 90: 49787 91: 49788 92: 49789 93: 49790 94: 49791 95: 49792 96: 49793 97: 49794 98: 49795 99: 49796 100: 49797 101: 49798 102: 49799 103: 49825 104: 49826 105: 49827 106: 49828 107: 49829 108: 49830 109: 49831 110: 49832 111: 49833 112: 49834 113: 49835 114: 49836 115: 49837 116: 49838 117: 49839 118: 49840 119: 49841 120: 49842 121: 49843 122: 49844 123: 49845 124: 49846 125: 49847 126: 49848 127: 49849 128: 49850 129: 49851 130: 49852 131: 49853 132: 49854 133: 49855 134: 49856 135: 49857 136: 49858 137: 49859 138: 49860 139: 49861 140: 49862 141: 49863 142: 49864 143: 49866 144: 49867 145: 49868 146: 49869 147: 49870 148: 49871 149: 49872 150: 49873 151: 49874 152: 49875 153: 49876 154: 49877 155: 49878 156: 49879 157: 49880 158: 49881 159: 49882 160: 49883 161: 49884 162: 49885 163: 50274 164: 50275 165: 50276 166: 50277 167: 50278 168: 50279 169: 50280 170: 50281 171: 50282 172: 50283 173: 50284 174: 50285 175: 50286 176: 50287 177: 50288 178: 50289 179: 50290 180: 50291 181: 50292 182: 50293 The port which I'd actually want to have opened is 49786 but the amount of ports reported with permission denied by my small testing algorithm, but not allocated when checking netstat is confusing me UPDATE 3: Now that simply running shutdown /s /f /t 0 doesn't work anymore, I've found another workaround which seems to be working fairly reliably in https://social.technet.microsoft.com/Forums/windows/en-US/e0cc1b3e-2c63-451a-abc8-8e1e66a23287/an-attempt-was-made-to-access-a-socket-in-a-way-forbidden-by-its-access-permissions?forum=w7itpronetworking - netsh int ip reset and restarting the computer (normal windows 10 restart is enough) and the port was consistently available on the next start so far (but it was just 3 tries) UPDATE 4: Summary of the comments: setting SO_REUSEADDR in the small f# script makes things only worse trying to close skype, VPN applications, dropbox and similar didn't have any effect (yes I actually made sure that the processes are terminated)
The reason is that Hyper-V takes over these ports, to prevent it from happening do the following: dism.exe /Online /Disable-Feature:Microsoft-Hyper-V (will have to restart) netsh int ipv4 add excludedportrange protocol=tcp startport=<your port> numberofports=1 dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All The original solution is here. If after that you still can't bind to the port do the following: netsh http add iplisten 0.0.0.0 for IPv4 netsh http add iplisten :: for IPv6 More information is here.
I also had the Hyper-v/WSL problem above, but found a simpler solution: I had stopped docker before doing this, not sure if it's necessary. Run as admin: net stop winnat net start winnat
A faulty Windows upgrade is the reason for the problems with reserved tcp ports. See https://github.com/docker/for-win/issues/3171#issuecomment-554587817 With this the problem should be fixed: netsh int ipv4 set dynamic tcp start=49152 num=16384 That would explain why a clean install fixes these type of problems.
If you face this issue on Win10 2004 that's because of of an issue in this update do the following netsh int ipv[46] set dynamic tcp start=49152 num=16384 reg add HKLM\SYSTEM\CurrentControlSet\Services\hns\State /v EnableExcludedPortRange /d 0 /f I face this on opening Jetbrains IDEs and and many other program that use sockets
In case someone lands up here after facing similar issues post updating Windows to May 2020 update which contains WSL2. In my case I also switched docker to WSL2 post which I started facing similar issues with some of my containers. Note: Run the following commands in powershell (Run as administrator) Disable Hyper-V. dism.exe /Online /Disable-Feature:Microsoft-Hyper-V Remove all hyper-v related network adapters. Get-HNSNetwork | Remove-HNSNetwork Reboot.
I am having a similar issue right now(August 2021) and this GitHub issue has some insight into the problem. It seems net stop winnat net start winnat Should fix the issue, you might need to start your application before restarting winnat
Expanding on the selected answer: if you have Hyper-V enabled, you can temporarily disable it during boot by using bcdedit: bcdedit /Set {current} hypervisorlaunchtype off Restart and exclude the necessary ports via: netsh int ipv4 add excludedportrange protocol=tcp startport=<your port> numberofports=1 Then simply re-enable Hyper-V, then restart: bcdedit /Set {current} hypervisorlaunchtype auto This prevents having to completely remove and re-add the Hyper-V feature, which requires several restarts.
When I looked for it, the explanation was An attempt was made to access a socket in a way forbidden by its access permissions. An example is using a broadcast address for sendto without broadcast permission being set using setsockopt(SO_BROADCAST). Another possible reason for the WSAEACCES error is that when the bind function is called (on Windows NT 4.0 with SP4 and later), another application, service, or kernel mode driver is bound to the same address with exclusive access. Such exclusive access is a new feature of Windows NT 4.0 with SP4 and later, and is implemented by using the SO_EXCLUSIVEADDRUSE option.
Find which process is listening on port 8001 on Mac OS X
How can I see which process is listening on port 8001 on Mac OS X? I have tried several commands: lsof -i | grep LISTEN Output: qbittorre 321 user 26u IPv4 0xc8e6037f28270c31 0t0 TCP *:6881 (LISTEN) qbittorre 321 user 27u IPv6 0xc8e6037f216348e1 0t0 TCP *:6881 (LISTEN) mysqld 14131 user 10u IPv4 0xc8e6037f3218da91 0t0 TCP *:mysql (LISTEN) httpd 14133 user 16u IPv6 0xc8e6037f216352e1 0t0 TCP *:http (LISTEN) httpd 14135 user 16u IPv6 0xc8e6037f216352e1 0t0 TCP *:http (LISTEN) httpd 14136 user 16u IPv6 0xc8e6037f216352e1 0t0 TCP *:http (LISTEN) httpd 14137 user 16u IPv6 0xc8e6037f216352e1 0t0 TCP *:http (LISTEN) httpd 14138 user 16u IPv6 0xc8e6037f216352e1 0t0 TCP *:http (LISTEN) httpd 14139 user 16u IPv6 0xc8e6037f216352e1 0t0 TCP *:http (LISTEN) httpd 14148 user 16u IPv6 0xc8e6037f216352e1 0t0 TCP *:http (LISTEN) httpd 14149 user 16u IPv6 0xc8e6037f216352e1 0t0 TCP *:http (LISTEN) httpd 14150 user 16u IPv6 0xc8e6037f216352e1 0t0 TCP *:http (LISTEN) Skype 14543 user 57u IPv4 0xc8e6037f324f9a91 0t0 TCP *:18666 (LISTEN) java 24640 user 68u IPv6 0xc8e6037f3295a3e1 0t0 TCP *:http-alt (LISTEN) java 24640 user 73u IPv6 0xc8e6037f32958fe1 0t0 TCP *:8009 (LISTEN) java 24640 user 101u IPv6 0xc8e6037f32959ee1 0t0 TCP localhost:8005 (LISTEN) lsof: sudo lsof -nPi -sTCP:LISTEN | grep 8001 Nothing found netstat: netstat -a | grep 8001 Nothing found I know that the port is in use by someone, because I am trying to change the Emacs simple-httpd default httpd-port from 8080 (default) to 8001, and it fails: Warning (initialization): An error occurred while loading `/Users/user/.emacs': File error: Cannot bind server socket, address already in use To ensure normal operation, you should investigate and remove the cause of the error in your initialization file. Start Emacs with the `--debug-init' option to view a complete error backtrace. How can I resolve it? I tried also to set the port to 8002, with the same problem and didn't find which process is listening on port 8002. What can be the source of the problem? Using nmap I discovered that port 8001 is used by vcom-tunnel service and it’s a closed port and that port 8002 is used by teradataordbms and is also closed. What are these services used for? Can I disable them and use their occupied ports?
You can use lsof to detect who is using the connection as long as there is active traffic on the connection. Here is a demonstration: setting a server on a given port fails with the error Address already in use lsof doesn't report any listener for that port Here is the shell log demonstrating this: python -m SimpleHTTPServer 3333 2>&1 | fgrep error Output: socket.error: [Errno 48] Address already in use sudo lsof -i TCP:3333 echo $? Output: 1 [1] : starting a web server on port 3333 fails with the error Address already in use [2] : lsof doesn't report port 3333 being used by anyone Let's generate traffic in order to force lsof to detect the usage of the port: in another terminal open a telnet connection: telnet localhost 3333 Now back on your previous terminal, you will see that lsof finds your port: sudo lsof -n -P -i :3333 Output: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME telnet 78142 loic 5u IPv4 0x3fa2e8474ece6129 0t0 TCP 127.0.0.1:51855->127.0.0.1:3333 (ESTABLISHED) There is traffic going on, but according to the OS, only one end of the connection is there, the initiator, there still isn’t any `LISTENER`! Note: in my case, OS is macOS v10.13.3 (High Sierra), but I had that with previous versions of macOS/OSX too
Port settings with Windows network related to receiving signal
I'm trying to run the same program on 2 laptops. One successfully ran the program but the other one could not. The following are the networks situation when I called the program. From the below messages, I guess that it may be because the system is using the port. The failed one cannot send anything from ports 2501 & 9301 while the successful one could do so (labelled with () & (*) below). Does anyone know how to resolve this problem? ["netstat -na" on successful running] Active Connections Proto Local Address Foreign Address State TCP 0.0.0.0:2501 0.0.0.0:0 LISTENING TCP 0.0.0.0:9301 0.0.0.0:0 LISTENING TCP 212.14.156.113:2501 14.0.202.5:13362 ESTABLISHED ----(*) TCP 212.14.156.113:9301 14.0.202.5:2725 ESTABLISHED ----(**) UDP 127.0.0.1:1900 *:* UDP 212.14.156.113:1900 *:* ["netstat -na" on failed running] Active Connections Proto Local Address Foreign Address State TCP 0.0.0.0:2521 0.0.0.0:0 LISTENING TCP 0.0.0.0:2523 0.0.0.0:0 LISTENING TCP 0.0.0.0:2525 0.0.0.0:0 LISTENING TCP 0.0.0.0:2527 0.0.0.0:0 LISTENING TCP 0.0.0.0:9301 0.0.0.0:0 LISTENING TCP 212.14.156.113:2512 173.252.122.23:443 ESTABLISHED UDP 127.0.0.1:1900 *:* UDP 127.0.0.1:52555 *:* UDP 212.14.156.113:1900 *:* UDP 212.14.156.113:52554 *:* UDP [::1]:1900 *:* ["netstat -a -b" on failed running] Active Connections Proto Local Address Foreign Address State TCP 0.0.0.0:2521 T61:0 LISTENING [Program.exe] TCP 0.0.0.0:2523 T61:0 LISTENING [Program.exe] TCP 0.0.0.0:2525 T61:0 LISTENING [Program.exe] TCP 0.0.0.0:2527 T61:0 LISTENING [Program.exe] TCP 0.0.0.0:9301 T61:0 LISTENING [Program.exe] UDP 127.0.0.1:52555 *:* SSDPSRV [svchost.exe] UDP 212.14.156.113:52554 *:* SSDPSRV [svchost.exe] UDP [::1]:1900 *:* SSDPSRV [svchost.exe]