I’m currently running 126.96.36.199_beta_2023-05-25 and just now received the report, that one of my backups failed.
It’s a backup of a local directory to Mega (with the “new” MFA option set). On Friday (2 days ago) it worked without a problem, now it doesn’t.
Just a few minutes ago I received the error message “At least one error has occurred.” Unfortunately, there is no entry in the log for the backup-attempt at all.
I created a third backup to the same mega and it works without a problem.
I tried to verify files, repairing the database, recreating the database and all of them ran without any errors.
I tested around quite a lot and the problem seems to be linked to 3 video files. Without them in the source, the backup works. The files are 423MB, 353MB and 387MB of size.
It’s no problem related to the left storage of the account I used, I tried with my other account that has 30GB of storage left too, same problem.
please try to gather more information since as it is there is not much to go on.
For that, you can export the job as command line, open a terminal (in admin mode if you are running Duplicati as a service) and paste the export into it, add the flag --console-log-level=verbose, then run it.
When it has crashed, copy, say, the 200 preceding lines, zip them and attach the result to a reply.
Thank you for you answer.
Here is the Output:
I recorded the whole output, if you need more than the last 200 lines, I’ll need to censore them but can get you them.
“ResourceExpired” as API response seems to be related
--auth-two-factor-key (Password): The shared secret used to generate
two-factor TOTP codes.
For accounts with two-factor authentication enabled, this is the shared
secret used to generate the two-factor TOTP codes.
and it seemingly does really mean the original shared secret, not usual 6 digit time based code.
I see it generates the code before giving it to MEGA. Does the system time here seem correct?
If any of the failing accounts doesn’t use 2FA, then that’s a good way to kill this line of inquiry…
Problem is that it’s rather unclear what’s going on. There’s a reverse-engineered protocol done
from a third party library – and MEGA support generally doesn’t want to even start with support.
There are a few similar uses, one major one used by rclone, and I’m not finding such problems.
I did find a complaint about concurrent uploads, so especially after you had some early uploads asynchronous-concurrent-upload-limit set to 1 instead of its default 4 might possibly avoid issue.
It’s true that the error begins before - I did not take in account the retryings when I asked for the last 200 lines. Anyway it’s possible that there is not much more interesting data before. If it’s the case it could be interesting to follow all the good advice you received, particularly posting your job config - did you by any chance raise the maximum file size above the default value of 50 MB ? If yes the problem could be that you are simply suffering from a time out due to too big blocks. There is often a maximum time for a single Http transfer (PUT).
Edit: I forgot to say that the advanced option for that in Duplicati is only active if Duplicati is managing the Http transfer itself. When there is an external third party driver, the option needs to be passed by specific API - something that don’t seem to be done currently.
I was able to reproduce it for the last 2 days. Just to confirm again, I just ran the backup again and… it worked without any problem. Even tried creating copies of the previously problematic files, but the backup worked anyway. I’ll try to replicate it in the next few days.
I’ll try disabling MFA once the problem comes up again.
nope. I left it to default 50MB.
Thank you for all your help.
I’m sorry that I don’t know how to provide any lead on what caused the problem.
From what I’ve found so fare regarding problems with Duplicati, Mega doesn’t seem to be a good choice for a backup target. I’m using it, as I’ve got a grandfathered 50GB Free account.
I just tried it with my test install for next Duplicati (it uses the same Mega driver than current Beta) and succeeded with a 480 MB file so it’s not a general problem (however I did not try it with 2FA - I have no idea how to use this, I have only setup a test account with Mega to test Duplicati)
Yeah I dont know.
This is my second post screaming for help - last time the transfer limit of Mega was reached for some reason. (I guess due to my ISP cycling public IPs on a daily basis)
Anyway, here is a short guide on how to use Mega with MFA multi factor authentication with Duplicati:
Set-up MFA in Mega in the security part of settings and copy the seed code that is shown to you.
1a. If you already have it activated and use a non-shit MFA Tool you can also derive this from the TOTP: otpauth://totp/MEGA:*username*@*provider*.com?secret=herewouldbeacodethatyouneedtocopy&issuer=MEGA → herewouldbeacodethatyouneedtocopy
In the second step (Destination) of the duplicati backup setup, once needs to enter the credentials and expand the advanced options. In the dropdown, select the option auth-two-factor-key and enter the previously copied herewouldbeacodethatyouneedtocopy into the new field.
Yeah there is something rotten with 2FA. I test the connection and it is ‘successful’, yet trying to do a backup (empty, never mind a 400 Mb file) fails immediately. I can see the code in FreeOtp+ and it’s the same as in Duplicati :-/. Trying a second time, backup succeeds yet I can see retries in the live log, even for small files.
Removed 2FA and an empty backup succeeds without retry (it is always doing a download of at least 50 Mb file for verification purpose).
For the sake of research, if you disable 2FA, does it succeeds ?