Xavron
commented
6 months ago This will indeed have some user side oddities that users will have to deal with. FileZilla, for instance, will do a 2 count hit (browsing and transfers are two separate logins). The limit will have to be adjusted accordingly or client(s) will see problems. Different clients could potentiality do other things.
So, if you try to limit strict, its not really going to be so. If one FileZilla client connects and another tries before an expected transfer then there's a race between clients on a too close limit (like a limit of 2 or even 3 in this case) then problems will happen. For these two clients, the limit would have to be 4 or more. And of course, a limit of 2 being required for one instance of FileZilla, could see another client creating havoc :)
FileZilla will also not clear 2 connections within itself on its disconnect. Connect another client, simply connect again, and too many users. Exit FileZilla and connect again and it connects (but would still fail to transfer with a limit of 2 anyway since another client is connected which would also fail to transfer).
So, best to set a loose higher limit value at eg 2x the clients to connect as a minimum. Eg 5 possible clients would need a minimum of 10 for the limit. Whereas 1 would need a minimum limit of 2.
Seems some ftp servers do limit per IP https://stackoverflow.com/questions/30797269/too-many-ftp-connections-cant-accept-more/45131091#45131091 but I'm not going to do that and will keep it simple and not micro manage into other variations of problems. It can always be done in the future by someone if desired.
ppareit
Since there is a feature to create users and set chroot for each, maybe the same option to limit anonymous users (they are already read-only, which is good)