After upgrading or installing a recent version of Windows 11, administrators may encounter problems accessing older network shares, NAS appliances, Linux/Samba servers, embedded devices or legacy file servers.

A typical command such as:

net use Z: "\\192.168.10.25\shared"

may return:

System error 3227320323 has occurred.

Another common message is:

You can't access this shared folder because your computer is configured to require SMB signing.

The confusing part is that the remote server may still respond perfectly to ping, making the problem appear to be related to permissions, networking or the UNC path.

In many cases, however, the problem is caused by a security compatibility mismatch between the Windows SMB client and the SMB server.

Microsoft specifically documents System error 3227320323 as one of the errors that can occur when connecting to third-party SMB devices using guest access while Windows requires SMB signing.

What is SMB?

SMB, or Server Message Block, is the network protocol commonly used by Windows for:

• shared folders;
• network drives;
• file servers;
• NAS devices;
• shared printers;
• Windows-to-Windows file access;
• Windows-to-Linux/Samba file sharing.

A typical SMB UNC path looks like:

\\fileserver\documents

or:

\\192.168.10.25\documents

Modern systems normally use SMB 2.x or SMB 3.x.

Windows 11 does not install SMBv1 by default, and Microsoft strongly recommends against enabling it because the protocol is deprecated and has significant security weaknesses.

Therefore, enabling SMB1 should not be the first solution when a network share stops working.

What is SMB signing?

SMB signing provides integrity protection for SMB communications.

Each SMB message can include a cryptographic signature generated using information from the authenticated SMB session. The receiving system can verify this signature to determine whether the message was modified while traveling across the network.

SMB signing therefore helps protect against attacks such as:

• SMB relay attacks;
• man-in-the-middle attacks;
• message modification;
• spoofing;
• certain credential-relay scenarios.

Microsoft describes SMB signing as a mechanism that helps verify that SMB data has not been tampered with in transit.

Why did the share work before but stop working now?

This situation has become particularly common with newer Windows 11 security defaults.

Windows 11 version 24H2 introduced stronger SMB signing requirements. In particular, current Microsoft documentation states that Windows 11 24H2 Pro, Enterprise and Education can require SMB signing for SMB connections by default.

Older systems, NAS appliances, embedded devices and older Samba configurations may:

1. not support SMB signing correctly;
2. have SMB signing disabled;
3. offer only unauthenticated guest access;
4. fall back to Guest instead of authenticating users;
5. use an obsolete SMB implementation.

The Windows client consequently refuses the connection even though the server itself is reachable.

Step 1: Verify basic network connectivity

Start by checking whether the remote host is reachable.

For example:

ping 192.168.10.25

A successful response such as:

Reply from 192.168.10.25: bytes=32 time=4ms TTL=64

confirms basic IP connectivity.

However, a successful ping does not prove that SMB works.

ping uses ICMP, while normal SMB file sharing typically uses TCP port 445.

A system can therefore answer ping requests while SMB is completely unavailable.

Step 2: Test SMB port 445

PowerShell provides a better network test:

Test-NetConnection 192.168.10.25 -Port 445

Look for:

TcpTestSucceeded : True

If it returns:

TcpTestSucceeded : False

the problem is more likely related to:

• firewall rules;
• network ACLs;
• routing;
• the SMB server not running;
• port 445 being blocked.

If TCP 445 succeeds but the share still cannot be opened, investigate SMB authentication, signing and permissions.

Step 3: Test the share directly

Instead of mapping a drive immediately, test the share:

dir "\\192.168.10.25\shared"

You can also test a deeper directory:

dir "\\192.168.10.25\shared\department\archive"

If Windows returns:

You can't access this shared folder because your computer is configured to require SMB signing.

the problem has now been narrowed down considerably.

Step 4: Check the Windows SMB client configuration

Open PowerShell as Administrator and run:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableInsecureGuestLogons

A system with stronger defaults may show something similar to:

RequireSecuritySignature EnableInsecureGuestLogons
------------------------ -------------------------
True                     False

The two settings mean different things.

RequireSecuritySignature

True

means the Windows SMB client requires SMB signing.

EnableInsecureGuestLogons

False

means Windows refuses unauthenticated guest SMB sessions.

These are two independent security controls.

Microsoft provides Get-SmbClientConfiguration and Set-SmbClientConfiguration specifically for inspecting and modifying SMB client configuration.

Step 5: Determine whether guest access is involved

This distinction matters.

There are broadly two legacy scenarios.

Scenario A: The server supports authenticated users but not mandatory signing

For example:

Windows PC
    |
    | SMB
    v
Legacy SMB Server
Authentication: YES
SMB signing: NO

In this case, disabling the requirement for client signing may restore compatibility.

