I have set up quite a few Duplicati 2 backups on Windows to OneDrive for Business. I have saved the configuration and used it on a few Macs as well. I get pretty consistently successful backup reports from the Windows machines but I get pretty consistent failures from the Macs. All are running Duplicati 2.0.3.3.
One common error I get on one of the Macs is:
Failed to process file duplicati-20180605T133600Z.dlist.zip.aes => Cannot send data when method is: GET,
One common fatal report I get from the Macs is:
Failed: No SharePoint web could be logged in to at path ‘https://COMPANY-my.sharepoint.com/personal/ACCOUNTNAME/Documents/Backups/MacBookAir2’. Maybe wrong credentials. Or try using ‘//’ in path to separate web from folder path.
All of the Windows computers are backing up to this same OD4B account and location but of course each has it’s own folder, not “MacBookAir2” directory as in the example above.
Is there something I need to do differently for Macs than I do on Windows to make this work correctly?
There shouldn’t be anything different needed - the files being put on the destination are zip (or 7z) files with a standard Duplicati naming convention so the OS type from which they are being uploaded shouldn’t make any difference.
Are all the Mac failures intermittent or do you have a few that happen every run?
I have a few that happen every run. Every few days one of the Macs will get an error which seems to mean the verify failed but the backup was actually successful. Then it will give a fatal report the next few days saying the SharePoint site doesn’t exist.
I know the files stored are the same regardless of OS. The only thing that I know is different is that Macs require the Mono framework. Maybe that is an issue.
It’s just odd that 10 to 12 Windows machines get successful backups over 90% of the time and on the Macs I’m just hoping for an error rather than fatal report.
That sounds like a bug in the OD4B client. Can you get a stack trace or similar for this? You should find it in the “Logs…” area for the backup.
I get this report fairly regularly.
“DeletedFiles: 3268
DeletedFolders: 8
ModifiedFiles: 1666
ExaminedFiles: 171759
OpenedFiles: 8031
AddedFiles: 6365
SizeOfModifiedFiles: 592063734
SizeOfAddedFiles: 482251611
SizeOfExaminedFiles: 67031795333
SizeOfOpenedFiles: 1080383802
NotProcessedFiles: 0
AddedFolders: 40
TooLargeFiles: 0
FilesWithError: 0
ModifiedFolders: 0
ModifiedSymlinks: 0
AddedSymlinks: 0
DeletedSymlinks: 0
PartialBackup: False
Dryrun: False
MainOperation: Backup
ParsedResult: Error
VerboseOutput: False
VerboseErrors: False
EndTime: 6/8/2018 4:53:52 PM (1528491232)
BeginTime: 6/8/2018 4:00:00 PM (1528488000)
Duration: 00:53:52.8108920
Messages: [
No remote filesets were deleted
]
Warnings: []
Errors: [
Failed to process file duplicati-20180601T120000Z.dlist.zip.aes => Cannot send data when method is: GET,
Failed to process file duplicati-i356d68124f2645ac8fdf1266e75cdec0.dindex.zip.aes => Element with path ‘/personal/admin_COMPANY_org/Documents/Backups/MBAir/duplicati-i356d68124f2645ac8fdf1266e75cdec0.dindex.zip.aes’ not found on host ‘https://COMPANY-my.sharepoint.com’.,
Failed to process file duplicati-b7763d68c7b9e4ea197e2e7199614ecf3.dblock.zip.aes => Element with path ‘/personal/admin_COMPANY_org/Documents/Backups/MBAir/duplicati-b7763d68c7b9e4ea197e2e7199614ecf3.dblock.zip.aes’ not found on host ‘https://COMPANY-my.sharepoint.com’.
]”
As soon as I can get back on that computer I’ll look in the log for a stack trace. Thanks for looking into this.
Hello, I’m actually hitting the same issue on my mac. Backups are successful (even if tests fail), but I’m unable to fully restore any backup because of this issue : the retrieval of some block/index volumes fail, even the dlist file, although if I see them in OneDrive …
Here is the requested stack trace:
Operation Get with file duplicati-20180808T114616Z.dlist.zip.aes attempt 4 of 5 failed with message: Cannot send data when method is: GET
System.Net.ProtocolViolationException: Cannot send data when method is: GET
at System.Net.HttpWebRequest.GetRequestStream () [0x00013] in <ef91d242760e4228b2b02d60ba54c76a>:0
at Microsoft.SharePoint.Client.SPWebRequestExecutor.Execute () [0x00000] in <ae42712e06c349faba29591f4f24e683>:0
at Microsoft.SharePoint.Client.File.OpenBinaryDirect (Microsoft.SharePoint.Client.ClientContext context, System.String serverRelativeUrl) [0x00078] in <8e3eb3065b524a909640c2bd1341366d>:0
at Duplicati.Library.Backend.SharePointBackend.doGet (System.String remotename, System.IO.Stream stream, System.Boolean useNewContext) [0x000cd] in <af8ac214563a4fee9eb61e07c1ce76ed>:0
at Duplicati.Library.Backend.SharePointBackend.Get (System.String remotename, System.IO.Stream stream) [0x00000] in <af8ac214563a4fee9eb61e07c1ce76ed>:0
at Duplicati.Library.Main.BackendManager.coreDoGetPiping (Duplicati.Library.Main.BackendManager+FileEntryItem item, Duplicati.Library.Interface.IEncryption useDecrypter, System.Int64& retDownloadSize, System.String& retHashcode) [0x00270] in <ae134c5a9abb455eb7f06c134d211773>:0
at Duplicati.Library.Main.BackendManager.DoGet (Duplicati.Library.Main.BackendManager+FileEntryItem item) [0x002ed] in <ae134c5a9abb455eb7f06c134d211773>:0
at Duplicati.Library.Main.BackendManager.ThreadRun () [0x000e5] in <ae134c5a9abb455eb7f06c134d211773>:0
Hell @Gilles_Gagniard, welcome to the forum!
Are you also running Duplicati 2.0.3.3 beta like the original poster was running?
(Note that I edited your post by replaced the “>” with “~~~” around the beginning and end of the error messages.)
Yes same version. I’ve tried setting up the storage as Microsoft Sharepoint or as Microsoft OD4B, but I’ve got the exact same issue with both backends, probably because they both use the same client behind the scene.
If the issue only exists on Mac (and Linux probably?), the root cause is probably a difference in the mono runtime vs the .Net one on Windows, and the sharepoint client being incompatible with mono …
That would make sense, though I feel we’d be hearing more people having this issue if that were what was going on. But just in case, can you let us know what version of mono you’re using? You should be able to find it in the “MonoVersion” field on the main menu “About” → “System info” page under “System properties”.
Are you just testing or did you really need to restore a file? If the later, remember that as long as you can get the destination files to somewhere that Duplicati can access successfully, you can restore form there. It’s not ideal, but at should work.
@kenkendk or @Pectojin , have you run into this issue before (can’t restore due to "Cannot send data when method is: GET" error)?
Hmm, this one is pretty weird. It’s happening within the Microsoft.SharePoint.Client library, with the actual error message coming from HttpWebRequest.
The HttpWebRequest library is basically just saying that you can’t put POST data in a GET request, which seems fair since it breaks the standard. But it sounds weird to me that this would be implemented differently in mono than on .NET 
I’m not really familiar with the SharePoint Client in C#, but I’m not seeing any way to force the OpenBinaryDirect method to use POST rather than GET. Kinda seems like it has to be fixed upstream unless we can do something different with the library 
Looking into the SharePoint library, it is doing something strange:
string requestUrl = File.MakeFullUrl (context, serverRelativeUrl);
WebRequestExecutor webRequestExecutor = context.WebRequestExecutorFactory.CreateWebRequestExecutor (context, requestUrl);
webRequestExecutor.RequestHeaders [HttpRequestHeader.Translate] = "f";
context.FireExecutingWebRequestEventInternal (new WebRequestEventArgs (webRequestExecutor));
webRequestExecutor.GetRequestStream ().Write (new byte[0], 0, 0); //<--- write empty data
webRequestExecutor.RequestMethod = "GET";
webRequestExecutor.Execute ();
So it seems that the library sets an empty body, which should be the same as not setting a body, but it is likely that which is triggering the error.
Unfortunately, we cannot fix that; it requires the sharepoint library to be updated.
However, if Mono correctly handles an empty write, that would fix it as well.
Are you using an updated Mono ?
At that time I was using the mono available from homebrew, so probably 5.14.0.177.
Right now, I’m using the official mono distribution version 5.10.1.57. I’ve also upgraded to canary build 2.3.0.9 to have access to the new Onedrive v2 backend, which is not available in the latest beta version 2.3.0.3.
With this new backend, I’m able to successfully backup/restore to a OneDrive for Business account.