Why did the latest Windows update stop network drives from working and how can I fix it?

Is your old scanner or printer broken after the September Windows update? Here’s what to do about SMBv1.

The recent Windows security update from September 2025 has created significant issues for network file sharing. This update disrupts connections that depend on an old protocol called Server Message Block version 1 (SMBv1). If your office suddenly cannot access shared files or use network printers, this update is a likely cause. This guide will explain the problem in simple terms. We will cover what SMBv1 is, why it is still in use, and the serious dangers it presents. You will learn how the September update affects your systems, what you can do to fix it right now, and what other users are experiencing. Most importantly, we will outline the best long-term plan to move away from this outdated technology and secure your network.

What is SMBv1?

Think of Server Message Block version 1, or SMBv1, as an old, original language for computers on a network to share things like files and printers. It was created in 1983, a time when network security was not the major concern it is today. For many years, it was the standard way Windows computers talked to each other. However, just like languages evolve, so do computer protocols.

In 2007, a new and improved version called SMBv2 was released. Later, SMBv3 arrived, bringing even better performance and, critically, much stronger security. Because these newer versions are far safer and more efficient, Microsoft officially began phasing out SMBv1 in 2014. The company has since advised everyone to stop using it. The newer SMBv2 and SMBv3 protocols are the modern standard, offering encryption and other features that protect your data from attackers.

Why is SMBv1 Still Used?

If SMBv1 is so old and insecure, why is it still found in many business environments? The answer is legacy hardware and software. Many older devices were built to speak only the SMBv1 language and cannot be updated to learn newer ones.

Older Office Equipment

Many multifunction printers, scanners, and network-attached storage (NAS) devices, especially those manufactured before 2014, require SMBv1 to function. Devices from various well-known brands may have “Scan to Folder” features that rely exclusively on this old protocol. Upgrading the firmware on these devices is not always possible.

Legacy Operating Systems

Some organizations still run very old operating systems like Windows XP or Windows Server 2003 on specific machines that control critical equipment. These systems do not support modern SMB versions and depend entirely on SMBv1 for network communication.

Embedded and Third-Party Applications

Specialized business applications, such as those used in manufacturing, healthcare, or accounting, may have been coded decades ago with SMBv1 dependencies. Medical devices that send scans to a network share or factory machines that receive instructions from a central server might use SMBv1. Replacing or rewriting this custom software can be extremely expensive and disruptive.

For these reasons, many IT administrators have kept SMBv1 active on their networks to support these essential legacy systems, even though they are aware of the risks.

The Security Risks of SMBv1

Using SMBv1 on your network is like leaving a ground-floor window of your office unlocked every night. It has fundamental security weaknesses that cannot be fixed. These flaws have been exploited in some of the most damaging cyberattacks in history.

The protocol lacks modern security features. It does not properly encrypt communications, meaning a hacker on your network could potentially read the data being transferred. It also has weak authentication mechanisms, making it easier for an attacker to gain unauthorized access.

The most famous exploit targeting SMBv1 is called EternalBlue. This tool, developed by the U.S. National Security Agency and later leaked online, took advantage of a critical vulnerability in the protocol. It allowed attackers to run malicious code on any unpatched computer that had SMBv1 enabled. This exploit was the engine behind several devastating global cyberattacks:

WannaCry (2017)

This ransomware attack spread rapidly across the globe, locking up the files of hundreds of thousands of computers in over 150 countries. It crippled businesses, government agencies, and, most notably, hospitals within the UK’s National Health Service, forcing the cancellation of thousands of appointments and operations.

NotPetya (2017)

Initially disguised as ransomware, NotPetya was a destructive cyberweapon that permanently wiped data from infected computers. It caused billions of dollars in damages to major corporations, including the shipping giant Maersk, which had to reinstall its entire global network of 45,000 PCs and 4,000 servers.

TrickBot and Emotet

These are banking trojans and malware distribution networks that have used SMBv1 vulnerabilities to spread laterally within an infected network, stealing credentials and deploying further malware like ransomware.

These events show that the danger of SMBv1 is not theoretical. It is a proven entry point for attackers that can lead to catastrophic financial and operational losses. This is a clear “Your Money or Your Life” (YMYL) issue, where a technical vulnerability has direct real-world consequences.

