Forum Discussion
Automated upload competing with users who have a file open in Co-authoring mode
This behavior began approximately mid-December. An automated process uploading/overwriting a file located in SharePoint online was constantly receiving errors when executing. We ran through several scenarios for troubleshooting but in the end, we had found that a user would open the file and leave it open in the background through the working day. This behavior produced some co-authoring lock on the file where people could get in and work on the file at the same time but locked out the automated process that would upload a new version of the file regularly.
We fixed the behavior after consulting with the people who were referencing the file, they were gathering data from it and were not updating it in any way. So, we broke the permission inheritance for this file and set it up to be read-only for all users but the process that was uploading the file. This allowed the people to reference the file and undid the locking behavior that we had observed.
Now, before the middle of December, this locking mechanism didn't exist. Users could have the file open in edit mode and our automated process to update the file was able to upload and overwrite at the same time without issues. Has anyone else observed this behavior within the last few months? We didn't open up a ticket with Microsoft to get an official answer if something new was perhaps implemented and we're curious if anyone has opened a ticket regarding this behavior. Also, I briefly look through the message center and couldn't find any changes in there that seemed to be related to this change by their titles.
The error that was seen from the automated process was:
The remote server returned an error: (423) Locked.
Any input appreciated - I am definitely curious to hear if others are observing this as well.
1 Reply
I haven’t experienced this specific issue, but I have seen related behavior in SharePoint Online. If a file is opened by someone, even if they are only viewing it, SharePoint may treat it as an edit session, which prevents metadata updates. In those cases, SharePoint shows the familiar message:
“The file is locked by \<user\>.”
This happens because users with Edit permissions often open documents in Edit mode by default, even when they only intend to read the content. That passive edit session can block automated processes or metadata updates.
Workaround I use
If users only need to read the document and rarely edit it, I set the file to be read‑only by default. This prevents SharePoint from opening the file in edit mode and avoids the locking behavior.
This thread describes a similar scenario:
Sharepoint - Prevent a new version each time a document is read | Microsoft Community Hub
Default - "Open Read Only" for Office Files | Microsoft Community Hub
If my post solved your issue or answered your query, please mark it as a Solution and give it a Like.
