OneDrive failing : "The remote server returned an error: (410) Gone."

I’m running Duplicati - on a PC and Duplicati - 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.

Same happened here.

  • Latest version of Duplicati running.
  • I see the Duplicati APP in the list of authorized apps on my MS account.
  • I use a separate account only for backup.
  • The BKP files are still on the backend.
  • Generated new AuthID, but test connection still fails with (410) Gone
    99% sure MSFT changed something in their API.

I’ve had exactly the same, nothing has changed from the usual routine but both OneDrive backup sets failed with this error last night.

That was announced. Maybe it finally happened. For Duplicati OneDrive, this means switch to OneDrive v2.

Migrating from Live SDK to Microsoft Graph

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

The above How-To is possibly a better place to document any information generally useful to setting this up.

1 Like

@ts678 ,
I updated Duplicati this morning from the auto-update feature and then the version was .
Clicking on “About -> Check for updates now” did nothing.

So I just manually downloaded and installed the version, 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 :

From null

What should I do …? :slight_smile:

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 will avoid the need to deal with browser caching quite as often.


@ts678 ,
Control+F5 did the trick, thanks ! :slight_smile:
I had to re-do the AuthID, but now everything is working normally again.

I’ve done the cntrl-F5 and re-auth but it still gives this error (Win-10, Chrome). Any other ideas on this?

Can I try to change from onedrive to onedrive v2 without redoing the whole backup?


With the version, 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 :slight_smile: )

1 Like

Yes, that did it! Thanks.

@manu: Big thank you, you saved my day.

My thanks also. You folks made it easy for me!

Thank you, repaired here.

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:

Invalid file names and file types in OneDrive, OneDrive for Business, and SharePoint

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.


To add a little bit to this test. This was a live setup of three computers. Each sending a selection of files into the same OneDrive account. The path had the ++ signs in it when running a backup using the older OneDrive V1 as a destination. That had been running happy for a while. So this issue has crept in as part of the migration to OneDriveV2

To fix it, all I needed to do was rename the folder on the server to remove the ++ and update the path in Duplicati. All was then very happy and the backups have picked up and continued.

I apologise that I don’t have time to keep up with all the life on the forum, so get a bit lost in the technical details at times here. I also don’t have a GitHub account, but hope these very repeatable findings are of use.

What is especially key here is the error message is clearly showing the ++ missing from the path. So that is an easy tip for other people to spot if the issue is the same for them.

I’m curious to hear if people have the same issue if the “+” is in the middle or end of the folder name. (I suspect they will.)

1 Like

When I work on the machine again this evening I’ll try a few other random path tests.

It is simple to test when just setting up a new backup destination. If I put in a path it doesn’t like - it will error if the path exists or not. So I’ll try a few other combos out. FOL++DER, FOLDER++, FOL!!DER and FOL DER also FOL%2b%2bDER to see if the percent encoding works.

Anything else you would like me to check?

It is certainly a downgrade from previous. The path was happy before as these are legal characters for a file path. Simple to guess the fix though thanks to the verbose error splurge. I may not have understood what any of it meant, but I could see my path had spaces instead of ++ signs.

I’m actually in the middle of upgrades on two different Office 365 systems. One is Office365 Home and the other is Office 365 Business. Both happily using OneDriveV2 now.

(I have to say it is a little confusing trying to pick the correct choice with three different OneDrive options, and two different SharePoint choices. That had me running round in circles for a while due to lack of example paths.)

Testing details
Windows 10 Pro 1809 PC. Current BETA release. Office 365 HOME account. Chrome browser.

Press ADD backup, give it any name and password, hit next.
Set Storage Type to OneDriveV2, setup AuthID (using Office 365 Home account)

Now put test path into the Path on Server box and hit TEST.

  • An accepted path will offer to be created. (Press NO as folder not needed)
  • A failed path will kick out the error box as in my earlier post.

(Note I never proceed past this Backup Destination setup page. I just backed out of the half setup config once testing is completed. The [Test Connection] button was all I needed for the path test)

Test Results
All of the following are legal paths. Plus, Space, Exclamation Marks are all legal for folder names. (And used to work with OneDriveV1)



The error message said “contains invalid trailing character” when the ++ were on the end of the folder name.

The error message also said “contains invalid trailing character” when the ++ were on the start of the folder name.

That does go to imply that the issue only occurs when the “invalid characters” [sic] are at the start or end of the folder name. Perfectly acceptable in the middle of a foldername

Using Percentage Encoding
The use of percent encoding DOES work.

zzBACKUPS/%2b%2bFOLDER did create zzBACKUPS/++FOLDER
zzBACKUPS/FOL%2b%2bDER did create zzBACKUPS/FOL++DER

Other feedback from a noob to this backup
The error messages are SERIOUSLY impossible to read for us mere humans. Any plans to have clearer error messages with the developer info hidden behind an advance button?

Only now when I am reading it after testing have I actually see the text at the end there about “contains invalid trailing character”. it would be REALLY helpful if text like that was highlighted in some way. Or promoted to be the first line.

Or maybe the errors just need a “Translate for ID-10T user” button. :rofl:

Also a LOUD tip here when testing Office 365 Accounts - USE PRIVACY MODE

I notice in the forum discussions the authentication can get confused. Web browser remembering login details. Or remembering details of a different account. Or different user.

If you are getting problems then open your web browser in INCOGNITO MODE or PRIVACY MODE.

Usually done by a RIGHT CLICK on the icon and launch the browser. Now when you sign in you are certain to not have any old credentials around.

When testing I’ll often have multiple instances of the browser running like this, allowing me to be connected to multiple different Microsoft accounts with out clashing.

Same trick works with Google Accounts and no doubt most of the cloudy stuff.