Windows September updates break SMBv1 shares: Workarounds and user feedback

Microsoft’s September 2025 security updates have broken connectivity to SMBv1 shares over NetBIOS over TCP/IP (NetBT), disrupting Windows client and server systems that still rely on this legacy protocol. This article explains what SMBv1 is, why it remains in use despite being deprecated, and the serious security risks that come with it. We’ll cover the details of the September updates, their impact on affected systems, and the available workarounds for organizations struggling to restore functionality. Finally, we’ll look at user feedback and long-term recommendations for migrating away from SMBv1 to more secure and modern protocols.

Read 4sysops without ads for free

Author
Recent Posts

IT Experts

This text emerged from a vibe blogging collaboration between a human IT expert and four AI agents (Claude Sonnet, Gemini Pro, Perplexity, and ChatGPT). Each AI queried different search engines to verify facts and challenge the other agents' views, while the human did the final fact-checking and editing. If you spot any mistakes, leave a comment below.

What is SMBv1?

Server Message Block version 1 (SMBv1) is a network file-sharing protocol developed in 1983. It enables file and printer sharing across Windows networks using specific TCP/IP ports. It was the primary file-sharing protocol for Windows systems until SMBv2 replaced it in 2007. Microsoft deprecated SMBv1 in 2014 in favor of SMBv2 and SMBv3, which provide better security, performance, and reliability.

Read 4sysops without ads for free

Why is SMBv1 still used?

Despite Microsoft's deprecation efforts, SMBv1 is still used in many environments because legacy devices and systems depend on it. Older printers, scanners, and multifunction devices from vendors like HP and Xerox often require SMBv1 for network features and cannot be upgraded.

Legacy operating systems such as Windows XP and Windows 2003 Server also rely on SMBv1 for connectivity. Some older NAS devices default to SMBv1, requiring manual reconfiguration for newer protocols. Additionally, certain third-party applications and embedded systems depend on SMBv1, making migration challenging without significant updates or replacements.

SMBv1 is disabled by default in new versions of Windows Server

What are the security risks of SMBv1?

SMBv1 has severe security flaws, including weak authentication, a lack of integrity checks, and unencrypted communications. These vulnerabilities enabled exploits like EternalBlue, which fueled the WannaCry ransomware attack in 2017. Such weaknesses have been leveraged in major cyberattacks, including WannaCry, NotPetya, TrickBot, and Emotet.

What are the September 2025 updates?

The September 2025 Windows security updates fixed 81 vulnerabilities, including two publicly disclosed zero-day vulnerabilities, as part of Microsoft’s Patch Tuesday cycle. Updates were released for Windows 11, Windows 10, and Windows Server, addressing critical security flaws.

How do the updates affect SMBv1 shares?

Microsoft has confirmed that the September 2025 updates break connections to SMBv1 shares, specifically when accessed over NetBIOS over TCP/IP (NetBT). The issue occurs when either the SMB client or server has installed the September update, preventing successful file and folder access using the SMBv1 protocol.

Users attempting to connect to SMBv1 shares may encounter System error 86 or repeated credential prompts, even with correct authentication details. The connection failures manifest as timeout errors or rejection messages when trying to access previously functional network shares.

Read 4sysops without ads for free

What are the impacted systems?

The September 2025 update issue affects a comprehensive range of Microsoft platforms:

Client systems

Windows 11 24H2, 23H2, and 22H2
Windows 10 22H2 and 21H2

Server systems

Windows Server 2025
Windows Server 2022

The problem occurs regardless of whether the client or server system installed the September update, meaning mixed environments with some updated systems will experience connectivity issues to SMBv1 shares.

What are the workarounds?

Completely disabling SMBv1 protocol support breaks all connectivity to legacy devices that require SMBv1. The workaround depends on whether you have Windows systems that need to connect to legacy devices (like old NAS boxes, printers) that only support SMBv1 or whether legacy applications need to connect to your Windows server's shares.

Read 4sysops without ads for free

Windows systems connecting to legacy devices

In this case, you must force Windows systems to use only direct TCP (port 445) by disabling the broken NetBT transport path. However, many legacy SMBv1-only devices depend on NetBIOS over TCP/IP (port 139) and do not support direct-hosted SMB over TCP 445. Thus, disabling NetBT can prevent communication with older systems.

Additionally, having port 445 open doesn't guarantee SMB will use direct TCP—Windows will still try both transport methods simultaneously unless you specifically disable the NetBT path. To force SMB to use port 445, disable or block NetBIOS over TCP/IP (ports 137–139) by disabling NetBIOS via DHCP or NIC settings.

Disable NetBIOS via DHCP server

