Some users (generally a distance away from the server) when attempting to upload files larger than 2mb the server closes the connection. Smaller files upload fine.
Error as seen in the log (/var/log/proftpd/proftpd.log) for each attempt:

notice: user testuser: aborting transfer: Interrupted system call

The problem does not exist with the same configuration in version 1.3.5b-4.
Added configuration items from stock.
Various files in /etc/proftpd/conf.d/* containing

DefaultRoot /home/UserName/Website UserName
DeleteAbortedStores on
AllowStoreRestart on

and in proftpd.conf
RequireValidShell off
MasqueradeAddress insert.wan.ip.here

This is on an up to date 14/02/2019 buster installation
Seems to be the same problem as expressed here.
https://github.com/proftpd/proftpd/issues/668#issuecomment-357406734 (https://github.com/proftpd/proftpd/issues/668#issuecomment-357406734)

forwarded 922307 https://github.com/proftpd/proftpd/issues/668
stop

On 14.02.19 13:55, david@daveserver.info wrote:

Hi,
<snip>
Castaglia (the upstream author of proftp) asked about a year ago for a
Debug Log from the Client side, but nobody considered to provide one. So
I don't see a chance to make progress here. Are you willing to provide
one and post it on github?

I'm marking this bug as known in upstream for now.

Hilmar

On 2/14/19 1:55 PM, david@daveserver.info wrote:

Hi,

I've uploaded 1.3.6a to unstable. It contains a fix:

- Bug 4319 - FTP uploads frequently break due to "Interrupted system
call" error.

Does the new version solve your issue?

Hilmar

On Mon, 14 Oct 2019 23:13:09 +0200 Hilmar Preuße <hille42@web.de> wrote:
 > On 2/14/19 1:55 PM, david@daveserver.info wrote:
 >
 > Hi,
 >
 > I've uploaded 1.3.6a to unstable. It contains a fix:
 >
 > - Bug 4319 - FTP uploads frequently break due to "Interrupted system
 > call" error.
 >
 > Does the new version solve your issue?
 >
 > Hilmar
 >
 > --
 > sigfault
 > #206401 http://counter.li.org

Dear Maintainer,

we have recently received reports of customers having issues when
uploading many HTML files at once (429 items, totaling 3,1 MiB). We can
reproduce this issue with FTPES (explicit TLS) on both Ubuntu 19.10 with
FileZilla 3.39.0 and on Windows 10 using WinSCP. On the client side
(FileZilla) an aborted file transfer is logged as follows:

   Command:    STOR w00017.htm
   Response:    150 Opening ASCII mode data connection for w00017.htm
   Response:    450 Transfer aborted. Link to file server lost
   Error:    File transfer failed
   Status:    Starting upload of
/home/kab/Desktop/Vertretungsplan/S-stat/52/w/w00017.htm
   Status:    Retrieving directory listing of
"/home/kim.brodowski/Vertretungsplan/S-stat/52/w"...
   Status:    File transfer successful, transferred 2.1 KB in 1 second

On the server side in proftpd.log we essentially receive the same error:

   2020-02-05 13:14:18,605 iserv.kim.mein-iserv.de proftpd[10571]
iserv.kim.mein-iserv.de
(2003:a:422:3ba0:34c8:a6df:1a03:f976[2003:a:422:3ba0:34c8:a6df:1a03:f976]):
notice: user kim.brodowski: aborting transfer: Link to file server lost

In tls.log I don't see any lines that appear to be of interest at first
glance, even with verbose logging enabled.

Disabling TLS results in the file transfer proceeding as expected, but
of course is unsuitable for transfers over the internet.

We're currently running proftpd-basic and proftpd-mod-pgsql version
1.3.6-4+deb10u3 (stable/Buster). As you have suggested that a newer
upstream version might resolve the issue I've also backported both
packages from Bullseye in version 1.3.6b-3. This does not appear to have
any effect.