Log not being emailed when run unattended

[otronics]

Hi.

I am using SyncBackFree on various workstations.

On one machine, the log isn't being emailed after the profile is run unattended.

Settings are correct and the same as the other workstations.

However, testing the settings works (a test email sends fine) and when the profile is run manually, the email sends.

Any ideas?

Oliver.

[cliffhanger]

By "run unattended", do you mean "Run (Unattended)" as per right-click profile > context menu (alt. same option in Task menu with profile selected)?

Or, do you mean "Scheduled"?

If you mean the latter, have you tried the former (if not, try it & report back)?

Reason I ask is that you say "manually" works / "run unattended" does not - but you can 'Run (Unattended)' manually...

[otronics]

Thanks for the reply.

I have tested again.

It does not work when 'Run (Unattended)' is clicked.

It doesn't work when it is run on a schedule either.

Using the test email settings button does send a test email though.

[cliffhanger]

...when the profile is run manually, the email sends...

When you run the profile manually (not 'unattended'), are you prompted for the (email) password?

Conversely, when it apparently does not send the log ('run unattended' or 'scheduled'), is there any error message in the Result column afterwards? (You may need to drag the Result column wider to see the full contents)

[otronics]

Running the profile manually - it does not ask for a password.

No error in the 'Result' column. It says 'success'.

To clarify as well - it's not just the log that isn't sending - the email isn't being sent at all.

Thanks.

[cliffhanger]

Sorry, I'm out of ideas, unless there is some AV (or similar) on that machine which is silently trashing any attempt by an 'unauthorized' application (SB) to send emails the AV thinks may be spam. But, although I can think of a reason why this might happen only on a Scheduled run (the security context being more restricted as a 'batch job'...) I cannot see why you would also have a problem on a manual Run Unattended,because your security context is then exactly the same as the context of a manual Run (attended) - which you say works OK.

The only other thing I can say is that it more or less has to be something that is different on that problem PC (compared to the others), but what it might be, I can't tell from here. If I think of anything else, I'll post back, but for now I'm baffled.

[cliffhanger]

BTW re

To clarify as well - it's not just the log that isn't sending - the email isn't being sent at all.

I assumed that was the case from the outset

[otronics]

Some progress.

I have created a new profile which syncs just two folders.

I have run this several times (manually, scheduled etc) and the log emails fine.

[otronics]

I've done this just as a test.

Maybe something was wrong with the initial profile and maybe it was partially corrupt or something.

I've copied it to a new profile and I am testing as we speak.

[otronics]

I think it's something to do with the size of the email being sent (ie/ the size of the log files).

Smaller size log files work OK, large ones do not appear to send.

I'm not sure why though.

I've disabled anti-virus and even the firewall to test this and it still doesn't work.

Will try a different SMTP server to see if that makes any difference.

[cliffhanger]

Hi, it could be that the log for an Unattended (or Scheduled) 'live' run (that copies a normal workload, so log is larger) gets the problem, but manual/Attended test run soon afterwards (when you notice the missing email) finds less/nil to copy so the attachment to the email is much smaller and transmission succeeds.

It is not unknown for a mail server/service to silently discard a message with an attachment that exceeds some maximum size without returning an error to the sending client (SB in this case). Had there been an error message, SB would have quoted it in the Result column (SB has everything to gain by revealing the source of the problem - avoiding being blamed for not trying, for one thing). But if the mail server effectively lies by accepting the message without returning an error (then junks the message), not a lot SB can do. It may be a philosophy that anything above a certain size is spam, but returning an error would confirm the address is 'live'.

The Pro/SE/Lite models have an option to compress the attached log (also other options to potentially reduce the number of log entries in the first place), which may help, but these are not supported in SyncBackFree. You can install any copy of a commercial version (in parallel with Free if you want) for 30 days to test if it would help. Or maybe you can indeed successfully use a different mail server. Good luck!

[otronics]

This is an email service provider issue (I am 99%) sure.

More here if you are interested:

https://community.virginmedia.com/t5/Em ... se#M151418

For some reason, some of the log files do not send, even when I attach them manually!

Strange, as it used to work, and still does on my other computer.

[otronics]

Hello.

I'm still having issues with this - it is an ISP problem filtering out the emails of which I have no control.

They say that if I can provide a header for the affected email, they can tweak the filter and it should work.

I of course can't provide them with an example email as it doesn't work!

Any idea how I can achieve this?

The 'test email settings' won't help here. This feature works - it's something in the log file during an actual profile run that my ISP doesn't like.

[Swapna]

Hi,

Please submit a support zip (with debug logs) of your profile run to [email protected] for investigation.

Full instructions for creating and submitting the support zip are given here:

http://support.2brightsparks.com/knowle ... ation-file

If your Zip is over 30MB, contact us for alternate instructions, advising the actual size. Do not try to attach to the ticket!

Do not post (nor links to) Support Zips on this open forum.

Thank you.

[otronics]

This is 100% an ISP issue but I have emailed support to see if they can spot anything.

Thanks.