Can edit document stored in SharePoint in Word Online but not Word 2016

Iron Contributor

Hi all - weird one for you!

 

We've got a load of Word files in a document library in SharePoint (Office 365).  The files use 2 content types (which may or may not be relevant) - here's the problem / symptoms:

  1. For existing files using the 'Document' content type, I can edit them fine in Word 2016 or Word Online.
  2. For new files using the 'Document' content type or any files using the 'Contract' content type, I can edit them in Word Online, but cannot in Word 2016.  The documents open in read-only mode in Word 2016 so can't be amended / saved.
  3. If I rename one of the problem files in SharePoint and then open it in Word 2016, it opens in edit mode and I can make and save changes.  However, if I close the file and then go back into it in Word 2016 it's in read-only mode again!!!
  4. The 'Contract' content type is not set to read-only.
  5. The 'Contract' content type includes a number of mandatory fields.  I can edit these fields / document properties for all files in SharePoint (through Details or Datasheet view).
  6. When I've edited and saved a file in Word Online, I cannot then see the changes when opening the same file in Word 2016.  It opens in read-only and says that changes have been made by another author and that I'll see them when I save the file ... which I can't do as it's opened in read-only mode.
  7. Other users are experiencing exactly the same issue.

I've tried repairing Office 2016, cleaned out cached files from the upload centre and so on, but to no avail.  I've also tried checking files out before editing them, but they still open in read-only mode in Word 2016.  It can't be a permissions thing as I can rename files and edit them in Word online.  It's as if the link between Word 2016 and the files on SharePoint is completely broken.  Has anyone experienced this or got any ideas please as this is causing us significant problems.

 

 

Thanks as always, Oz

10 Replies

Got to the bottom of this at last!  I was syncing this library to OneDrive and apparently syncing libraries which include different content types causes problems and prevents updating of the documents from OneDrive.  I've stopped the sync and all now works fine ... other than from OneDrive.

 

Really hoping Microsoft resolve the issues of syncing SharePoint doc libraries which utilise content types as it's killing adoption of their tools for us.

Oz,

Thanks for posting your findings.  I've also been experiencing this issue for a library that only has the default Document content type.  Once i stopped syncing the library to my OneDrive client, Word now opens the document in edit mode.

Another update:

 

By unchecking the following option within the OD4B client, i was able to keep my document library syncing and still edit files in Word from SharePoint Online.

 

OD4B.png

Thanks Ryan.  So, we can either not sync files and collaborate on them online, or sync files and not collaborate on them!

 

Microsoft, I haven't seen anything in your advertising that says you lose either the sync or the collaboration functionality if you use content types - is this a bug that you're working on?

Oz,

Turns out the issue i ran into was related to the document library having a required column.  The following article talks about the limitation of this; open the article and search for read-only:

https://support.microsoft.com/en-gb/help/3125202/restrictions-and-limitations-when-you-sync-files-an...

 

We'll most likely instruct our users to just not sync and collaborate online for those libraries.

 

The next thing I'm interested in testing out is the Windows 10 Fall Creators Update and the files on demand feature for OneDrive.  If we can't sync offline, can we use the placeholders to easily navigate our libraries using Files on-demand?  I personally like having access to the file structure in Windows Explorer vs. having to open a browser and navigate to a site.

 

 

It's so disappointing that if you use even the most basic of SharePoint functionality (i.e. required columns) that syncing doesn't work and I hope that this is something Microsoft will work on.  I'm not sure that the Fall Creators update will help as I think that when you access an online only file from Windows Explorer it downloads the file to your C: ... and if that file has required meta-data I'd assume it will do it as read-only.  I'm hoping I'm wrong so please let us know what you find.

Check document settings -

 

Document Library --> Settings --> Advanced Settings --> Allow management of content types? should be set to NO.

 

Setting to No worked for me.

After serious digging on my own and struggling I implemented both solutions proposed by @MonicaJ  and @Ryan Steeno  and finally found a solution that worked for me.

 

Disable in Sharepoint:
Allow management of content types? found in:
Document Library --> Settings --> Advanced Settings

 

as well as:

Disable in OneDrive:
Use Office to sync (something like that)
found in Office tab in OneDrive app settings


This solution resulted in ability to edit files in Word app when opened in Sharepoint and sync/save them no longer creating local copy as well as (this confused me the most) not losing ability to work on document with another person even though option is unchecked in OneDrive app. 

@BartW 

On my end, I didn't turn off "Allow management of content types?". I only turned off the option in OneDrive "Use Office applications to sync files that I open".

 

Now when a user want to edit a file that has required columns in the application when browsing on the sync folder in File Explorer:

  1. Right click the file
  2. Click "View Online"
  3. After the file open in Office Online, click "Open in Word [or Excel]" to edit in the application.

This detour via the online application allow editing the file. It covers the majority of the use cases here where I work. Still I'm not impressed by this lack of support for required columns with OneDrive :(

This fixed my issue, I had even tried Un-syncing deleting and re-syncing but that didn't work the first time, I may give it another try though.