SFTPGo or MiroTalk SFU not starting because they use ephemeral ports

[imc67]

BTW: I also restarted Docker via the GUI but it also didn't solved it.

[imc67]

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.

[james]

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 lingering sftp connection since SFTP uses SSH as the binding agent.
If you can find out what or who 2a03:REDACTED:61f0 and 2a01:REDACTED::2 is you might find the device that had the connection still open.

[imc67]

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)

[imc67]

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

[girish]

@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]

@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]

@girish and @James I just updated SFTPGo to 1.1.0, don't see differences, portrange is still 41000 but I also can't change it to ie. 70000, the field becomes RED.

EDIT: I can change it to 61000

[girish]

@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]

@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?

[robi]

Can you also shrink the ephemeral port range to something tighter @girish ?

[girish]

@robi I think the port range comes part of linux/ubuntu setup . I also don't completely know the side effects of making it tighter.

[robi]

@girish "32768-60999 range" is not the entire valid range for linux, so I would guess it was a configuration default instead.

Hence the tightening request.

[joseph]

FWIW, I can confirm that on Hetzner/Ubuntu this is the default range.