I tried to repro this and did not (client Linux / server Linux, both Ubuntu with default ssh/sftp server, filled to the brim by hand).
I got a failed transfer. It was not the ssh timeout (I set it to 5 minutes and it failed well before that). Also, I have set retries to 0 so no long retries, so it failed quite fast, less than one minute. Thanks to the new code, the job failure is reported, the detailed reporting is not very informative though:
[Error-Duplicati.Library.Main.Operation.BackupHandler-FatalError]: Fatal error
SshConnectionException: An established connection was aborted by the server.
I tried to update SSHNET to the last version and sadly the error reporting is no better. It is probably a SSH problem though; trying to do a manual put with Linux sftp gives:
Couldn’t write to remote file “/fichiers/myfile.txt”: Failure
Not informative at all.
The server (SSH) is at fault. It returns status 4 (Failure) and not 14 (NO_SPACE_ON_FILESYSTEM)
SSHNet can handle the error code but it’s not reported by the server correctly.
Edit: looking at sftp.h in the openssh repo (for example GitHub - openssh/openssh-portable: Portable OpenSSH, but in the openbsd source it’s the same), the error ‘disk full’ does NOT exist. It’s not an Ubuntu old version problem, it’s the original developers who did not see any interest in reporting this kind of problem.
Let’s see: filezillaserver does not support sftp. Proftpd does and uses this 14 error code. Too late today to test if it works correctly with Duplicati, but Proftpd seems to live up to its ‘Pro’ in the name at least.