The September 2025 Updates

As part of its regular monthly security schedule, known as Patch Tuesday, Microsoft released updates in September 2025. These updates fixed 81 security holes across its products, including Windows 11, Windows 10, and Windows Server. Among the fixes were patches for two zero-day vulnerabilities, which are flaws that are actively being exploited by attackers. While these updates are critical for security, they have had an unintended side effect.

How the Updates Affect SMBv1 Shares

Microsoft has confirmed that the September updates unintentionally broke connections to SMBv1 shares. The problem specifically occurs when the connection uses an old transport mechanism called NetBIOS over TCP/IP (NetBT). NetBT is essentially an old-fashioned phone book that computers use to find each other on a local network.

When a computer with the September update tries to connect to an SMBv1 share, the connection fails. Likewise, if a legacy device tries to connect to an updated Windows machine’s share, it also fails. Users report seeing “System error 86” or being stuck in a loop where the system repeatedly asks for a username and password, even when the correct credentials are provided. From the user’s perspective, the shared drive simply times out or refuses to open.

Impacted Systems

This issue affects a wide range of modern Windows systems that have received the September 2025 update.

• Client Systems: Windows 11 (versions 24H2, 23H2, 22H2) and Windows 10 (versions 22H2, 21H2).
• Server Systems: Windows Server 2025 and Windows Server 2022.

The problem exists in mixed environments. For example, if your file server is not updated but your Windows 11 desktop is, the connection to an SMBv1 share on that server will fail. The reverse is also true.

Workarounds for the Issue

Completely turning off SMBv1 will break all legacy devices that depend on it. The correct workaround depends on your specific situation. There are two primary scenarios: a modern Windows computer needs to connect to a legacy device, or a legacy application needs to connect to a modern Windows server.

Windows Systems Connecting to Legacy Devices

In this scenario, the goal is to force your Windows computer to use a different communication path that is not broken by the update. This involves disabling NetBT and forcing the SMB connection to use TCP port 445 directly.

Important Warning: This workaround will only succeed if the legacy device (your old scanner or NAS) supports direct-hosted SMB over TCP 445. Many very old devices do not; they rely exclusively on the broken NetBT path (using port 139). For those devices, this fix will not work.

You can disable NetBIOS in two main ways:

Disable NetBIOS via NIC Settings (for a single computer)

1. Right-click the network icon in your system tray and select “Network and Internet settings.”
2. Go to “Advanced network settings” and then select your network adapter (e.g., “Ethernet”).
3. Click “Properties,” then select “Internet Protocol Version 4 (TCP/IPv4)” and click its “Properties” button.
4. On the General tab, click the “Advanced” button.
5. Go to the “WINS” tab.
6. Select the option “Disable NetBIOS over TCP/IP.”
7. Click OK on all windows to save the changes.

Disable NetBIOS via PowerShell (for scripting and multiple computers)

You can use a PowerShell command to apply this setting. Run PowerShell as an administrator and enter the following script:

# Get all network adapters that have an IP address configured
$adapters = Get-WmiObject Win32_NetworkAdapterConfiguration | where {$_.IPEnabled -eq $true}

# Loop through each adapter and disable NetBIOS
foreach ($adapter in $adapters) {
$adapter.SetTcpipNetbios(2) # 2 means disabled
}

This script finds every active network connection and sets its NetBIOS configuration to “disabled.”

Legacy Applications Connecting to Windows Shares

If you have an old application that needs to write data to a share on your modern Windows Server, you can adjust the share itself to be more compatible. Microsoft suggests disabling a feature called “leasing” on the share. Leasing is a modern SMB feature that improves performance but can confuse old applications.

You can do this using a PowerShell command on your file server.

To create a new share compatible with legacy apps:

New-SmbShare -Name "LegacyShare" -Path "C:\Data\Legacy" -LeasingMode None

To modify an existing share:

Set-SmbShare -Name "ExistingShare" -LeasingMode None

This command tells the server to host the share without the modern leasing features, making it appear more like a basic share that older systems can understand, all while still using the secure SMBv2 or SMBv3 protocol.

