a clear and technical explanation with regards to the multiple concurrent FTP sessions issue when locking the data port to only one port is what I am most interested in knowing in depth. When can it work, when will it not work, why it may not be recommended, etc.
This will be a wild guess, as I haven't tested it, you should try it for yourself and see if there are some other problems I might have missed.
I suppose you could limit the passive port range to one single port. In fact you can see in this question that small port ranges are used in practice. Theoretically, to support multiple concurrent connections you only need the 4 values: local IP, local port, remote IP, remote port to be unique. This is how you discern between different connections.
If you lock down the port on your server to one single value, then the only variable left is the port used by the client. This is not a problem, as long as the client has a large enough pool of free ephemeral ports to choose from. Unless it's doing some heavy NAT, you don't have to worry about this. Now, be warned this will be purely theoretical stuff: if you used multiple ports on your server, you could multiply the number of hypothetical concurrent connections by enabling number of ports in range connections per one port client-side. But it won't happen in practice, as I doubt there's any implementation of an FTP client that would support this (because it doesn't make much sense). Plus if the client has to share his ephemeral ports in this way and can't just open a new one, then he has much more severe problems to deal with. So, from this perspective you should be totally safe using a single port.
Let's think why a single port may not be sufficient.
First of all, I could come up with a situation where a really buggy FTP server implementation uses solely the local port number as a way to identify the client data transfer. Once again, I don't think any decent FTPd would do that.
The real problem (yes, you can disregard all above as a major digression ;-)) is that passive port range is in a non-privileged range.
This means that your selected port number is not reserved per se, and in fact any user process (doesn't need root privileges) can grab it before your FTP server does. If you have an abundant pool of ports to select from, you just grab a random free one. If you're bound to use the only one and it's already used, you won't be able to handle the transfers properly.
Sorry, if the answer seems a bit too speculative. To be honest, I tried hard to find a reason why you shouldn't use a single port and, apart from the last bit, I couldn't think of any hard evidence against it. Nevertheless, an interesting and challenging question you pose.
For my case I had to explicit remove and install again pure-ftpd via apt:
systemctl stop pure-ftpd
apt remove pure-ftpd
apt install pure-ftpd
systemctl start pure-ftpd
Or if you need to use pure-ftpd-mysql instead:
systemctl stop pure-ftpd-mysql
apt remove pure-ftpd-mysql
apt install pure-ftpd-mysql
systemctl start pure-ftpd-mysql
Best Answer
In active mode the server initiates a connection to a client defined ip address, so the server has no way of affecting the port number being used. In this case you don't need to open other incoming ports than 21 because the server initiates the data connection towards the client.
In passive mode the client opens a connection to a server defined port, and that's the spot where passive port range comes into play. Server chooses a free port within the range and hands it to the client. This of course means that the entire port range needs to be open in the server firewall, which has security implications.
Linux has a neat feature to mitigate the effects of opening a large port range for passive FTP - iptables connection tracking. To take advantage of it, you need to make sure ip_conntrack_ftp module is loaded, and then you can permit traffic like this
# iptables -A your_chain -i your_iface -m state --state RELATED -m helper --helper ftp -j ACCEPT(you could include your port range if necessary). That tells iptables to accept related connections managed by conntrack FTP helper. So, if any other service would be listening on a socket in your passive port range, iptables would deny access to the port because it cannot recognize it being FTP related.