Select the Advanced tab and then select Microsoft Windows 2000 Options in the Vendor class list. Select the 001 Microsoft Disable Netbios Option check box in the Vendor class list. This setting will apply to DHCP clients configured to Use NetBIOS setting from the DHCP server (the default on many Windows versions). Verify this client option before relying on the DHCP push.

Disable NetBIOS via NIC settings

Right-click Local Area Connection, and then select Properties. Select Internet Protocol (TCP/IP), and then select Properties. Select Advanced. Select the WINS tab and Disable NetBIOS over TCP/IP.

Alternatively, you can use PowerShell:

$adapters = (Get-WmiObject Win32_NetworkAdapterConfiguration | where {$_.IPEnabled -eq $true})
Foreach ($adapter in $adapters){ $adapter.SetTcpipNetbios(2) }

This PowerShell script first queries all network adapters on the system and filters to only those that have IP enabled (are actively configured for TCP/IP networking). It then loops through each of these active adapters and sets the NetBIOS over TCP/IP setting to 2 (disabled) using the SetTcpipNetbios method.

Legacy applications connecting to Windows shares

For legacy applications that need to access file shares on your Windows server, Microsoft suggests configuring those shares with leasing mode using the -LeasingMode None parameter in PowerShell commands like New-SmbShare or Set-SmbShare. This makes the Windows server's shares behave like SMBv1 (without modern features like oplocks and leases) while still using the more secure SMBv2 or SMBv3 protocols.

Here is an example:

# Create a new share compatible with legacy applications
New-SmbShare -Name "LegacyApp" -Path "C:\LegacyData" -LeasingMode None

# Or modify an existing share
Set-SmbShare -Name "ExistingShare" -LeasingMode None

This allows legacy applications to connect successfully without requiring the vulnerable SMBv1 protocol.

What if workarounds are insufficient?

For devices that truly only support NetBT/port 139, the available options become very limited:

Uninstall the September updates (security risk)
Wait for Microsoft's official fix
Replace the legacy devices (if possible)

What is the user feedback?

Corporate users have expressed the most severe frustration.

Enterprise chaos and business disruption

One administrator reported that "there are thousands of computers in the company sharing files and printers this way is causing chaos after the KB5065426 update." Multiple users demanded Microsoft "wake up and fix this issue" as entire organizational networks lost connectivity to shared resources.

The update KB5065426 stops file sharing by resetting network profiles from private to public and disabling file and printer sharing entirely. Even after manually reconfiguring settings, users found that connectivity remained broken until they completely uninstalled the problematic updates.

Cloned systems are particularly affected

A significant discovery emerged regarding cloned operating systems. Users found that the September updates specifically broke file sharing between computers with identical machine Security Identifiers (SIDs)—a common situation in enterprise environments where disk images are deployed across multiple machines using tools like Acronis or Macrium.

As one frustrated administrator noted, "most companies clone operating system images to replicate them on hundreds of other machines distributed across multiple locations," making this restriction particularly damaging for business operations.

Workaround inadequacy

Microsoft's suggested workaround involving TCP port 445 configuration has drawn criticism for requiring potentially unsafe firewall changes that don't fully resolve compatibility issues. Users report that the patches often override manual re-enabling of SMBv1 features, leaving them with limited options beyond completely removing the security updates. This solution eliminates essential security protections.

How to disable SMBv1?

Microsoft strongly advises migrating away from SMBv1 entirely. The company recommends contacting manufacturers of legacy devices for firmware updates supporting SMBv2 or SMBv3, or replacing incompatible hardware.

Before disabling SMBv1, make sure to enable auditing so you can get an overview of the systems in your network that still use SMBv1.

Frequently asked questions

Can I safely uninstall the September 2025 update?

Uninstalling security updates removes important vulnerability fixes and is not recommended. Microsoft's TCP port 445 workaround provides a safer approach to restoring SMBv1 connectivity.

Will SMBv2 and SMBv3 shares continue working?

The September 2025 update issue affects only SMBv1 over NetBT connections. SMBv2 and SMBv3 shares remain fully functional.

When will Microsoft offer a fix?

Microsoft has not provided a timeline for the permanent fix. Organizations should plan for SMBv1 migration rather than relying indefinitely on the workaround solution.

Are there security implications of the port 445 workaround?

Opening TCP port 445 may increase network exposure. Implement appropriate firewall rules and network segmentation to limit access to trusted systems only.

Conclusion

The September 2025 update issue highlights the ongoing challenges of maintaining legacy protocol support in modern environments. IT administrators should implement Microsoft's TCP port 445 workaround for immediate relief while developing comprehensive SMBv1 migration strategies.

Subscribe to 4sysops newsletter!

Consider this disruption an opportunity to eliminate security vulnerabilities and improve network performance by transitioning to supported SMB protocol versions. The investment in migration planning will provide long-term benefits beyond resolving the current connectivity issues.