Ubiquiti UniFi Controller issue "port being used"

Hey all, I’m a little lost at this point. I can’t seem to get the UniFi Network Server software/controller to work. I keep getting “Port 8080 is used by other programs”.

Here is what I’ve done so far;

Fresh OS install (Win 11 Pro) with just the UniFi Network software and either Java 8 64bit or
Java 21 64bit installed only.

I disabled all windows firewalls (Domain, Private, and Public)

Network sharing is on for Private, Public, and All Networks

Changing the port # from 8080 to 8081, etc, port being used would just switch to 8081, etc.

PC is directly connected to cable modem

I’ll attach my untouched system.properties and netstat info below:
C:\Windows\System32>netstat -aon | findstr 8080
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 7288
TCP [::]:8080 [::]:0 LISTENING 7288

C:\Windows\System32>tasklist | findstr 7288
java.exe 7288 Console 1 411,068 K

C:\Windows\System32>netstat -aon | findstr 7288
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 7288
TCP 0.0.0.0:8443 0.0.0.0:0 LISTENING 7288
TCP 0.0.0.0:8843 0.0.0.0:0 LISTENING 7288
TCP 0.0.0.0:8880 0.0.0.0:0 LISTENING 7288
TCP [::]:8080 [::]:0 LISTENING 7288
TCP [::]:8443 [::]:0 LISTENING 7288
TCP [::]:8843 [::]:0 LISTENING 7288
TCP [::]:8880 [::]:0 LISTENING 7288

C:\Windows\System32>

system.properties

each unifi instance requires a set of ports:

device inform

unifi.http.port=8080

controller UI / API

unifi.https.port=8443

portal redirect port for HTTP

portal.http.port=8880

portal redirect port for HTTPs

portal.https.port=8843

local-bound port for DB server

unifi.db.port=27117

UDP port used for STUN

unifi.stun.port=3478

the IP devices should be talking to for inform

system_ip=a.b.c.d

disable mongodb journaling

unifi.db.nojournal=false

extra mongod args

unifi.db.extraargs

HTTPS options

unifi.https.ciphers=TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA

unifi.https.sslEnabledProtocols=TLSv1,SSLv2Hello

unifi.https.hsts=false

unifi.https.hsts.max_age=31536000

unifi.https.hsts.preload=false

unifi.https.hsts.subdomain=false

Ports reserved for device redirector. There is no need to open

firewall for these ports on controller, however do NOT set

controller to use these ports.

portal.redirector.port=8881

portal.redirector.port.wired=8882

Port used for throughput measurement.

unifi.throughput.port=6789

#Sun Jan 21 12:31:23 EST 2024
reporter-uuid=43f42bb5-e693-4e5b-a0fc-52405f7f3f25
debug.device=warn
debug.mgmt=warn
debug.setting_preference=auto
uuid=3d0f2df0-b34d-4a82-b24c-f105bfc55cc8
debug.system=warn
debug.sdn=warn

Any help you all could offer would be greatly appreciated. I installed the controller software on 2 other PC’s on the same network that had Win 10 Pro and they installed and ran just fine.


There is one thing about Task Manager. If you see blank PIDs at the top with children hidden/available, any PIDs that you see when expanding those will not show up below in the visible PIDs. So 7288 might be hidden under a process at the top of the list.

“Port 8080 is used by other programs”

C:\Windows\System32>netstat -aon | findstr 8080
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 7288
TCP [::]:8080 [::]:0 LISTENING 7288
C:\Windows\System32>tasklist | findstr 7288
java.exe 7288 Console 1 411,068 K
C:\Windows\System32>netstat -aon | findstr 7288
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 7288
TCP 0.0.0.0:8443 0.0.0.0:0 LISTENING 7288
TCP 0.0.0.0:8843 0.0.0.0:0 LISTENING 7288
TCP 0.0.0.0:8880 0.0.0.0:0 LISTENING 7288
TCP [::]:8080 [::]:0 LISTENING 7288
TCP [::]:8443 [::]:0 LISTENING 7288
TCP [::]:8843 [::]:0 LISTENING 7288
TCP [::]:8880 [::]:0 LISTENING 7288

Its pretty obvious something is tunning and hogging the reuired 8080. That system inst clean as you think.

Identifiy the process and kill it, pretty much everything else is superfluous at this point.

To get port → PID

netstat -ano -p tcp

To find what that PID actually is

ps
get-process

2 Likes

Hey all, I ran the netstat -ano -p tcp and I got the following

