this morning, my daily backup to my OneDrive gave this error message :
The remote server returned an error: (410) Gone.
Here the full last retry log message :
Operation List with file attempt 5 of 5 failed with message: The remote server returned an error: (410) Gone.
System.Net.WebException: The remote server returned an error: (410) Gone.
at Duplicati.Library.Main.BackendManager.List()
at Duplicati.Library.Main.Operation.FilelistProcessor.RemoteListAnalysis(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)
at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)
at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(BackendManager backend, String protectedfile)
at Duplicati.Library.Main.Operation.BackupHandler.Run(String[] sources, IFilter filter)
In my OneDrive backup folder, I can see 3 files from yesterday and many more from the past 6 months, so everything looks normal.
Maybe it’s just a short outage ? Or OneDrive just changed its communication protocol ?
I just re-did the AuthID authorization but it didn’t change anything.
EDIT:
testing the connection in the configuration menu gives the same error.
I’m getting this as well. Started on the run from last night (Monday night, 1/7) and has just happened again this evening. The last files I’m seeing are from Saturday at 12am, which is when the backup runs (nightly at midnight). There’s less than 20% space used, so it’s not running out of space.
I was having this issue (I just updated to 2.0.4.5_beta_2018-11-28, but I don’t know if that’s related). It worked once I switched the destination from “Microsoft OneDrive” to “Microsoft OneDrive v2”.
I to have the issue, on 1x PC and 2x MAC started at the same time too. Only OneDrive is affected my local backups are fine as is GoogleDrive. Duplicati version is “Duplicati - 2.0.4.5_beta_2018-11-28” and I have been running it successfully since release.
I’m running Duplicati - 2.0.4.5_beta_2018-11-28 on a PC and Duplicati - 2.0.3.3_beta_2018-04-02 on a Synology DiskStation device. Both of these are connected to OneDrive and both have started reporting the same error: The remote server returned an error: (410) Gone
It’s interesting to note that I haven’t changed any files or directories on OneDrive. Actually, this OneDrive is dedicated to Duplicati.
@samh I have the same question as @manu: How to configure Microsoft OneDrive v2, that you said is working OK for you.
these APIs are now end of life and will no longer be available after November 1, 2018 .
To switch, I think (besides editing the job to change the Storage type dropdown from Microsoft OneDrive to Microsoft OneDrive v2) you probably have to get a new AuthID but you can certainly “Test connection” first.
Migrating “should” just be a dropdown change and probably a new AuthID. The Duplicati screen is the same. Between its Storage Type and AuthID is a Path on server (still). If there’s something more, please say where.
Setting up OneDrive (personal) gives some information. Link goes to a post to address questions/concerns, however lack of OneDrive v2 in a beta release (as opposed to canary or experimental) was fixed by 2.0.4.5.
The above How-To is possibly a better place to document any information generally useful to setting this up.
@ts678 ,
I updated Duplicati this morning from the auto-update feature and then the version was
2.0.4.2_experimental_2018-11-12 .
Clicking on “About -> Check for updates now” did nothing.
So I just manually downloaded and installed the version 2.0.4.5_beta_2018-11-28, which failed (on Windows 10) ; so I manually uninstalled it and reinstalled it, and then Duplicati launched normally again, but I still don’t have a correct support for OneDrive v2, as seen on this screenshot :
Probably the first thing to try when the web UI gets confused (as it might be here – did previous OneDrive look that way too, or is this coming from somewhere else?) is a hard refresh of the browser, sometimes Control-F5.
There is some hope that a change after 2.0.4.5 will avoid the need to deal with browser caching quite as often.
With the version 2.0.4.5_beta_2018-11-28, you have to select OneDrive v2, then Ctrl+F5 if you see the old parameters (like on my screenshot above), and finally click AuthID and follow its process.
it’s compatible and it won’t reupload everything (at least it didn’t for me )
Are there any reasons why this would fail due to having ++ in the path?
I am trying to upgrade a Windows 10 Pro based, non-Service, install to the newer beta.
It was using OneDrive v1 and the previous beta. Now I am trying to swap to OneDrive v2.
I have swapped to v2 in the GUI as above thread notes, hit CTRL+f5, changed the authid, also used different browser to check the backup folder really is still there…
But I get this error message instead. The path is supposed to be ++BACKUPS/Test and this is an Office365 account for a “home” user.
Notice how in that screenshot there are no ++ on the path?
As a test, I swapped the path to just BANANA and then let it create the folder when the test button asked. And sure enough - there is the new folder in OneDrive.
So, whilst not even leaving the page, I now change the path to zzBACKUPS/Test and use the other browser to rename the folder on the server.
Sure enough, we now have success. Backup running - picked up from the old files. And all is continuing.
POSSIBLE ISSUE: Why did the ++ in my OneDrive path make it fail?
Duplicati.CommandLine.BackendTool.exe let me try out variations (and see errors) a bit more easily, and the suspect wound up being Percent-encoding in a URI which I’m not sure is being done correctly. You can follow that chart, converting a plus sign to the sequence %2b or %2B to see if it lets plus work. That’s a workaround, not a fix. For a code fix (if manual encoding actually helps), please file an issue to get the fix request queued.
This same issue possibly explains this problem found by @thepappaq where workaround was to do a folder rename. That one was a little murkier because the # (number sign or pound sign) is also an invalid character sometimes, so Microsoft Graph’s unifying things could maybe have unified restrictions, but plus is not invalid:
Thanks for testing out variations of names. If you would like, feel free to try other characters that should also be percent-encoded. The test data for the URL encoding theory so far is a little thin now, but could be better.
