1. 从一次真实的“扩展错误”说起上周帮朋友处理一台新装的 Windows 11 机器他想访问公司内网一台老文件服务器上的共享目录输入\\192.168.1.20\public之后系统弹出一个让人摸不着头脑的提示“出现了扩展错误”。没有错误代码没有详细说明就这六个字。点确定之后重试还是同样的结果。更诡异的是同一台机器用 IP 能 ping 通用另一台 Windows 10 的电脑访问同一个共享却完全正常。这个场景其实非常典型。Windows 11 在共享访问这块做了不少安全层面的收紧尤其是SMB 签名SMB Signing相关的策略默认行为和 Win10 时代有了明显差异。很多从 Win10 升级上来、或者新装 Win11 的用户第一次遇到“出现了扩展错误”时完全不知道从哪下手网上搜到的答案又大多是“改注册表”“关防火墙”这类笼统建议试了一圈还是没解决。这篇内容就是把这个问题的来龙去脉讲清楚它到底是怎么产生的、为什么 Win11 特别容易触发、以及一套从快到慢、从安全到激进的排查路径。涉及的关键词包括Windows 11、共享文件夹、SMB 签名、扩展错误、PowerShell。不管你是普通家庭用户想访问 NAS还是企业 IT 在维护混合系统环境这套思路都能直接拿去用。需要先说明一点下面所有操作都基于我实际处理过的案例总结不同环境域环境、工作组、NAS 品牌、服务器系统版本可能细节有差异但排查逻辑是通用的。我会在每个步骤里说明“为什么这么做”而不是只丢一串命令给你。2. “扩展错误”到底是个什么错误2.1 它不是网络不通而是协商失败很多人看到“扩展错误”第一反应是网络问题于是去 ping、去查网线、去重启路由器。但如果你能 ping 通目标 IP甚至能用telnet 目标IP 445测通端口那问题基本不在网络层。“出现了扩展错误”这个提示本质上是SMB 协议在会话建立或认证协商阶段失败之后Windows 抛出的一个笼统错误。它不像0x80070035找不到网络路径那样指向明确也不像0x80070005拒绝访问那样指向权限。它更像是一个“兜底提示”——系统知道出问题了但没法用一句话说清楚。从实际抓包和日志分析的经验看触发这个提示最常见的原因集中在三类SMB 签名策略不匹配客户端要求签名服务端不支持或配置不一致。SMB 版本协商失败Win11 默认优先 SMB 3.x老设备可能只支持 SMB 1.0/2.0。凭据或安全策略冲突比如 NTLM 被限制、来宾访问被禁用、凭据管理器里存了错误的旧密码。提示如果你在事件查看器里看到Microsoft-Windows-SMBClient相关的警告或错误那基本可以确认是 SMB 层的问题而不是单纯的网络问题。2.2 为什么 Windows 11 特别容易踩这个坑Win11 相比 Win10在 SMB 安全策略上有几个关键变化这些变化正是“扩展错误”频发的根源。第一SMB 签名默认要求更严格。在 Win10 时代客户端对签名的要求相对宽松很多场景下可以协商降级。但 Win11 在部分版本尤其是较新的 22H2、23H2、24H2中对 SMB 签名的默认策略做了调整当服务端不支持签名或签名配置不匹配时协商就会直接失败而不是像以前那样“降级继续”。第二SMB 1.0/CIFS 默认被移除或禁用。很多老 NAS、老打印机、老文件服务器还在用 SMB 1.0。Win11 默认不再安装 SMB 1.0 支持访问这类设备时就会在协商阶段卡住。第三来宾访问Guest默认被禁用。以前访问共享如果没输密码系统可能会尝试用 Guest 账户。Win11 默认禁止了不安全的来宾登录这也会导致协商失败。第四NTLM 的限制。部分企业环境或安全加固过的系统会限制 NTLM 认证而很多老设备只支持 NTLM这同样会触发扩展错误。理解了这四点你就明白为什么“同一台服务器Win10 能访问Win11 不行”——不是 Win11 坏了而是它的安全默认值变了。2.3 先做这三件事快速缩小范围在动手改任何配置之前先做三个基础判断能帮你省掉大量瞎折腾的时间。第一确认目标共享本身是好的。用另一台能正常访问的电脑最好是 Win10 或同版本 Win11访问同一个共享路径。如果那台也访问不了问题在服务端不在你的 Win11 客户端。第二确认你用的是 IP 还是主机名。有些环境里主机名解析有问题用 IP 能通、用主机名不行。反过来也有。两种都试一下能排除 DNS/NetBIOS 层面的干扰。第三确认凭据是否正确。打开“凭据管理器”控制面板 → 用户账户 → 凭据管理器 → Windows 凭据看看有没有针对目标服务器保存的旧凭据。如果有先删掉再重试。这一步经常被忽略但实际排查中命中率不低。做完这三步如果问题依旧那就进入下面的正式排查流程。3. 用 PowerShell 定位 SMB 协商的真实状态3.1 为什么优先用 PowerShell 而不是图形界面图形界面能看的信息太少了。你点“映射网络驱动器”失败了就一个弹窗没有任何细节。而 PowerShell 里的 SMB 相关 cmdlet 能直接告诉你当前客户端支持哪些 SMB 版本、签名策略是什么、和目标服务器的会话状态如何。更重要的是PowerShell 的输出是可复制、可对比的。你可以把排查前后的输出贴在一起看差异这对定位问题非常关键。打开 PowerShell 的方式按Win X选择“终端”或“Windows PowerShell”。建议用管理员权限运行因为部分查询和修改需要提权。3.2 查看客户端 SMB 配置先看客户端这边的全局配置Get-SmbClientConfiguration这个命令会输出一堆参数重点看这几个参数含义关注点RequireSecuritySignature是否强制要求 SMB 签名如果为 True服务端不支持签名就会失败EnableSecuritySignature是否启用签名通常为 TrueEnableInsecureGuestLogons是否允许不安全的来宾登录Win11 默认 FalseEnableSMB1Protocol是否启用 SMB 1.0Win11 默认 FalseEnableSMB2Protocol是否启用 SMB 2.x/3.x通常为 True如果你看到RequireSecuritySignature是 True而目标服务器是老设备那基本就是它了。再看客户端支持的 SMB 版本Get-SmbClientConfiguration | Select-Object -Property *或者更直接地查协议版本支持情况Get-SmbClientConfiguration | Format-List3.3 查看当前 SMB 会话和连接如果之前尝试过连接可以看看有没有残留的会话Get-SmbConnection Get-SmbSessionGet-SmbConnection显示的是当前已建立的连接包括用的 SMB 版本、签名状态、加密状态。如果目标服务器出现在列表里但状态异常那信息就很有价值。如果连接根本没建立起来这两个命令可能返回空。这时候可以尝试主动发起连接并观察net use \\192.168.1.20\public /user:用户名 密码注意net use在 PowerShell 里也能用它的报错信息有时比图形界面更具体。如果返回“系统错误 64”或“系统错误 53”那指向的是网络层如果返回“系统错误 5”那是权限问题如果还是“出现了扩展错误”那继续往下查。3.4 查看 SMB 相关的事件日志PowerShell 也能直接读事件日志这比在图形界面里一层层点要快得多Get-WinEvent -LogName Microsoft-Windows-SMBClient/Operational -MaxEvents 20如果这个日志没启用可以用Get-WinEvent -LogName Microsoft-Windows-SMBClient/Connectivity -MaxEvents 20重点找 Event ID 30803、30804 这类和签名、协商相关的记录。日志里通常会写明“签名要求不匹配”或“协议版本协商失败”之类的具体原因。这一步是定位问题的关键很多人跳过日志直接改配置结果改了一堆无关的东西。提示如果事件日志里明确写了“SMB 签名”相关字样那第 4 节的方案就是对症的。如果写的是“协议版本”那重点在第 5 节。4. SMB 签名不匹配的完整处理路径4.1 先判断是客户端要求太严还是服务端不支持SMB 签名问题的核心矛盾是一方要求签名另一方不支持或没启用。所以处理方向有两个——要么放宽客户端要求要么在服务端启用签名。从安全角度优先考虑在服务端启用签名而不是在客户端关掉要求。因为签名本身是为了防止中间人篡改关掉它是降低安全性。但如果服务端是老设备比如老 NAS、老打印机根本不支持签名那就只能在客户端侧做妥协。判断方法在能正常访问该共享的机器上运行Get-SmbConnection看输出的Signed列是 True 还是 False。如果是 False说明这个共享本身就没在用签名那 Win11 客户端要求签名就会失败。4.2 客户端侧放宽签名要求的操作如果确认是客户端要求过严可以用 PowerShell 调整Set-SmbClientConfiguration -RequireSecuritySignature $false执行后可能需要确认输入Y回车。这个命令把“强制要求签名”关掉但签名本身还是启用的EnableSecuritySignature仍为 True只是不再强制。这样兼容性更好安全性损失也相对可控。如果想进一步确认当前状态Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature改完之后先断开已有连接再重试net use * /delete /y然后重新访问共享。如果问题解决说明就是签名策略的问题。注意这个修改是全局的会影响这台机器访问所有 SMB 共享的行为。如果你的机器同时要访问安全性要求高的服务器建议改完后记录一下必要时再改回来。4.3 服务端启用签名的思路如果条件允许更好的做法是在服务端启用 SMB 签名。以 Windows Server 为例Set-SmbServerConfiguration -RequireSecuritySignature $true但这里有个坑如果服务端强制要求签名而某些老客户端不支持那些老客户端就会反过来访问不了。所以服务端改签名策略前一定要确认所有需要访问的客户端都支持签名。对于 NAS 设备签名设置通常在管理界面的“文件服务”或“SMB 设置”里不同品牌位置不一样。群晖一般在“控制面板 → 文件服务 → SMB → 高级设置”威联通在“控制面板 → 网络和文件服务 → Win/Mac/NFS → Microsoft 网络”。找“启用 SMB 签名”或“SMB 签名”相关选项。4.4 一个容易被忽略的点加密和签名的关系SMB 3.x 引入了加密功能而加密和签名在某些配置下会互相影响。如果服务端启用了 SMB 加密客户端在协商时可能会因为加密算法不匹配而失败报错也可能表现为“扩展错误”。查看加密相关配置Get-SmbClientConfiguration | Select-Object EncryptionCiphers Get-SmbServerConfiguration | Select-Object EncryptionCiphers如果两边支持的加密算法集合没有交集协商就会失败。这种情况在混合了较新 Windows 和老 NAS 的环境里偶有出现。处理方式是调整其中一方的加密算法列表或者升级固件/系统。5. SMB 协议版本协商失败的排查5.1 确认目标设备支持哪个 SMB 版本如果签名不是问题那下一个重点就是协议版本。Win11 默认优先使用 SMB 3.x如果目标设备只支持 SMB 1.0 或 2.0协商就可能失败。判断目标设备支持什么版本最直接的方法是看能正常访问它的那台机器上Get-SmbConnection的输出Get-SmbConnection | Select-Object ServerName, DialectDialect列会显示类似3.1.1、3.0.2、2.1、1.0这样的值。如果显示的是1.0或2.x而你的 Win11 默认没启用对应支持那就是问题所在。5.2 启用 SMB 1.0 的正确姿势与风险SMB 1.0 是个安全性很差的协议微软一直在推动淘汰它。Win11 默认不安装 SMB 1.0 支持。如果你的目标设备确实只支持 SMB 1.0需要手动启用。在“启用或关闭 Windows 功能”里找到“SMB 1.0/CIFS 文件共享支持”勾选后重启。或者用 PowerShellEnable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -All执行后需要重启。但这里必须强调启用 SMB 1.0 会显著降低安全性因为它存在已知的严重漏洞。如果只是临时访问一台老设备用完建议关掉Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol更好的替代方案是如果那台老设备支持固件升级优先升级到支持 SMB 2.0 或 3.0 的版本。很多老 NAS 通过固件更新是能支持更高版本的。5.3 SMB 2.0/3.0 的启用与禁用如果目标设备支持 SMB 2.0 但不支持 3.0而 Win11 在协商时优先尝试 3.0 失败后没有正确回退也可能出问题。可以尝试临时禁用 SMB 3.0 来强制走 2.0Set-SmbClientConfiguration -EnableSMB2Protocol $true注意SMB 2.x 和 3.x 是共用EnableSMB2Protocol这个开关的没法单独只关 3.0 保留 2.0。所以这个方向的操作空间有限更多是确认它处于启用状态。如果确认是版本协商问题且服务端无法升级那实际可行的方案往往就是启用 SMB 1.0临时或者更换服务端设备。5.4 用抓包确认协商过程如果前面都排查了还是没头绪可以上抓包工具。Wireshark 是最常用的过滤条件用smb2或smb。抓包能看到协商请求和响应里双方各自支持的版本列表以及在哪一步失败。这个信息比任何日志都直接。不过抓包有一定门槛适合已经排除了常见原因、需要深入定位的场景。一个更轻量的替代方案是用 Windows 自带的netsh抓包netsh trace start captureyes tracefileC:\smb_trace.etl复现问题后netsh trace stop然后用事件查看器或网络监视器打开 etl 文件分析。这个方式不用装额外软件适合在客户现场快速取证。6. 凭据、来宾访问与安全策略的干扰6.1 凭据管理器里的旧密码是隐形杀手这个坑我踩过不止一次。之前访问过某台服务器保存了凭据后来服务器密码改了但凭据管理器里还是旧的。Win11 在访问时会用旧凭据去认证认证失败后报的却是“扩展错误”而不是明确的“密码错误”。清理方法cmdkey /list这个命令列出所有保存的凭据。找到目标服务器的条目然后cmdkey /delete:目标服务器IP或名称删掉之后重新访问系统会重新提示输入凭据。图形界面路径是控制面板 → 用户账户 → 凭据管理器 → Windows 凭据。找到对应条目删除即可。6.2 来宾访问被禁用导致的协商失败Win11 默认禁止不安全的来宾登录。如果目标共享允许匿名访问很多 NAS 的公共目录是这样Win11 会因为策略限制而拒绝用来宾身份连接。查看当前设置Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons如果返回 False而你需要访问的共享确实依赖来宾访问可以临时启用Set-SmbClientConfiguration -EnableInsecureGuestLogons $true同样这是降低安全性的操作。更推荐的做法是在服务端为共享设置一个专用账户用账户密码访问而不是依赖来宾。6.3 NTLM 限制与安全策略在企业环境里组策略可能限制了 NTLM 的使用。如果目标服务器只支持 NTLM 认证而客户端被策略禁止使用 NTLM协商就会失败。检查本地安全策略secpol.msc→ 本地策略 → 安全选项 → “网络安全: 限制 NTLM”。如果这里配置了限制而目标设备需要 NTLM就需要调整。不过这个方向涉及域策略的情况比较多普通家庭用户一般不会遇到。如果你在公司网络里遇到建议先问一下 IT 是否有相关策略。6.4 防火墙和端口转发的排查虽然“扩展错误”通常不是防火墙直接导致的但防火墙拦截了 SMB 协商所需的某些端口也可能间接引发。SMB 主要用 445 端口老版本可能用 139。测试端口连通性Test-NetConnection -ComputerName 192.168.1.20 -Port 445如果TcpTestSucceeded是 False那先解决端口连通问题。如果 True说明端口是通的问题在协议层。有些环境里做了端口转发比如把外部的某个端口转发到内部的 445。这种情况下SMB 协商可能会因为地址转换而出现异常。如果必须走端口转发建议确认转发规则是否正确以及是否支持 SMB 所需的双向通信。7. 一套可复用的排查顺序与经验总结7.1 从快到慢的排查清单把前面的内容整理成一个可执行的顺序遇到“扩展错误”时按这个顺序走基础确认ping 通不通、445 端口通不通、换台机器能不能访问。清理凭据cmdkey /list看有没有旧凭据有就删。看日志Get-WinEvent查 SMBClient 日志找具体原因。查签名Get-SmbClientConfiguration看RequireSecuritySignature。查版本在能访问的机器上看Get-SmbConnection的Dialect。查来宾确认EnableInsecureGuestLogons状态。改配置根据前面定位的原因针对性调整。抓包前面都无效时用抓包看协商细节。这个顺序的核心逻辑是先排除最简单的再处理需要改配置的最后才上重型工具。很多人一上来就改注册表、关防火墙结果把环境搞乱了问题还没解决。7.2 几个我实际踩过的坑坑一改了客户端签名忘了重启相关服务。改完Set-SmbClientConfiguration后有时候需要重启Workstation服务或者重启机器才生效。我遇到过改完没反应重启后就好了的情况。坑二以为所有 Win11 版本行为一致。不同 Win11 版本21H2、22H2、23H2、24H2在 SMB 默认策略上有细微差异。尤其是企业版和专业版可能还受组策略影响。所以别人的解决方案在你机器上不一定直接有效要结合自己的版本判断。坑三忽略了服务端的日志。如果服务端也是 Windows它的 SMB 日志同样有价值。在服务端运行Get-WinEvent -LogName Microsoft-Windows-SMBServer/Operational能看到它那边记录的协商失败原因。两边日志对照定位会快很多。坑四在域环境里用本地账户思路排查。域环境下的认证走的是域控凭据、策略、信任关系都可能影响。域环境遇到这个问题优先检查域信任和组策略而不是本地 SMB 配置。7.3 关于安全性的取舍建议整个排查过程中很多操作是在“兼容性”和“安全性”之间做取舍。我的建议是能升级服务端就升级让老设备支持更高版本的 SMB这是最优解。能用在服务端启用签名解决的就不要在客户端关签名要求。SMB 1.0 只在临时场景启用用完就关。来宾访问能不用就不用给共享设个专用账户更安全。所有降低安全性的修改都记录下来方便后续审计或恢复。7.4 后续可以扩展的方向如果你经常需要处理这类问题可以进一步了解几个方向一是 SMB over QUIC这是较新版本 Windows 引入的远程访问方案二是 SMB 加密的配置和性能影响三是用 PowerShell DSC 或组策略统一管理多台机器的 SMB 配置避免一台台手动改。另外如果你在虚拟机环境里遇到共享文件夹问题比如 VMware 或 Hyper-V 的共享文件夹那和 SMB 共享是两套机制排查思路完全不同。虚拟机共享文件夹更多是驱动和挂载配置的问题不要和 SMB 混在一起查。最后分享一个小技巧在排查任何 SMB 问题时养成先运行Get-SmbConnection的习惯。它一行输出就能告诉你当前连到了哪台服务器、用的什么版本、有没有签名、有没有加密。这个信息量比点十次图形界面都大。
Windows 11 共享文件夹报“扩展错误”？SMB 签名与协议协商排查指南
1. 从一次真实的“扩展错误”说起上周帮朋友处理一台新装的 Windows 11 机器他想访问公司内网一台老文件服务器上的共享目录输入\\192.168.1.20\public之后系统弹出一个让人摸不着头脑的提示“出现了扩展错误”。没有错误代码没有详细说明就这六个字。点确定之后重试还是同样的结果。更诡异的是同一台机器用 IP 能 ping 通用另一台 Windows 10 的电脑访问同一个共享却完全正常。这个场景其实非常典型。Windows 11 在共享访问这块做了不少安全层面的收紧尤其是SMB 签名SMB Signing相关的策略默认行为和 Win10 时代有了明显差异。很多从 Win10 升级上来、或者新装 Win11 的用户第一次遇到“出现了扩展错误”时完全不知道从哪下手网上搜到的答案又大多是“改注册表”“关防火墙”这类笼统建议试了一圈还是没解决。这篇内容就是把这个问题的来龙去脉讲清楚它到底是怎么产生的、为什么 Win11 特别容易触发、以及一套从快到慢、从安全到激进的排查路径。涉及的关键词包括Windows 11、共享文件夹、SMB 签名、扩展错误、PowerShell。不管你是普通家庭用户想访问 NAS还是企业 IT 在维护混合系统环境这套思路都能直接拿去用。需要先说明一点下面所有操作都基于我实际处理过的案例总结不同环境域环境、工作组、NAS 品牌、服务器系统版本可能细节有差异但排查逻辑是通用的。我会在每个步骤里说明“为什么这么做”而不是只丢一串命令给你。2. “扩展错误”到底是个什么错误2.1 它不是网络不通而是协商失败很多人看到“扩展错误”第一反应是网络问题于是去 ping、去查网线、去重启路由器。但如果你能 ping 通目标 IP甚至能用telnet 目标IP 445测通端口那问题基本不在网络层。“出现了扩展错误”这个提示本质上是SMB 协议在会话建立或认证协商阶段失败之后Windows 抛出的一个笼统错误。它不像0x80070035找不到网络路径那样指向明确也不像0x80070005拒绝访问那样指向权限。它更像是一个“兜底提示”——系统知道出问题了但没法用一句话说清楚。从实际抓包和日志分析的经验看触发这个提示最常见的原因集中在三类SMB 签名策略不匹配客户端要求签名服务端不支持或配置不一致。SMB 版本协商失败Win11 默认优先 SMB 3.x老设备可能只支持 SMB 1.0/2.0。凭据或安全策略冲突比如 NTLM 被限制、来宾访问被禁用、凭据管理器里存了错误的旧密码。提示如果你在事件查看器里看到Microsoft-Windows-SMBClient相关的警告或错误那基本可以确认是 SMB 层的问题而不是单纯的网络问题。2.2 为什么 Windows 11 特别容易踩这个坑Win11 相比 Win10在 SMB 安全策略上有几个关键变化这些变化正是“扩展错误”频发的根源。第一SMB 签名默认要求更严格。在 Win10 时代客户端对签名的要求相对宽松很多场景下可以协商降级。但 Win11 在部分版本尤其是较新的 22H2、23H2、24H2中对 SMB 签名的默认策略做了调整当服务端不支持签名或签名配置不匹配时协商就会直接失败而不是像以前那样“降级继续”。第二SMB 1.0/CIFS 默认被移除或禁用。很多老 NAS、老打印机、老文件服务器还在用 SMB 1.0。Win11 默认不再安装 SMB 1.0 支持访问这类设备时就会在协商阶段卡住。第三来宾访问Guest默认被禁用。以前访问共享如果没输密码系统可能会尝试用 Guest 账户。Win11 默认禁止了不安全的来宾登录这也会导致协商失败。第四NTLM 的限制。部分企业环境或安全加固过的系统会限制 NTLM 认证而很多老设备只支持 NTLM这同样会触发扩展错误。理解了这四点你就明白为什么“同一台服务器Win10 能访问Win11 不行”——不是 Win11 坏了而是它的安全默认值变了。2.3 先做这三件事快速缩小范围在动手改任何配置之前先做三个基础判断能帮你省掉大量瞎折腾的时间。第一确认目标共享本身是好的。用另一台能正常访问的电脑最好是 Win10 或同版本 Win11访问同一个共享路径。如果那台也访问不了问题在服务端不在你的 Win11 客户端。第二确认你用的是 IP 还是主机名。有些环境里主机名解析有问题用 IP 能通、用主机名不行。反过来也有。两种都试一下能排除 DNS/NetBIOS 层面的干扰。第三确认凭据是否正确。打开“凭据管理器”控制面板 → 用户账户 → 凭据管理器 → Windows 凭据看看有没有针对目标服务器保存的旧凭据。如果有先删掉再重试。这一步经常被忽略但实际排查中命中率不低。做完这三步如果问题依旧那就进入下面的正式排查流程。3. 用 PowerShell 定位 SMB 协商的真实状态3.1 为什么优先用 PowerShell 而不是图形界面图形界面能看的信息太少了。你点“映射网络驱动器”失败了就一个弹窗没有任何细节。而 PowerShell 里的 SMB 相关 cmdlet 能直接告诉你当前客户端支持哪些 SMB 版本、签名策略是什么、和目标服务器的会话状态如何。更重要的是PowerShell 的输出是可复制、可对比的。你可以把排查前后的输出贴在一起看差异这对定位问题非常关键。打开 PowerShell 的方式按Win X选择“终端”或“Windows PowerShell”。建议用管理员权限运行因为部分查询和修改需要提权。3.2 查看客户端 SMB 配置先看客户端这边的全局配置Get-SmbClientConfiguration这个命令会输出一堆参数重点看这几个参数含义关注点RequireSecuritySignature是否强制要求 SMB 签名如果为 True服务端不支持签名就会失败EnableSecuritySignature是否启用签名通常为 TrueEnableInsecureGuestLogons是否允许不安全的来宾登录Win11 默认 FalseEnableSMB1Protocol是否启用 SMB 1.0Win11 默认 FalseEnableSMB2Protocol是否启用 SMB 2.x/3.x通常为 True如果你看到RequireSecuritySignature是 True而目标服务器是老设备那基本就是它了。再看客户端支持的 SMB 版本Get-SmbClientConfiguration | Select-Object -Property *或者更直接地查协议版本支持情况Get-SmbClientConfiguration | Format-List3.3 查看当前 SMB 会话和连接如果之前尝试过连接可以看看有没有残留的会话Get-SmbConnection Get-SmbSessionGet-SmbConnection显示的是当前已建立的连接包括用的 SMB 版本、签名状态、加密状态。如果目标服务器出现在列表里但状态异常那信息就很有价值。如果连接根本没建立起来这两个命令可能返回空。这时候可以尝试主动发起连接并观察net use \\192.168.1.20\public /user:用户名 密码注意net use在 PowerShell 里也能用它的报错信息有时比图形界面更具体。如果返回“系统错误 64”或“系统错误 53”那指向的是网络层如果返回“系统错误 5”那是权限问题如果还是“出现了扩展错误”那继续往下查。3.4 查看 SMB 相关的事件日志PowerShell 也能直接读事件日志这比在图形界面里一层层点要快得多Get-WinEvent -LogName Microsoft-Windows-SMBClient/Operational -MaxEvents 20如果这个日志没启用可以用Get-WinEvent -LogName Microsoft-Windows-SMBClient/Connectivity -MaxEvents 20重点找 Event ID 30803、30804 这类和签名、协商相关的记录。日志里通常会写明“签名要求不匹配”或“协议版本协商失败”之类的具体原因。这一步是定位问题的关键很多人跳过日志直接改配置结果改了一堆无关的东西。提示如果事件日志里明确写了“SMB 签名”相关字样那第 4 节的方案就是对症的。如果写的是“协议版本”那重点在第 5 节。4. SMB 签名不匹配的完整处理路径4.1 先判断是客户端要求太严还是服务端不支持SMB 签名问题的核心矛盾是一方要求签名另一方不支持或没启用。所以处理方向有两个——要么放宽客户端要求要么在服务端启用签名。从安全角度优先考虑在服务端启用签名而不是在客户端关掉要求。因为签名本身是为了防止中间人篡改关掉它是降低安全性。但如果服务端是老设备比如老 NAS、老打印机根本不支持签名那就只能在客户端侧做妥协。判断方法在能正常访问该共享的机器上运行Get-SmbConnection看输出的Signed列是 True 还是 False。如果是 False说明这个共享本身就没在用签名那 Win11 客户端要求签名就会失败。4.2 客户端侧放宽签名要求的操作如果确认是客户端要求过严可以用 PowerShell 调整Set-SmbClientConfiguration -RequireSecuritySignature $false执行后可能需要确认输入Y回车。这个命令把“强制要求签名”关掉但签名本身还是启用的EnableSecuritySignature仍为 True只是不再强制。这样兼容性更好安全性损失也相对可控。如果想进一步确认当前状态Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature改完之后先断开已有连接再重试net use * /delete /y然后重新访问共享。如果问题解决说明就是签名策略的问题。注意这个修改是全局的会影响这台机器访问所有 SMB 共享的行为。如果你的机器同时要访问安全性要求高的服务器建议改完后记录一下必要时再改回来。4.3 服务端启用签名的思路如果条件允许更好的做法是在服务端启用 SMB 签名。以 Windows Server 为例Set-SmbServerConfiguration -RequireSecuritySignature $true但这里有个坑如果服务端强制要求签名而某些老客户端不支持那些老客户端就会反过来访问不了。所以服务端改签名策略前一定要确认所有需要访问的客户端都支持签名。对于 NAS 设备签名设置通常在管理界面的“文件服务”或“SMB 设置”里不同品牌位置不一样。群晖一般在“控制面板 → 文件服务 → SMB → 高级设置”威联通在“控制面板 → 网络和文件服务 → Win/Mac/NFS → Microsoft 网络”。找“启用 SMB 签名”或“SMB 签名”相关选项。4.4 一个容易被忽略的点加密和签名的关系SMB 3.x 引入了加密功能而加密和签名在某些配置下会互相影响。如果服务端启用了 SMB 加密客户端在协商时可能会因为加密算法不匹配而失败报错也可能表现为“扩展错误”。查看加密相关配置Get-SmbClientConfiguration | Select-Object EncryptionCiphers Get-SmbServerConfiguration | Select-Object EncryptionCiphers如果两边支持的加密算法集合没有交集协商就会失败。这种情况在混合了较新 Windows 和老 NAS 的环境里偶有出现。处理方式是调整其中一方的加密算法列表或者升级固件/系统。5. SMB 协议版本协商失败的排查5.1 确认目标设备支持哪个 SMB 版本如果签名不是问题那下一个重点就是协议版本。Win11 默认优先使用 SMB 3.x如果目标设备只支持 SMB 1.0 或 2.0协商就可能失败。判断目标设备支持什么版本最直接的方法是看能正常访问它的那台机器上Get-SmbConnection的输出Get-SmbConnection | Select-Object ServerName, DialectDialect列会显示类似3.1.1、3.0.2、2.1、1.0这样的值。如果显示的是1.0或2.x而你的 Win11 默认没启用对应支持那就是问题所在。5.2 启用 SMB 1.0 的正确姿势与风险SMB 1.0 是个安全性很差的协议微软一直在推动淘汰它。Win11 默认不安装 SMB 1.0 支持。如果你的目标设备确实只支持 SMB 1.0需要手动启用。在“启用或关闭 Windows 功能”里找到“SMB 1.0/CIFS 文件共享支持”勾选后重启。或者用 PowerShellEnable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -All执行后需要重启。但这里必须强调启用 SMB 1.0 会显著降低安全性因为它存在已知的严重漏洞。如果只是临时访问一台老设备用完建议关掉Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol更好的替代方案是如果那台老设备支持固件升级优先升级到支持 SMB 2.0 或 3.0 的版本。很多老 NAS 通过固件更新是能支持更高版本的。5.3 SMB 2.0/3.0 的启用与禁用如果目标设备支持 SMB 2.0 但不支持 3.0而 Win11 在协商时优先尝试 3.0 失败后没有正确回退也可能出问题。可以尝试临时禁用 SMB 3.0 来强制走 2.0Set-SmbClientConfiguration -EnableSMB2Protocol $true注意SMB 2.x 和 3.x 是共用EnableSMB2Protocol这个开关的没法单独只关 3.0 保留 2.0。所以这个方向的操作空间有限更多是确认它处于启用状态。如果确认是版本协商问题且服务端无法升级那实际可行的方案往往就是启用 SMB 1.0临时或者更换服务端设备。5.4 用抓包确认协商过程如果前面都排查了还是没头绪可以上抓包工具。Wireshark 是最常用的过滤条件用smb2或smb。抓包能看到协商请求和响应里双方各自支持的版本列表以及在哪一步失败。这个信息比任何日志都直接。不过抓包有一定门槛适合已经排除了常见原因、需要深入定位的场景。一个更轻量的替代方案是用 Windows 自带的netsh抓包netsh trace start captureyes tracefileC:\smb_trace.etl复现问题后netsh trace stop然后用事件查看器或网络监视器打开 etl 文件分析。这个方式不用装额外软件适合在客户现场快速取证。6. 凭据、来宾访问与安全策略的干扰6.1 凭据管理器里的旧密码是隐形杀手这个坑我踩过不止一次。之前访问过某台服务器保存了凭据后来服务器密码改了但凭据管理器里还是旧的。Win11 在访问时会用旧凭据去认证认证失败后报的却是“扩展错误”而不是明确的“密码错误”。清理方法cmdkey /list这个命令列出所有保存的凭据。找到目标服务器的条目然后cmdkey /delete:目标服务器IP或名称删掉之后重新访问系统会重新提示输入凭据。图形界面路径是控制面板 → 用户账户 → 凭据管理器 → Windows 凭据。找到对应条目删除即可。6.2 来宾访问被禁用导致的协商失败Win11 默认禁止不安全的来宾登录。如果目标共享允许匿名访问很多 NAS 的公共目录是这样Win11 会因为策略限制而拒绝用来宾身份连接。查看当前设置Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons如果返回 False而你需要访问的共享确实依赖来宾访问可以临时启用Set-SmbClientConfiguration -EnableInsecureGuestLogons $true同样这是降低安全性的操作。更推荐的做法是在服务端为共享设置一个专用账户用账户密码访问而不是依赖来宾。6.3 NTLM 限制与安全策略在企业环境里组策略可能限制了 NTLM 的使用。如果目标服务器只支持 NTLM 认证而客户端被策略禁止使用 NTLM协商就会失败。检查本地安全策略secpol.msc→ 本地策略 → 安全选项 → “网络安全: 限制 NTLM”。如果这里配置了限制而目标设备需要 NTLM就需要调整。不过这个方向涉及域策略的情况比较多普通家庭用户一般不会遇到。如果你在公司网络里遇到建议先问一下 IT 是否有相关策略。6.4 防火墙和端口转发的排查虽然“扩展错误”通常不是防火墙直接导致的但防火墙拦截了 SMB 协商所需的某些端口也可能间接引发。SMB 主要用 445 端口老版本可能用 139。测试端口连通性Test-NetConnection -ComputerName 192.168.1.20 -Port 445如果TcpTestSucceeded是 False那先解决端口连通问题。如果 True说明端口是通的问题在协议层。有些环境里做了端口转发比如把外部的某个端口转发到内部的 445。这种情况下SMB 协商可能会因为地址转换而出现异常。如果必须走端口转发建议确认转发规则是否正确以及是否支持 SMB 所需的双向通信。7. 一套可复用的排查顺序与经验总结7.1 从快到慢的排查清单把前面的内容整理成一个可执行的顺序遇到“扩展错误”时按这个顺序走基础确认ping 通不通、445 端口通不通、换台机器能不能访问。清理凭据cmdkey /list看有没有旧凭据有就删。看日志Get-WinEvent查 SMBClient 日志找具体原因。查签名Get-SmbClientConfiguration看RequireSecuritySignature。查版本在能访问的机器上看Get-SmbConnection的Dialect。查来宾确认EnableInsecureGuestLogons状态。改配置根据前面定位的原因针对性调整。抓包前面都无效时用抓包看协商细节。这个顺序的核心逻辑是先排除最简单的再处理需要改配置的最后才上重型工具。很多人一上来就改注册表、关防火墙结果把环境搞乱了问题还没解决。7.2 几个我实际踩过的坑坑一改了客户端签名忘了重启相关服务。改完Set-SmbClientConfiguration后有时候需要重启Workstation服务或者重启机器才生效。我遇到过改完没反应重启后就好了的情况。坑二以为所有 Win11 版本行为一致。不同 Win11 版本21H2、22H2、23H2、24H2在 SMB 默认策略上有细微差异。尤其是企业版和专业版可能还受组策略影响。所以别人的解决方案在你机器上不一定直接有效要结合自己的版本判断。坑三忽略了服务端的日志。如果服务端也是 Windows它的 SMB 日志同样有价值。在服务端运行Get-WinEvent -LogName Microsoft-Windows-SMBServer/Operational能看到它那边记录的协商失败原因。两边日志对照定位会快很多。坑四在域环境里用本地账户思路排查。域环境下的认证走的是域控凭据、策略、信任关系都可能影响。域环境遇到这个问题优先检查域信任和组策略而不是本地 SMB 配置。7.3 关于安全性的取舍建议整个排查过程中很多操作是在“兼容性”和“安全性”之间做取舍。我的建议是能升级服务端就升级让老设备支持更高版本的 SMB这是最优解。能用在服务端启用签名解决的就不要在客户端关签名要求。SMB 1.0 只在临时场景启用用完就关。来宾访问能不用就不用给共享设个专用账户更安全。所有降低安全性的修改都记录下来方便后续审计或恢复。7.4 后续可以扩展的方向如果你经常需要处理这类问题可以进一步了解几个方向一是 SMB over QUIC这是较新版本 Windows 引入的远程访问方案二是 SMB 加密的配置和性能影响三是用 PowerShell DSC 或组策略统一管理多台机器的 SMB 配置避免一台台手动改。另外如果你在虚拟机环境里遇到共享文件夹问题比如 VMware 或 Hyper-V 的共享文件夹那和 SMB 共享是两套机制排查思路完全不同。虚拟机共享文件夹更多是驱动和挂载配置的问题不要和 SMB 混在一起查。最后分享一个小技巧在排查任何 SMB 问题时养成先运行Get-SmbConnection的习惯。它一行输出就能告诉你当前连到了哪台服务器、用的什么版本、有没有签名、有没有加密。这个信息量比点十次图形界面都大。