Scenario B: The server uses anonymous Guest access

For example:

Windows PC
    |
    | SMB
    v
Legacy NAS / Samba Server
Authentication: Guest
SMB signing: unavailable

This is more problematic.

Microsoft notes that guest logons do not support normal SMB signing and encryption protections.

Preferred solution: Fix the SMB server

Before weakening the Windows client, the best solution is normally to correct the server.

Depending on the server or appliance, this may involve:

• upgrading its firmware;
• updating Samba;
• enabling SMB signing;
• creating authenticated user accounts;
• disabling anonymous guest access;
• enabling SMB 2 or SMB 3;
• replacing obsolete NAS hardware;
• updating the server operating system.

This preserves Windows security rather than changing every SMB connection made by the workstation.

Microsoft explicitly recommends enabling or correcting SMB signing on the server rather than disabling signing on the client as the preferred solution.

Workaround 1: Stop requiring SMB signing

If the SMB server cannot currently be updated and it exists on a trusted internal network, an administrator can configure Windows not to require signing.

Open an elevated PowerShell session:

Set-SmbClientConfiguration -RequireSecuritySignature $false -Force

Verify the result:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature

Expected:

RequireSecuritySignature
------------------------
False

Microsoft documents the equivalent configuration using:

Set-SmbClientConfiguration -RequireSecuritySignature $false

as well as the corresponding Group Policy setting.

Then test the share again:

dir "\\192.168.10.25\shared"

Important: This does not simply “turn SMB signing off”

There is an important technical distinction.

Setting:

RequireSecuritySignature $false

means:

The client no longer requires every SMB server to use signing.

It does not necessarily mean that every subsequent SMB connection becomes unsigned.

If an SMB server itself requires signing, signing can still be negotiated.

The dangerous case occurs when neither endpoint requires signing, in which case the SMB session can proceed unsigned.

Security risk of disabling RequireSecuritySignature

The command:

Set-SmbClientConfiguration -RequireSecuritySignature $false -Force

changes the SMB client policy, not merely one mapped drive.

That means the workstation can potentially establish unsigned SMB sessions with other servers too.

This reduces protection against attacks including:

• SMB relay;
• machine-in-the-middle interception;
• traffic modification;
• spoofed SMB servers;
• certain credential attacks.

For this reason, disabling mandatory signing should ideally be treated as a temporary compatibility measure, not the permanent solution.

Workaround 2: Enable insecure Guest SMB logons

Sometimes disabling mandatory signing is not enough.

The next error may indicate that Windows is blocking unauthenticated guest access.

The relevant setting can be inspected with:

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons

If absolutely required for a trusted legacy server, guest access can be enabled using:

Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force

Verify:

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons

Microsoft documents this command for legacy SMB servers that provide resources exclusively through Guest access.

However, Microsoft explicitly recommends not enabling insecure guest logons unless they are unavoidable.

Why insecure Guest SMB is especially risky

Guest SMB access does not properly authenticate the remote party in the same way as a normal authenticated SMB session.

Microsoft warns that enabling insecure guest logons can expose clients to:

• attacker-in-the-middle attacks;
• malicious or spoofed file servers;
• phishing scenarios;
• malware;
• ransomware;
• exposure of sensitive network data.

Guest connections also cannot provide normal SMB signing or encryption guarantees.

Therefore:

Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force

should not be treated as an ordinary network troubleshooting command.

It is a security policy change.

Combining the two compatibility settings

Some particularly old file servers may require both:

Set-SmbClientConfiguration -RequireSecuritySignature $false -Force

and:

Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force

This configuration provides considerably less protection than the default Windows configuration.

Use it only when:

• the server is known and trusted;
• the network is controlled;
• the device cannot currently be upgraded;
• access is operationally necessary;
• the risks are understood.

It should generally not be used on laptops regularly connected to unknown or public networks.

How to restore the secure Windows defaults

One of the most important parts of any troubleshooting procedure is knowing how to reverse it.

Re-enable mandatory SMB signing:

Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

Disable insecure Guest access:

Set-SmbClientConfiguration -EnableInsecureGuestLogons $false -Force

Then verify:

Get-SmbClientConfiguration |
    Select-Object RequireSecuritySignature, EnableInsecureGuestLogons

A hardened configuration should show:

RequireSecuritySignature EnableInsecureGuestLogons
------------------------ -------------------------
True                     False

This rollback is particularly important if temporary compatibility settings were enabled for migrating data from an obsolete server.

Configuring SMB signing through Group Policy

SMB signing requirements can also be controlled through Local Group Policy.

Run:

gpedit.msc

Navigate to:

Computer Configuration
  → Windows Settings
  → Security Settings
  → Local Policies
  → Security Options