Active Connections

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1480
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING 7536
TCP 0.0.0.0:7680 0.0.0.0:0 LISTENING 6836
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 4944
TCP 0.0.0.0:8443 0.0.0.0:0 LISTENING 4944
TCP 0.0.0.0:8843 0.0.0.0:0 LISTENING 4944
TCP 0.0.0.0:8880 0.0.0.0:0 LISTENING 4944
TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING 1104
TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING 8
TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING 2972
TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING 2908
TCP 0.0.0.0:49668 0.0.0.0:0 LISTENING 3832
TCP 0.0.0.0:49670 0.0.0.0:0 LISTENING 1072
TCP 0.0.0.0:49671 0.0.0.0:0 LISTENING 4592
TCP 127.0.0.1:49675 127.0.0.1:49676 ESTABLISHED 1388
TCP 127.0.0.1:49676 127.0.0.1:49675 ESTABLISHED 1388
TCP 192.168.0.159:139 0.0.0.0:0 LISTENING 4
TCP 192.168.0.159:49408 52.159.127.243:443 ESTABLISHED 4192
TCP 192.168.0.159:52246 20.50.73.13:443 TIME_WAIT 0
TCP 192.168.0.159:52247 23.200.156.204:80 TIME_WAIT 0
TCP 192.168.0.159:52248 52.184.216.226:443 FIN_WAIT_1 6836
TCP 192.168.0.159:52249 52.242.99.254:443 FIN_WAIT_1 6836
TCP 192.168.0.159:52250 13.68.233.9:443 FIN_WAIT_1 6764
TCP 192.168.0.159:52251 52.138.124.216:443 FIN_WAIT_1 7536
TCP 192.168.0.159:52252 142.250.65.227:443 TIME_WAIT 0
TCP 192.168.0.159:52257 52.184.216.226:443 ESTABLISHED 6836
TCP 192.168.0.159:52258 52.184.216.226:443 ESTABLISHED 6836
TCP 192.168.0.159:52259 52.138.124.216:443 ESTABLISHED 7536
TCP 192.168.0.159:52260 52.179.219.14:443 ESTABLISHED 6836
TCP 192.168.0.159:52279 13.107.21.200:443 ESTABLISHED 6460
TCP 192.168.0.159:52280 23.213.53.27:443 CLOSE_WAIT 6460
TCP 192.168.0.159:52281 23.213.53.27:443 ESTABLISHED 6460
TCP 192.168.0.159:52282 23.213.53.27:443 CLOSE_WAIT 6460
TCP 192.168.0.159:52287 52.109.4.22:443 ESTABLISHED 8076
TCP 192.168.0.159:52288 52.96.35.178:443 ESTABLISHED 6460
TCP 192.168.0.159:52289 52.96.35.178:443 ESTABLISHED 6460
TCP 192.168.0.159:52294 13.107.18.254:443 ESTABLISHED 6460
TCP 192.168.0.159:52295 72.21.81.200:443 ESTABLISHED 6460
TCP 192.168.0.159:52296 51.104.34.11:443 ESTABLISHED 6460
TCP 192.168.0.159:52300 204.79.197.222:443 ESTABLISHED 6460
TCP 192.168.0.159:52301 23.33.85.206:443 ESTABLISHED 6520
TCP 192.168.0.159:52302 23.62.33.22:443 ESTABLISHED 8224
TCP 192.168.0.159:52303 204.79.197.203:443 TIME_WAIT 0
TCP 192.168.0.159:52307 204.79.197.203:443 ESTABLISHED 8224
TCP 192.168.0.159:52313 204.79.197.200:443 TIME_WAIT 0
TCP 192.168.0.159:52314 20.190.161.152:443 TIME_WAIT 0

I ran the following and got
C:\Windows\System32>tasklist | findstr 4944
java.exe 4944 Console 1 278,588 K

So it seems that Java.exe is listening for port 8080…

Pretty sure unifi runs on Java so perhaps you’re running two instances somehow?

3 Likes

Update, I got it working, apparently with all the windows reinstalls I hadn’t installed the Intel chipset drivers. I don’t know exactly which one was the fix but using their “check your installed devices and update” tool fixed the problem. On a side note I had no version of Java installed so any java files that are needed are installed by the Unifi Server Software. Thanks to all of you for your help.

This was a Win 11Pro install

1 Like

I got it working, apparently with all the windows reinstalls I hadn’t installed the Intel chipset drivers

You got it working, but it doesnt have anything to do with drivers. You probably reinstalled pc during updates and whatever that was running did not start after reboot, allowing unifi controller to finalling bind port 8080.

Just chiming in so some poor future shmuck does not try installing chipset drivers to fix unrelated issues.

Maybe? It finally worked for me. I did 5 OS reinstalls, sometimes I installed Java first, other times the Unifi software first and always got the 8080 error. The only thing I did differently the last time was to install the chipset drivers prior to installing any other software. I’m not saying that this is “the fix” for someone having a port 8080 is being used error as it could be another issue related to that system but it can’t hurt to have updated chipset drivers regardless.

Chipset cannot have any effect on problem you were experiencing, you run into service management problem.

  • software requires to bind specific port to operate FACT
  • port binding is exclusive in nature FACT
  • port is not used by default on fresh system installation FACT
  • yet it was used by something when you tried to start controller OBSERVATION

=> there was a service running that used the port in question. That service was created directly or indirectly by user action.

Remediation always is →

  • what is using the port now?
  • and why is it running without me knowing ?
    • did I forget setting service up?
    • did service set itself up for autostart without me noticing?
    • other error
  • apply fixes and document how that happened, once reason is understood

By wiping the slate clean each time, you did not find out “why”, but you fixed it by chance in last attempt, alongside installing chipset drivers.

This exact scenario is junior sysadmin learning opportunity.

On a Windows 10 machine I solved the problem.

This command showed me that port 8080 was being used and provided a corresponding PID:

cmd
netstat -ano -p tcp

To see what is using that PID, one should open Task Manager, click the Processes tab, then More Details and then click the PID column. If you don’t see the PID column, right click and choose it.

The PID in my case corresponded to a file named AgentService.exe. I Googled that file name and found it was associated with the Minitools program, Shadowmaker (for partition managing) which I had installed recently. I uninstalled the program and then could get the Unifi Network Server program running.