This error keeps coming up, regardless of how many times I restart odrive, and prevents many files from syncing. They go directly to the Not Allowed menu. On the Manage Links page, I do not have the option to update the credentials for this connection. Is there a way to correct this without removing the entire account folder, then resyncing it all again?
Sorry to hear of the trouble, can you please post the snapshot of the error and steps you perform to get this error.
Definitely, you don’t need to unlink “OneDrive” account folder and odrive should provide you a way to re-authorize your storage (if needed), by any chance have you checked the OneDrive storage folder in odrive web client below?
To get this error, I started the odrive app, and the items go to the Not Allowed category almost immediately.
Here’s the error message that comes up:
I checked the link that you provided, and the OneDrive account in question only has the Edit and Unlink options. I am otherwise able to navigate the files and folders in that account through the odrive web interface.
We have also observed this incorrect error response given back to us from OneDrive which corresponds to no storage session. I believe this is an intermittent issue with OneDrive but file should re-tried again and sync to the storage.
Since you are able to access OneDrive storage from odrive web interface, it confirms odrive have access to storage without need of any re-authorization.
I would suggest you to wait and see if file automatically retried after giving 5 - 10mins to sync? btw what is the file size of the MVI_3256.MOV file.
Please let me know if problem persists, send diagnostic report from tray menu and mention OS user name / timestamp, I’ll take a look at it.
I know this is an old post but I am having the same issue. I have about 5 files that have been trying to sync for days.
When I start odrive it looks like they are going to sync but when they get to 100% they appear in the “Not Allowed” list. After about 5 min they try again.
I am not sure if it is related but odrive appears to be sapping my bandwidth in a bad way. When I disable the auto sync the problem goes away. I am going to try a subscription to see if that helps the bandwidth issue.
Thanks for the help,
Ok… some more info:
I was going to try to manually transfer the files to OneDrive and logged in directly to OneDrive went to the folder the first file should be in and found 218 files that were listed as “~tmpXX_FILENAME” where XX is a 2 digit alpha numeric number and FILENAME is the file name that should have been uploaded… these temp files were not taking up any space but the original file had not synced either.
Thanks for the update @rSquared. I missed this one before.
You are using OneDrive for business? This sounds like an issue I am communicating with them on:
Can you provide a screenshot of what you are seeing and then see if the file will be uploaded when those temp files are removed?
I’m having the same issue with constant fruitless syncing to OneDrive for Business and I received the titular error message earlier. I can browse OneDrive for Business via odrive.com. Deleting the ~tmp files did not fix it; they begin to repopulate. Any solution? Thank you.
Can you send over a diagnostic from the odrive tray menu so I can take a look?
Thanks, but I’ve already unlinked the account. oDrive dumped thousands of the ~tmp files in folders all over my OneDrive for Business account. They don’t sync back down to my computer, even with the Microsoft client, so I’m going to have to use PowerShell to find and delete those files.
Apologies for the inconvenience here.
It is actually Microsoft that creates those tmp files. They occur when OneDrive for Business accepts the upload, creates the tmp file for that upload, and then hits an error when trying to finish/commit that file.They are supposed to clean them up within 24 hours…
Their upload behavior has some flaws that perpetuate this type of occurrence. odrive can’t actually see those files at all, since they aren’t returned in the API calls. So, an error is generated initially on the OD4B side; odrive’s upload request is returned as an error; odrive marks the file for upload reattempt. The subsequent upload attempt can then fail because the tmp file exists (Microsoft returns: “An unspecified error has occurred”, which is pretty much useless to take any action on). Then it is just a vicious cycle of the same thing, at that point.
Unfortunately, I am not really sure how it can be addressed without Microsoft adjusting their upload flow behavior. I had missed a response from them last month in the bug report, so I am following-up again, to see what their recommendation is, if they cannot fix on their side.
Ok, thanks for the background. The news that the tmp files should clear eventually is definitely welcome. I sympathize with the difficulty of interfacing with a hampered API. Might suggest that the oDrive client do a sanity check for repeated failures with that error and break itself out of the “vicious cycle”, which is intensive in both processor utilization and bandwidth. E.g. those files could go to a special list with an option to manually retry syncing them all and maybe also have them be reset when the client is restarted. Again, thanks for the informative reply and help.
Thanks. Its a tough situation because our #1 priority is getting unsynced files uploaded, but we are working on improving the behavior by making it move visible and restricting the rate of retry.