Locate:

Microsoft network client:
Digitally sign communications (always)

This policy corresponds to whether the SMB client requires signing.

Microsoft documents this Group Policy path as the supported method for controlling SMB client signing requirements.

In Active Directory environments, administrators should normally manage this centrally through domain Group Policy rather than changing individual workstations.

Configuring insecure Guest access through Group Policy

For guest SMB access, open:

gpedit.msc

and navigate to:

Computer Configuration
  → Administrative Templates
  → Network
  → Lanman Workstation

Locate:

Enable insecure guest logons

Microsoft documents this policy as the Group Policy equivalent of:

Set-SmbClientConfiguration -EnableInsecureGuestLogons $true

Again, this setting should normally remain disabled.

Mapping the share after fixing SMB negotiation

Once the underlying SMB issue is resolved, map the network drive.

For example:

net use Z: "\\192.168.10.25\shared"

To authenticate with a specific account:

net use Z: "\\192.168.10.25\shared" /user:fileserver\username *

The * causes Windows to request the password interactively rather than exposing the password directly in the command.

This is preferable to:

net use Z: "\\192.168.10.25\shared" /user:username MySecretPassword

because putting passwords directly in commands can expose them through:

• command history;
• scripts;
• screenshots;
• logs;
• process inspection;
• documentation copied to other systems.

Microsoft’s net use command supports mapping remote resources, assigning drive letters and specifying alternate credentials.

Make the mapped drive persistent

To reconnect the share after signing in:

net use Z: "\\192.168.10.25\shared" /persistent:yes

Or change the default persistence behavior:

net use /persistent:yes

Use persistent mappings carefully on laptops that frequently leave the trusted corporate network.

Remove a mapped drive

To remove the mapping:

net use Z: /delete

View all mappings:

net use

Avoid casually using:

net use * /delete

because it can disconnect all current network mappings, potentially interrupting applications that are using files from network drives.

Inspect active SMB connections

Once the connection succeeds, PowerShell can show current SMB sessions:

Get-SmbConnection

You can request selected information:

Get-SmbConnection |
    Select-Object ServerName, ShareName, UserName, Dialect, Encrypted

Get-SmbConnection displays SMB connections established from the Windows SMB client to remote SMB servers and can show information including the negotiated SMB dialect.

Example:

ServerName   ShareName   Dialect   Encrypted
----------   ---------   -------   ---------
FILESERVER   Shared      3.1.1     False

The dialect is especially useful when identifying legacy systems.

Modern Windows SMB clients and servers normally negotiate the highest mutually supported SMB 2.x or SMB 3.x dialect.

Check whether SMB1 is installed

If troubleshooting a very old NAS or file server, administrators may wonder whether SMB1 is required.

Check Windows optional features:

Get-WindowsOptionalFeature -Online |
    Where-Object FeatureName -like "*SMB1*"

Do not enable SMB1 merely because a server is old.

Microsoft deprecated SMB1 years ago, and Windows 11 does not include the SMB1 client or server in a clean installation by default. Microsoft recommends upgrading or replacing servers that still require SMB1.

Why enabling SMB1 is usually worse than changing signing compatibility

A common internet troubleshooting recommendation is:

“Enable SMB 1.0/CIFS File Sharing Support.”

For most modern SMB signing problems, this is the wrong solution.

SMB signing compatibility and SMB protocol version are separate issues.

A server may support SMB2 or SMB3 but:

• not require signing;
• not support signing correctly;
• use Guest authentication.

Enabling SMB1 does not fix those underlying design problems and unnecessarily exposes the computer to an obsolete protocol.

Microsoft explicitly states:

Don’t enable SMB 1.0.

Modern SMB2 and SMB3 should be preferred.

Useful SMB troubleshooting command reference

Test host availability

ping 192.168.10.25

Risk: None beyond normal network probing.

Test SMB TCP port

Test-NetConnection 192.168.10.25 -Port 445

Risk: Read-only diagnostic operation.

Test a UNC share

dir "\\192.168.10.25\shared"

Risk: Normally read-only if simply listing a directory.

Display mapped network connections

net use

Risk: Read-only.

Inspect SMB client configuration

Get-SmbClientConfiguration

Risk: Read-only.

Inspect important security options only

Get-SmbClientConfiguration |
    Select-Object RequireSecuritySignature, EnableInsecureGuestLogons

Risk: Read-only.

Inspect active SMB connections

Get-SmbConnection

Risk: Read-only.

Disable mandatory client SMB signing

Set-SmbClientConfiguration -RequireSecuritySignature $false -Force

Risk level: HIGH

Allows connections to SMB servers that do not require signing, reducing protection against SMB relay and man-in-the-middle attacks.

