断开连接报错的根本原因是共享权限和ntfs权限未同时放行，二者为“与”关系；需检查高级共享权限和安全选项卡中同一用户的对应权限，确认身份验证格式（如desktop-abcdmin）、组成员关系、smb协议兼容性及server/workstation服务状态，并清除旧凭据。

断开连接报错，不是网络突然中断，而是系统在权限校验环节直接拒绝了访问请求——根本原因是共享权限和 ntfs 权限没对齐，其中任一层拒绝，就会“卡住”，显示“拒绝访问”“无权限”或反复弹出凭据窗口。

确认两层权限是否都放行

Windows 共享访问必须同时通过“共享权限”和“NTFS 权限”两道关卡，二者是“与”关系，不是“或”。哪怕共享层给了“完全控制”，但 NTFS 层没给读取，照样打不开。

• 右键共享文件夹 → “属性” → “共享”选项卡 → “高级共享” → “权限”：检查目标用户（如 Everyone、DESKTOP-ABCAdmin 或具体用户名）是否被明确赋予“读取”或更高权限
• 切换到“安全”选项卡 → “编辑” → “添加”：输入同一用户（注意格式一致），确保其拥有至少“读取和执行”+“列出文件夹内容”+“读取”（只读）；如需写入，再加“修改”或“完全控制”
• 特别提醒：如果添加的是组（如 Users），要确认当前登录用户确实属于该组；用 Microsoft 账户登录时，建议额外建一个本地账户（如 shareuser），并在两层权限中都显式添加它

检查身份验证方式是否匹配

权限配置正确，但系统压根没走你设的那条路——常见于凭据格式错误或策略限制。

• 访问时不要只输用户名，而要输完整格式：计算机名用户名（如 DESKTOP-ABCshareuser）或 .用户名（本地账户）
• 共享端必须存在该用户，且密码非空；Win10/11 默认禁用空密码来宾访问，若关闭了“密码保护的共享”，仍提示拒绝，大概率是账号不存在或密码不匹配
• 若用 IP 访问（如 \192.168.1.50Share）却提示“未授予登录类型”，请检查组策略：gpedit.msc → 计算机配置 → 安全设置 → 本地策略 → 安全选项 → 网络访问：本地账户的共享和安全模型，应设为“经典-对本地用户进行身份验证”，而非“仅来宾”

验证 SMB 协议与服务状态

权限再对，底层协议不通或服务停摆，连校验环节都进不去。

• 确保 Server 和 Workstation 服务正在运行（services.msc 中查看）；Function Discovery Resource Publication 也建议启用
• 旧设备（如 NAS、Win7）可能依赖 SMBv1，而 Win10/11 20H2 后默认禁用。如需兼容，打开“启用或关闭 Windows 功能”，勾选 SMB 1.0/CIFS 文件共享支持，并重启
• 若连接后短暂可用随即断开，可能是 SMB 客户端强制签名导致：以管理员身份运行 PowerShell，执行 Set-SmbClientConfiguration -RequireSecuritySignature $false

绕过干扰快速定位问题

先排除干扰项，再精细调整，避免在错误方向上反复折腾。

• 临时关闭 Windows Defender 防火墙，或确保“文件和打印机共享”在专用/公用网络中均被允许（端口 445/TCP 必须通）
• 在客户端命令行执行 net use Z: \192.168.1.50Share /user:shareuser password，用明确凭据挂载，比资源管理器双击更可靠
• 清除凭据管理器中旧的、错误的共享凭据（控制面板 → 用户账户 → 凭据管理器 → Windows 凭据），避免系统复用失效凭据