Help with SMTP gmail issues (TLS and STARTLSS timeout)

Howdy everyone!

I’m honestly just tearing my hair out with these emailing issues; any advice or insight would be immensely appreciated.

I’m using OMV 6 as the host, using the .deb duplicati file for installation, which can send emails fine using the cli using the following config:

However, when configuring backups using the Webgui and setting up the smtp service using starttls, I get the following error messages:

When trying via TLS (which also works via the CLI) I get a different error message:

Could it be something to do with the content of the email that’s being pushed through?

I’m using app passwords btw (also removed personal email address and smtp server)

If anybody has any advice, I would be sincerely grateful. :cry:


The config for the mail service in the webgui:


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.

Hi @gpatel-fr

Appreciate the response.

Forgot to mention that when I do attempt starttls I change the port to 587 respectively.


I decided to run the backup as a command via the CLI, and it presented this error below:

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.

1 Like

Thanks @gpatel-fr,

Here’s the log below and when the lines before it errors out:

Appreciate your help

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.

Hi @gpatel-fr,

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?

I may try the docker container to see If I get better success

Make sure you also remove data of The AUTH Command.

1 Like


Appreciate that

So, a more confusing update.

I tried the docker variant with a different backup config, different host, and different google smtp account, and still get the same timeout.

Maybe try to resend test mail with command line, but adding a bigger mail body with send-mail-body like:

mono /usr/lib/duplicati/Duplicati.CommandLine.exe send-mail  --send-mail-url="smtps://" --send-mail-username="hax0r" --send-mail-password="hax0r" --send-mail-to="" --send-mail-subject="Duplicati report for backup" --send-mail-from=no-reply --send-mail-body="/home/myuser/myfile.txt"

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).


This also allows a simpler configuration. I’m just using below options and letting code pick the rest.

--send-mail-url --send-mail-username --send-mail-password --send-mail-to

My current test has --send-mail-url=smtp:// and works in GUI.
You also get the transcript of the session right on the screen without having to set up a profiling log.


Hovering over the blue lines show that something decided they’re mailto links, maybe due to the @.

Thanks @ts678 and @gpatel-fr

I’ll try those suggestions shortly.

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.

@gpatel-fr and @ts678

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”

%PARSEDRESULT% and the others work fine.

What an interesting problem.


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.