What If the Workarounds Are Not Enough?

For some, the legacy device is so old it only supports SMBv1 over NetBT. In this case, the workarounds above will fail. Your options become very limited and carry risks.

• Uninstall the September updates: This will likely restore functionality but is a very dangerous choice. Uninstalling a security update reopens the vulnerabilities it was designed to fix, leaving your system exposed to attack. This should be considered a last resort.
• Wait for an official fix from Microsoft: Microsoft is aware of the issue. However, the company has not given a timeline for a permanent solution. Waiting is a passive strategy that may not be feasible for critical business operations.
• Replace the legacy device: This is the best, most secure long-term solution. While it requires a budget, it permanently resolves the security risk and eliminates the dependency on an outdated protocol.

User Feedback and Real-World Impact

The impact of this update has been felt most sharply in corporate environments. Administrators have expressed extreme frustration over the disruption. One admin noted, “thousands of computers in our company share files and printers this way, and this update is causing chaos.” The update, identified as KB5065426, was reported to reset network profiles from “Private” to “Public,” which automatically disables file and printer sharing as a security measure. Even after manually fixing these settings, connectivity remained broken.

A critical issue was discovered in environments that use cloned system images. Many large organizations use tools like Acronis or Macrium to create a single master Windows installation and then deploy that image to hundreds or thousands of computers. This process results in many machines having the same machine Security Identifier (SID). The September update appears to break file sharing between these cloned systems, a restriction that was not in place before. For businesses that rely on cloning for efficient deployment, this is a major operational roadblock.

The Long-Term Solution: A Full Migration from SMBv1

The current crisis serves as an urgent reminder: SMBv1 must be removed from your network. Relying on workarounds is not a sustainable strategy. A full migration is the only way to ensure security and stability.

Audit for SMBv1 Usage

You cannot remove what you cannot see. The first step is to find out which devices on your network are still using SMBv1. On Windows Server, you can enable auditing with a simple PowerShell command: Set-SmbServerConfiguration -AuditSmb1Access $true. This will create event logs every time a device connects using SMBv1, telling you the IP address of the legacy client.

Contact Vendors and Plan Upgrades

Once you have a list of devices, contact the manufacturers. Ask if a firmware update is available that adds support for SMBv2 or SMBv3. If no update exists, that device must be placed on a list for replacement.

Create a Replacement Budget

Present the list of non-upgradable devices to management. Explain the severe security risks and the operational instability caused by relying on SMBv1. Frame the replacement not as an IT expense but as essential risk mitigation for the business.

Disable SMBv1

Once you have confirmed that no devices require it, you must disable SMBv1 across your network. You can do this with PowerShell on both clients and servers. This is the final step to securing your environment from this specific threat vector.

Frequently Asked Questions

Question: Can I safely uninstall the September 2025 update?

Answer: Uninstalling a security update is not considered safe. It removes fixes for known vulnerabilities, leaving your system exposed. The workarounds are a much safer immediate step.

Question: Will my SMBv2 and SMBv3 shares continue working?

Answer: Yes. This issue only affects SMBv1 connections over NetBT. All shares using the modern and secure SMBv2 and SMBv3 protocols will continue to function normally.

Question: When will Microsoft offer a permanent fix?

Answer: Microsoft has not announced a specific date for a fix. Given the security risks of SMBv1, the company’s priority is encouraging migration. Organizations should focus on migration rather than waiting for a patch that may not come.

Question: How do I check if SMBv1 is enabled on my computer?

Answer: You can check the status on a client or server by running the following command in PowerShell: Get-SmbServerConfiguration | Select EnableSMB1Protocol. If it returns “True,” it is enabled.

Conclusion

The disruption caused by the September 2025 Windows update underscores the hidden dangers of maintaining legacy protocols. While the immediate workarounds can restore critical operations, they should be viewed as temporary measures. The core problem is the continued existence of SMBv1 in modern networks. This event should serve as a catalyst for all IT leaders to prioritize the auditing, planning, and complete removal of SMBv1. Migrating to modern protocols like SMBv3 is the only effective way to protect your organization from significant security threats and prevent future operational breakdowns.