you can’t use starttls on port 465. When this port is used, it’s with direct TLS. Starttls is used on port 587. With Gmail, I use port 587 with starttls (I think that 465 can be used but without starttls - did not check recently).
For the more efficient debugging of mail sending issues with Duplicati, exporting the job as command line and pasting the result in a OS command window has always served me better than running the job in the UI.
Please add to the pasted command in an OS command window the parameter --log-level=profiling and post the result with sufficient lines before the error message to understand when it happens.
seems this kind of error is triggered by a timeout. Beats me why Gmail should timeout on you for a rather small Smtp send. You don’t have a firewall between your computer and Internet by any chance ? If it’s the case, maybe configuring it to disable TLS packet inspection could help.
If not, maybe try to update Mono.
Yeah, as mentioned smtp notifications work fine via OMV as well as doing a test message with the CLI. No firewall, I have updated Mono using its Debian repository.
I’m pretty baffled lol.
Maybe it’s to do with Duplicati not finalising the body, hence causing the timeout?
Is this a retype or a copy-and-paste from three dot menu’s Edit as text? Use double dashes.
Copying and pasting with three backquotes above and below makes the dash uses easy to see.
Apparently (at least here) the forum software displayed only original double-dashed lines in blue.
Actually, the forum software might also be doing dash conversions, but I don’t know why they vary.
Regardless, the most puzzling thing to me is the difference between CLI (works) and GUI (errors).
Maybe you can try a tiny local backup job mainly for the purpose of GUI Commandline test such as The SEND-MAIL command (don’t even need to actually run backup, which removes that variable).
EDIT 2:
This also allows a simpler configuration. I’m just using below options and letting code pick the rest.
My current test has --send-mail-url=smtp://smtp.gmail.com:587/?starttls=always and works in GUI.
You also get the transcript of the session right on the screen without having to set up a profiling log.
EDIT 3:
Hovering over the blue lines show that something decided they’re mailto links, maybe due to the @.
I will add that with the docker Instances, I just tried one file and still encountered the issue. Running the exact same backup task via the CLI @ts678 will still encounter the error, with the message “Operating on non-blocking socket would block”
As mentioned, sending a test email via the cli works fine. It seems to only occur when performing the backup task.
I think we’re narrowing down the problem. By not putting in %RESULT% in the --send-mail-body line, the operation completes and emails successfully without error.
As soon as I add %RESULT% into it whatsoever, the command timeouts and produces “Operation on non-blocking socket would block”
Having only small packets going through sure rings a bell in my memory. MTU, MSS… wonder why it would quick (!) only for this particular connection. Anyway, it’s no great problem to do a quick test. Usually people considering Docker are using some Unixy system so I’d assume that
ip link set dev eth0 mtu 1300
(replacing eth0 by the appropriate interface if necessary) could be a way to test it. I’d let you search the way to do it if you are in fact using Windows.
Odd. That’s documented as the default body. Does it work if you just leave it at that default?
I don’t know if there’s something special in your --send-mail-body line that’s causing this.
You have control of the text. To see what’s in %RESULT% you might be able to run a script.
