Share via

Office Files Opening as Read-Only on SMB Share – Seen This Before?

Jeeshan Khan 0 Reputation points
2026-02-26T15:21:31.6133333+00:00

🔎 Office Files Opening as Read-Only on SMB Share – Seen This Before? For the last 5 months we’ve been working with Microsoft Support on an issue where Excel/Word files left open for long periods (e.g., overnight) reopen as read-only from a network share.

📌 Environment Windows Server 2012 → 2016 migration Worked perfectly for months after migration Issue started around Sep 2025 No change in user behaviour or access method Microsoft’s current position is that this is related to SMB leasing / session timeout / oplocks and is “by design”. However, this does not explain why the setup was stable for months and then changed without any known trigger. We are pushing for a log-based root cause rather than changing a long-standing business workflow.

🤝 Question to the community

Has anyone seen similar behaviour in: Windows Server 2016/2019/2022 file servers SMB 3.x Office files on network shares If yes: What was the actual root cause? Any reliable fix or mitigation? Would really appreciate insights from others who have faced this in production.

Microsoft 365 and Office | SharePoint Server | For business

Locked Question. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Eirik Grindevoll 0 Reputation points
    2026-04-21T13:33:16.7466667+00:00

    Hi @Jeeshan khan Did you figure this out ?

  2. Anonymous
    2026-02-27T00:18:32.03+00:00

    Hi Jeeshan Khan,

    Welcome to Microsoft Q&A Forum!

    Have a good day and I hope you're doing well!

    Thanks for sharing the detailed background on this case. Based on what you’ve described and similar scenarios in the community, I’d like to share a perspective for you to consider. 

    Building on your notes and the vendor's feedback, the issue likely lies within the SMB Leasing / Oplocks (Opportunistic Locks) and Session Timeout mechanisms. Here is how this dynamic typically plays out: 

    1. When a user opens a file, the Client receives a "Lease" (priority right) to write data. 
    2. When the Client machine is left overnight, it often enters an "Idle" state, Sleep, or the Network Interface Card (NIC) automatically switches to power-saving mode. This causes a network interruption, even if just for a split second. 
    3. To protect data integrity (and avoid file corruption), the Server is forced to break the lease when the Client stops responding. 
    4. The next morning, when the user wakes the machine, Office attempts to reconnect, but the Server considers the old session "closed," thus granting only Read-Only access. 

    Regarding the September 2025 timeline. Although user behavior hasn't changed, the underlying OS environment likely has. It is highly probable that a Windows Server Cumulative Update around that time modified SMB security policies or tightened how Timeouts are handled (making the Server less "patient" with idle connections to free up resources). 

    To dig deeper into the environmental factors that might be triggering this, you might want to review the following points: 

    1. Check NIC Power Management: Windows Updates often have a tendency to reset this setting to default. 

    • On the Client machine, go to Device Manager > Network Adapters > Right-click the NIC > Properties > Power Management tab. 
    • Ensure you uncheck "Allow the computer to turn off this device to save power". If enabled, the NIC cuts the connection when the machine idles, killing the SMB Lease immediately. 

    2. Check Sleep/Hibernate Settings: heck Power Options to ensure the computer does not automatically Sleep or Hibernate while plugged in (or increase the timeout significantly). If the machine sleeps, the TCP/IP connection is definitely dropped. 

    3. Check GPO for Idle Sessions: Check the Server for the Policy: "Microsoft network server: Amount of idle time required before suspending session". The September update might have activated this or lowered the default timeout value. 

    4. Verify with Logs (For Microsoft Support): Instead of debating the "by design" concept, you can provide them with specific proof from the logs: 

    • Open Event Viewer on the Server: Applications and Services Logs > Microsoft > Windows > SMBServer > Operational. 
    • Filter for Event IDs related to Lease Break or Session Closed that coincide with the time the Client machine went idle. This helps prove the root cause is a network drop/timeout, not an Office application error. 

    I hope these suggestions give you a solid direction to troubleshoot. Since this is a peer-to-peer forum, I would also love to hear insights from other members managing Windows Server 2016/2019 if they have encountered similar behavior. 

    Good luck getting this sorted! 

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.