SFTPGo or MiroTalk SFU not starting because they use ephemeral ports
-
Hello @imc67
The issue why your SFTPGo is not starting is because0.0.0.0:41090: bind: address already in use
.
I highly suspect this is just temporary and if you stop the app for 2–5 minutes and then start the app again, this will resolve itself.You can also run the following on your root:
lsof -i :41090 -S
to see if really anything is using that port.
-
Hello @imc67
The issue why your SFTPGo is not starting is because0.0.0.0:41090: bind: address already in use
.
I highly suspect this is just temporary and if you stop the app for 2–5 minutes and then start the app again, this will resolve itself.You can also run the following on your root:
lsof -i :41090 -S
to see if really anything is using that port.
@james said in Server security update reboot: SFTPGo doesn't start:
You can also run the following on your root:
lsof -i :41090 -S
to see if really anything is using that port.yes:
~# lsof -i :41090 -S COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME ssh 940 root 3u IPv6 25971 0t0 TCP [2a03:****:5f:dc5:48ba:****:fe45:61f0]:41090->[2a01:4f8:****:1635::2]:telnet (ESTABLISHED)
What could it be? I already stopped MiroTalk and Nextcloud
-
BTW: I also restarted Docker via the GUI but it also didn't solved it.
-
Thanks to ChatGPT I could solve it:
"Something" outside Docker was claiming this port
sudo kill 940
Killed this connection, now the restore worked and the app started.
-
This might have been a lingering connection from one of your IoT devices.
ssh 940 root 3u IPv6 25971 0t0 TCP [2a03:REDACTED:61f0]:41090->[2a01:REDACTED::2]:telnet (ESTABLISHED)
The program used was
ssh
so I assume a lingeringsftp
connection since SFTP uses SSH as the binding agent.
If you can find out what or who2a03:REDACTED:61f0
and2a01:REDACTED::2
is you might find the device that had the connection still open. -
Thanks for the hint, I investigated further:
The left IPv6 is my Cloudron server, from there is had an active connection (ssh outside of Docker) to the right IPv6 my storage box!I only use 1 Volume to a Storagebox and 1 Backup location. Could it be that one of those 2 uses the same port-range (41000+100)? @girish
BTW: @James please redact my ip's in your message (I just corrected mine)
-
I imc67 marked this topic as a question
-
-
Thanks for the hint, I investigated further:
The left IPv6 is my Cloudron server, from there is had an active connection (ssh outside of Docker) to the right IPv6 my storage box!I only use 1 Volume to a Storagebox and 1 Backup location. Could it be that one of those 2 uses the same port-range (41000+100)? @girish
BTW: @James please redact my ip's in your message (I just corrected mine)
said in Server security update reboot: SFTPGo doesn't start:
Thanks for the hint, I investigated further:
The left IPv6 is my Cloudron server, from there is had an active connection (ssh outside of Docker) to the right IPv6 my storage box!I only use 1 Volume to a Storagebox and 1 Backup location. Could it be that one of those 2 uses the same port-range (41000+100)? @girish
BTW: @James please redact my ip's in your message (I just corrected mine)
@girish is this a bug? There are more topics with the same kind of error message
-
@imc67 some blind guess here. I think what's happening is that something in box side (maybe backups code) is occupying that port 41000. This is in turn blocking the containers from using that port.
Digging deeper, this seems possible. The ephemeral port range is
$ cat /proc/sys/net/ipv4/ip_local_port_range 32768 60999
So, 40000 is not a good choice for a container to listen to. @imc67 a quick fix for you is to change sftpgo to use some other port which is outside the 32768-60999 range. In the meantime, I will fix the package to default to some port range outside the ephemeral port range.
I think it would be nice to also warn people when try to run containers in ephemeral port ranges. I will put a note in the docs for a start. @james what do you think?
-
@imc67 some blind guess here. I think what's happening is that something in box side (maybe backups code) is occupying that port 41000. This is in turn blocking the containers from using that port.
Digging deeper, this seems possible. The ephemeral port range is
$ cat /proc/sys/net/ipv4/ip_local_port_range 32768 60999
So, 40000 is not a good choice for a container to listen to. @imc67 a quick fix for you is to change sftpgo to use some other port which is outside the 32768-60999 range. In the meantime, I will fix the package to default to some port range outside the ephemeral port range.
I think it would be nice to also warn people when try to run containers in ephemeral port ranges. I will put a note in the docs for a start. @james what do you think?
@girish good founds! It's also the same issue with MiroTalk (what I know of and experienced) but maybe more apps?
https://forum.cloudron.io/search?term=bind%3A address already in use&in=titlesposts
-
@imc67 max port is 65535 so it can't be 70000 . A package cannot change the port ranges (just like it cannot change the installated domain names) . But for new installation, it will recommend 20000 instead . I have also fixed up the sfu package, will be published shortly .
-
@imc67 max port is 65535 so it can't be 70000 . A package cannot change the port ranges (just like it cannot change the installated domain names) . But for new installation, it will recommend 20000 instead . I have also fixed up the sfu package, will be published shortly .
@girish said in Server security update reboot: SFTPGo doesn't start:
A package cannot change the port ranges (just like it cannot change the installated domain names) . But for new installation, it will recommend 20000 instead
Maybe you can explicitly mention in the update notes the default / advised ports? Existing installs will not be moved to the "new" ports and thus keep having issues?