Skip to content
Windows.HomesUnofficial

LAN shares and SMB versions: why \\NAS disappeared

Verified 2 min read

Share versus NTFS permissions, the SMB1 removal that broke old devices, and the guest-access default that blocks NAS logins.

Tested onPro (26H2) / Server · Build 26300.9457 / 26100.33650 · x64
E1
Build
26300.9457 / 26100.33650
Edition
Pro (26H2) / Server
Architecture
x64
Support
Documentation (E1)
Evidence
E1Official documentation
Verified
2026-10-29
Page type
Setup

The short answer

Section titled “The short answer”

Three independent layers decide whether \\NAS\share opens:

Layer Question
Name resolution can the client turn NAS into an IP?
SMB protocol version does the device speak something Windows still allows?
Authentication is the account allowed, and is guest access permitted?

Windows changed the defaults on the last two, which is why shares that “worked for years” stopped.

Layer 1: name resolution

Section titled “Layer 1: name resolution”
Terminal window
Resolve-DnsName nas -ErrorAction SilentlyContinue
Test-NetConnection nas -Port 445
Test-NetConnection 192.168.50.10 -Port 445

If the IP works and the name does not, it is name resolution — not SMB. Use the IP, add a hosts entry, or fix DNS on the router.

Layer 2: SMB versions

Section titled “Layer 2: SMB versions”
Version Status on Windows 11/Server 2025
SMB1 disabled by default, removal supported
SMB2 enabled
SMB3 enabled, encryption capable

Old NAS boxes and printers still speak SMB1. Enabling it re-introduces a protocol with known weaknesses — do it only for a device you cannot replace, and only on a trusted LAN.

Terminal window
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RequireSecuritySignature,EncryptData
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature,EnableInsecureGuestLogons

Layer 3: guest access is blocked

Section titled “Layer 3: guest access is blocked”

Since Windows 10 1709, insecure guest logons are disabled: a share that allows anonymous access is refused with “you can’t access this shared folder because your organization’s security policies block unauthenticated guest access”.

Two honest options:

  1. Create a real account on the NAS and connect with credentials (correct).
  2. Re-enable insecure guest logons (quick, weak — the share becomes readable by anyone on the LAN).
Terminal window
# the policy that produces that message
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters' -Name AllowInsecureGuestAuth -ErrorAction SilentlyContinue

Creating a share correctly

Section titled “Creating a share correctly”

Share permissions and NTFS permissions are both applied; the effective permission is the more restrictive.

Terminal window
New-Item -ItemType Directory -Path D:\Shares\Team -Force
New-SmbShare -Name Team -Path D:\Shares\Team -FullAccess 'DOMAIN\Admins' -ChangeAccess 'DOMAIN\Staff'
Grant-SmbShareAccess -Name Team -AccountName 'DOMAIN\Staff' -AccessRight Change -Force

Rule of thumb: give Everyone / Full at the share level and control access with NTFS. Two permission systems fighting each other is the most common “but I gave them access” problem.

Who is connected right now

Section titled “Who is connected right now”
Terminal window
Get-SmbSession | Select-Object ClientComputerName,ClientUserName,NumOpens
Get-SmbOpenFile | Select-Object ClientUserName,Path

To kick a stale session: Close-SmbSession -ClientComputerName 192.168.50.20 -Force (closes that client’s open files).

Section titled “Related”

Lab boundary

Section titled “Lab boundary”

E1. SMB defaults and cmdlets are Microsoft-documented. The lab VMs share nothing over SMB, so no share fault was reproduced.

Sources