Update: This was fixed in December 2020 CU.
October 2020 CU introduced a regression in the file upload functionality which may result in errors when you upload a file that’s larger than 100 MB to a document library using the classic UI. The same problem also exists in November 2020 CU.
The error visible in UI and ULS contains information similar to the following:
Original error: Microsoft.SharePoint.Client.InvalidClientQueryException: The expression "web/getFileByServerRelativeUrl(@file)/FinishUpload(uploadId=guid'…',fileOffset=…,checkInComment=)" is not valid. at Microsoft.SharePoint.Client.Rest.EdmExpressionParser.ParseIdentifier(Boolean allowMethodCall, EdmParserNode& node) at Microsoft.SharePoint.Client.Rest.EdmExpressionParser.ParsePath() at Microsoft.SharePoint.Client.Rest.RestRequestProcessor.GetObjectFromPath(Boolean mainRequestPath, String path, String pathForErrorMessage)
Affected SharePoint versions
- SharePoint Server 2016
- SharePoint Server 2019
Status
Microsoft is planning to fix the issue in December 2020 CU.
Workarounds we are currently aware of
SharePoint 2016:
- Use the Upload button in the ribbon
This needs “Allow management of content types : YES” - Upload to an an Asset Library (this library type uses always uploadex.aspx)
You need to copy the file from there to the final folder structure destination. - Explicitely navigate to the following upload page http://<site-holding-the-doc-lib>/_layouts/15/uploadex.aspx
Be aware that this method will always upload the file to the root of the specific library, the file can be copied manually to the final folder after the upload has completed - Use the Open with Explorer
Can be used with Internet Explorer 32-bit to do your file transfers. - Use a Powershell script to upload to the desired location.
There are various examples available on the internet e.g. this and this
SharePoint 2019:
- Switch to Modern UI to perform the uploads
- Use the Upload button in the ribbon
This needs “Allow management of content types : YES” - Upload to an an Asset Library (this library type uses always uploadex.aspx)
You need to copy the file from there to the final folder structure destination. - Explicitely navigate to the following upload page http://<site-holding-the-doc-lib>/_layouts/15/uploadex.aspx
Be aware that this method will always upload the file to the root of the specific library, the file can be copied manually to the final folder after the upload has completed - Use the Open with Explorer
Can be used with Internet Explorer 32-bit to do your file transfers. - Use a Powershell script to upload to the desired location.
There are various examples available on the internet e.g. this and this
Permalink
Thank you for the info, we had just installed Oct CU last weekend, so I tested this and it appears we have this on all our farms as well. I guess we will have to wait for Dec CU and advise the users of the workaround.
Permalink
Have anyone seen this in SharePoint Server 2013 or is it just in 2016/2019?
Permalink
Hi Dwayne,
only SharePoint Server 2016 and 2019 are affected.
Cheers,
Stefan
Permalink
Hi Stefan – Thank you
Permalink
Hi Stefan,
About that bullet point “Use the Upload button in the ribbon – This needs “Allow management of content types : YES”” that I have trouble to understand in conjunction with the bullet point above that (SP2019). –> Does that work in to Classic UI or in Modern UI only? That actually sounds to me like the most standard function for a standard user to upload files, or did I get that wrong?
Another guess: Does uploading files >100 MB via web service work?
Kind regards
Hardy
Permalink
Hi Hardy,
configuration of the library settings is done in classic view.
Not sure about the webservice to be honest. I haven’t seen any cases on this topic.
Cheers,
Stefan
Permalink
Thanks for the heads up!
A question for Stefan and anyone else reading this:
what is the best way to keep up to date with SharePoint CU regressions? Todd Klindt’s good old website for SharePoint builds used to be good for that, but it seems broken and un-maintained nowadays…
Permalink
Hi Will,
here is my take on this:
such a site is not that helpful. The reason is that most regressions only affect a very small number of customer with very specific scenarios.
Also keep in mind that the majority of regressions is identified 6-12 months after the fix was released and not right away.
Some of the regressions which were causing issues in the last couple of months were already known when the fixes were released and they were documented in the “Known Issues” section of the relevant KB articles. We still received a lot of support cases about these issues because customers were applying the fixes without reading the KB articles.
What is important is that each fix should be evaluated against all imporant business requirements and processes in a test environment before it is applied on a production environment to ensure that the changes do cause a negative effect on your specific environment and configuration.
Cheers,
Stefan
Permalink
Thanks for your reply Stefan!
Obviously all patches should be evaluated in a test environment before being applied in production. But no matter how much testing one does, not all scenarios or features can be covered. Things slip through the cracks. And that includes regressions in SharePoint CU’s. But that’s just how IT is.
It’s not uncommon for SharePoint environments out there to lag months and sometimes years behind the current patch version. So suddenly, you’d have to read up on 12, 24, 36 or maybe even 48 KB articles to get up to speed on all bug fixes and “known issues”. Sure, it’s not impossible by any means, but it’s often not done, for maybe obvious reasons.
And that’s where Todd Klindt’s site for SharePoint patch versions was great. Bigger regressions that affected most customers were reported by users and they were easily assessed by a click on each CU. You could quickly get an overview of the entire CU chain, from where you are to where you needed to be. And while I’m not familiar with the circumstances on the latest regressions, I trust what you say about them being documented in advance. But that is certainly not always the case.
Finally, I would have to argue that your own very site is obviously a great asset in this matter. I realized that 10 seconds after posting my initial question, and believed I’d get that back as a reply…
Thanks for all your hard work in helping us SharePointers, it’s all very much appreciated! Have a nice weekend!
Permalink
Thank you for the information, we have the same issue on our SharePoint 2019 Farm. We might advice our users to map their site as network drive for uploading files. Temporary solution for uploading large files.
On the other hand this advice has download limit 100mb which might confuse our users. We couldn’t succed to increase it by increasing the limit in WebClient settings in Registry.
Regards
Permalink
Since we installed october cu, some users can no longer synchronize with the OneDrive clien (groove.exe). We also have the message that the file size is too big. Maybe this has something in common with this error. Microsoft is working hard on this issue.
Permalink
Thanks for this info. I was searching for the solution of this issue since last two days. I have applied the OCT CU in our SP 2016 environment. But the workaround is working fine. Will wait until MS fix it in next cycle.
Permalink
Facing this problem since Nov and didnt find this blog.. wasted a lot effort to create upload tools to replace this.. thanks for the news and i know it is not my fault.. MS really mass up nowadays..
Permalink
Hi Adam,
the issue is fixed in December CU which was just released.
Cheers,
Stefan
Permalink
Thank you for the confirmation.
Permalink
We have seen serious performance problems on 1 SP2016 farm since Oct update. Dec update has not fixed them. I’m creating a case with MS now and will follow up with findings (if there are any).
Permalink
Hi There, Has this been fixed? Seems we are still having issues with the upload that is more than 100mb
Thanks