Re-enable mandatory signing

Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

Risk: Low; improves security but can break access to incompatible legacy servers.

Enable insecure Guest access

Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force

Risk level: VERY HIGH

Allows unauthenticated Guest SMB sessions and weakens protections against malicious or spoofed servers.

Disable insecure Guest access

Set-SmbClientConfiguration -EnableInsecureGuestLogons $false -Force

Risk: Low; improves security but breaks legacy Guest-only shares.

Map a network drive

net use Z: "\\192.168.10.25\shared"

Risk: Depends on the security of the remote server.

Map using authenticated credentials

net use Z: "\\192.168.10.25\shared" /user:server\username *

Risk: Lower than Guest access. Prefer interactive password entry rather than placing passwords directly in scripts.

Remove one mapping

net use Z: /delete

Risk: Any program using files from that drive may lose access.

Recommended troubleshooting sequence

A safe troubleshooting workflow is:

1. Test IP connectivity
        ↓
2. Test TCP port 445
        ↓
3. Test the UNC path
        ↓
4. Check SMB client security configuration
        ↓
5. Determine whether authentication or Guest access is used
        ↓
6. Update/fix the SMB server if possible
        ↓
7. Only then consider client-side compatibility changes
        ↓
8. Test the connection
        ↓
9. Restore stronger security settings when no longer required

This approach avoids weakening Windows security before determining the real problem.

A practical example

Assume a workstation cannot access:

\\192.168.10.25\shared

The first test is:

ping 192.168.10.25

The server responds.

Next:

Test-NetConnection 192.168.10.25 -Port 445

returns:

TcpTestSucceeded : True

The network and SMB service are therefore reachable.

Testing:

dir "\\192.168.10.25\shared"

returns:

You can't access this shared folder because your computer is configured to require SMB signing.

Check the client:

Get-SmbClientConfiguration |
    Select-Object RequireSecuritySignature, EnableInsecureGuestLogons

and receive:

RequireSecuritySignature : True
EnableInsecureGuestLogons : False

At this stage the administrator should investigate the remote server.

If the server can be configured for:

• authenticated access;
• SMB2/SMB3;
• SMB signing;

that is the preferred correction.

Only if the legacy server cannot be updated should the administrator consider:

Set-SmbClientConfiguration -RequireSecuritySignature $false -Force

If the server additionally requires unauthenticated Guest access, the administrator may discover that:

Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force

is also necessary.

But doing so should be viewed as accepting a documented security trade-off, not as a normal configuration improvement.

Should SMB signing simply be disabled on an internal LAN?

Not automatically.

A common assumption is:

“It is on our LAN, so unsigned SMB is safe.”

Modern network security does not assume that every machine on a local network is trustworthy.

An attacker could potentially gain LAN access through:

• a compromised workstation;
• malware;
• an infected laptop;
• an insecure Wi-Fi client;
• a compromised IoT device;
• unauthorized physical network access;
• a breached VPN account.

Once inside the network, unsigned SMB traffic provides weaker protection against interception and relay attacks.

Therefore, the fact that a server is internal reduces some exposure but does not remove the security risk.

Best long-term configuration

For a modern environment, aim for:

SMB2 / SMB3
        +
Authenticated user accounts
        +
SMB signing
        +
No insecure Guest access
        +
SMB encryption where appropriate

The Windows client can then retain:

RequireSecuritySignature = True
EnableInsecureGuestLogons = False

This removes the need for workstation-specific compatibility exceptions.

Final recommendations

When Windows reports:

System error 3227320323 has occurred.

or:

You can't access this shared folder because your computer is configured to require SMB signing.

do not immediately enable SMB1 or disable Windows security features.

First determine whether the server:

1. supports SMB2 or SMB3;
2. supports SMB signing;
3. uses authenticated accounts;
4. relies on anonymous Guest access;
5. can receive a software or firmware upgrade.

If the server can be modernized, fix the server.

If it cannot, Windows provides compatibility controls such as:

Set-SmbClientConfiguration -RequireSecuritySignature $false -Force

and, in more problematic Guest-only environments:

Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force

But both commands weaken the default security posture of the computer, with insecure Guest access carrying particularly significant risk.

For temporary migration or legacy-access scenarios, document the change and restore the secure configuration afterward:

Set-SmbClientConfiguration -RequireSecuritySignature $true -Force
Set-SmbClientConfiguration -EnableInsecureGuestLogons $false -Force

The objective should not simply be to make the network share work.

The objective should be to make it work without unnecessarily weakening every other SMB connection made by the workstation.

Quick reference

Security summary

Sources: Microsoft documentation on SMB signing, SMB client configuration, insecure guest logons, SMB security hardening and SMBv1 deprecation.