博客主页https://blog.csdn.net/wkd_007博客内容嵌入式开发、Linux、C语言、C、数据结构、音视频本文内容介绍解决samba连接不了的问题排查过程 金句分享你不能选择最好的但最好的会来选择你——泰戈尔⏰发布时间⏰本文未经允许不得转发目录一、概述二、排查过程逐步逼近真相✨2.1 基础排查用户密码与凭据缓存✨2.2 修改 Windows 本地安全策略无效尝试✨2.3 服务端日志分析没有认证记录✨2.4 网络抓包锁定协议协商失败✨2.5 最小化配置测试找到突破口✨2.6 深入理解NTLMv1 vs NTLMv2✨2.7 为什么修改 Windows 安全策略无效三、根本原因总结✨方法一在 Wireshark 中分析 NTLMSSP_AUTH 包✨方法二查询 Windows 注册表 LmCompatibilityLevel四、解决方案✨4.1 方案一在 Samba 服务端启用 NTLMv1本文采用快速修复✨4.2 方案二强制 Windows 使用 NTLMv2推荐彻底解决五、经验教训与排查心得六、结语一、概述最近在 Ubuntu 22.04 上配置 Samba 服务器时遇到了一个令人头疼的问题按照网络教程配置好后Windows 客户端始终提示“用户名或密码错误”而另一台 Ubuntu 18.04 服务器用同样的配置却能正常访问。将现象反馈给 DeepSeek 后它建议我从用户密码、服务端日志、网络抓包一步步排查最终定位到是 NTLM 认证协议版本不匹配所致。本文将完整记录这次排查过程希望能帮助遇到类似问题的朋友少走弯路。环境与现象项目信息服务端Ubuntu 22.04 LTS Samba 4.15客户端Windows 10用户wkd共享路径/home/wkd/share现象描述在 Windows 资源管理器输入\\192.168.2.xx\wkd弹出凭据窗口就已提示“拒绝访问”。输入正确的用户名wkd和 Samba 密码点击确定后立即提示“用户名或密码错误”。同事的电脑可以正常连接同一台 Ubuntu 22.04 服务器。我自己的电脑可以正常连接另一台 Ubuntu 18.04 服务器。在 Ubuntu 22.04 上执行smbclient -L localhost -U wkd能正常列出共享说明 Samba 服务自身没问题。初步判断问题不是用户密码错误而是我电脑与 Ubuntu 22.04 之间的认证通道出了兼容性问题。将情况告知 DeepSeek它回复说这种情况很可能是认证协议或 SMB 协议版本不匹配导致的需要逐层排查。二、排查过程逐步逼近真相✨2.1 基础排查用户密码与凭据缓存按照 DeepSeek 的指导首先确认 Samba 用户和密码sudosmbpasswd-awkd# 重新设置密码然后在 Windows 上打开“凭据管理器”删除所有与192.168.2.xx相关的凭据。以管理员身份运行命令提示符执行net use # 查看当前网络连接 net use \\192.168.2.xx\samba /del # 删除指定的网络连接 net use * /del /y cmdkey /delete:192.168.2.xx重启电脑后重新尝试连接。结果问题依旧。✨2.2 修改 Windows 本地安全策略无效尝试DeepSeek 查阅资料后告诉我Windows 的 LAN Manager 认证级别可能影响 SMB 连接。于是尝试修改本地安全策略运行secpol.msc打开本地安全策略。依次展开本地策略 → 安全选项。找到“网络安全: LAN Manager 身份验证级别”将其从默认值修改为“发送 LM 和 NTLM – 如果已协商则使用 NTLMv2 会话安全”这是一个兼容性较高的级别。执行gpupdate /force并重启电脑。再次测试依然提示“用户名或密码错误”。将结果反馈给 DeepSeek它分析说这说明问题不在 Windows 这一侧的简单策略设置上可能是协议协商更底层的环节出了问题。✨2.3 服务端日志分析没有认证记录DeepSeek 建议开启 Samba 详细日志看能否捕捉到认证失败的具体原因sudovi/etc/samba/smb.conf# 在 [global] 中添加log level3passdb:5 auth:10sudosystemctl restart smbd然后让 Windows 尝试连接再查看日志sudotail-50/var/log/samba/log.smbd输出如下[2026/05/22 19:08:59.344393, 3] ../../lib/util/access.c:372(allow_access) Allowed connection from 192.168.2.180 (192.168.2.180) ...后续再无关于这个 IP 的认证日志关键发现日志中只有Allowed connection没有任何check_ntlm_password、NT_STATUS_*等认证尝试的记录。将结果反馈给 DeepSeek它回复说这意味着 Windows 客户端虽然建立了 TCP 连接但 SMB 认证请求根本没有到达 Samba 的用户认证阶段很可能是在协议协商阶段就失败了。✨2.4 网络抓包锁定协议协商失败DeepSeek 说为了看清底层到底发生了什么需要在服务器上用tcpdump抓包并在 Windows 上用 Wireshark 抓包对照分析。在服务器上执行sudotcpdump-iens160-nhost192.168.2.180 and port445-vv在 Windows 上DeepSeek 让我使用 Wireshark 抓包过滤器输入ip.addr 192.168.2.89 tcp.port 445。结果分析TCP 三次握手正常完成SYN, SYN-ACK, ACK。Windows 发送了SMB Negotiate Protocol Request其中包含支持的 dialectsSMB1 到 SMB2.???。服务器回复了一些数据包但最终 Windows 发出了RST包中断连接。在 Wireshark 中查看Negotiate Protocol Response包没有找到说明服务器根本没有给出有效的 SMB 协商响应。将抓包结果反馈给 DeepSeek它说这意味着SMB 协议协商阶段就失败了根本没有进入到用户身份验证阶段。难怪服务端日志里看不到认证记录。✨2.5 最小化配置测试找到突破口DeepSeek 建议创建一个最小化配置文件来排除原配置中的复杂参数干扰。于是备份原配置sudomv/etc/samba/smb.conf /etc/samba/smb.conf.baksudovi/etc/samba/smb.conf按照 DeepSeek 给出的配置模板写入以下内容[global] workgroup WORKGROUP security user map to guest Bad User server min protocol NT1 ntlm auth yes [wkd] path /home/wkd/share browseable yes read only no valid users wkd force user wkd重启 Sambasudosystemctl restart smbd神奇的一幕出现了Windows 居然可以正常连接了接下来我按照 DeepSeek 的建议将原配置中的参数逐行加回这个最小配置试图定位是哪个参数起了决定性作用。最终发现加上ntlm auth yes→ 连接成功。去掉ntlm auth yes→ 连接失败回到“用户名或密码错误”。结论关键在于ntlm auth yes这个参数。✨2.6 深入理解NTLMv1 vs NTLMv2将这一发现反馈给 DeepSeek它查阅资料后解释说Ubuntu 18.04搭载的 Samba 版本4.7.6对 NTLMv1 的限制较宽松默认允许。Ubuntu 22.04搭载的 Samba 版本4.15出于安全考虑默认将ntlm auth设置为ntlmv2-only即拒绝 NTLMv1只接受 NTLMv2。从 Samba 4.5 版本开始官方就出于安全考虑将ntlm auth的默认值从yes改为了no。到了 Ubuntu 22.04 搭载的 Samba 4.15更是默认ntlmv2-only实际上完全禁止了 NTLMv1 的使用。而我的 Windows 客户端即使修改了本地安全策略在某些情况下仍会尝试使用 NTLMv1 进行认证可能是历史原因、组策略未完全生效、或者某些应用程序强制要求。当它连接到 Ubuntu 22.04 时Samba 因为默认拒绝 NTLMv1导致 SMB 协商无法完成从而表现为“用户名或密码错误”。同事的电脑可能因为之前修改过策略允许 NTLMv2或者其 Windows 版本/配置恰好兼容所以能连上。✨2.7 为什么修改 Windows 安全策略无效DeepSeek 分析说我之前将 LAN Manager 身份验证级别改为了“发送 LM 和 NTLM – 如果已协商则使用 NTLMv2 会话安全”级别 2。这个级别依然允许 NTLMv1并不是完全拒绝 NTLMv1。因此 Windows 仍然可能优先或协商使用 NTLMv1而 Ubuntu 22.04 却拒绝了它。真正能让 Windows 只使用 NTLMv2 的级别是“仅发送 NTLMv2 响应。拒绝 LM 和 NTLM”级别 5。但当时我没有设置到这么高所以问题依然存在。三、根本原因总结组件行为结果Windows 客户端尝试使用 NTLMv1 进行 SMB 认证发送的认证请求不兼容Ubuntu 22.04 Samba默认ntlm auth ntlmv2-only拒绝 NTLMv1直接拒绝协商不进入密码验证流程错误提示“用户名或密码错误”误导性提示实际是协议不匹配一句话概括Ubuntu 22.04 Samba 默认关闭了 NTLMv1 支持而 Windows 客户端仍在使用 NTLMv1导致 SMB 协议协商失败被误报为“用户名或密码错误”。补充验证如何判断客户端使用的是 NTLMv1 还是 NTLMv2在排查过程中为了进一步确认客户端的 NTLM 版本我采用了以下两种方法✨方法一在 Wireshark 中分析 NTLMSSP_AUTH 包在 Wireshark 中找到Session Setup Request, NTLMSSP_AUTH包。依次展开SMB2 (Server Message Block Protocol v2)Session Setup RequestSecurity Blob (GSS-API)NTLM Secure Service Provider (NTLMSSP)NTLMv2 Response或NTLM Response取决于版本展开NTLM Secure Service Provider→ 查看NTLM Response字段的Length如果Length 24 字节→ 客户端使用的是NTLMv1。如果Length 24 字节且字段名为NTLMv2 Response→ 客户端使用的是NTLMv2。我的抓包中NTLM Response长度为 24明确表明客户端发送的是 NTLMv1。✨方法二查询 Windows 注册表LmCompatibilityLevel在 Windows PowerShell 中执行以下命令Get-ItemProperty-PathHKLM:\SYSTEM\CurrentControlSet\Control\Lsa-NameLmCompatibilityLevel返回的数值含义如下值策略级别含义0 或不存在级别 0发送 LM 和 NTLM 响应允许 v11级别 1发送 LM 和 NTLM 响应允许 v1我的电脑当前值2级别 2仅发送 NTLM 响应仍允许 v13级别 3仅发送 NTLMv2 响应但可能接受 v15级别 5仅发送 NTLMv2 响应拒绝 LM 和 NTLM完全禁用 v1我的电脑LmCompatibilityLevel 1证实了客户端强制使用 NTLMv1与 Wireshark 抓包结果完全一致。四、解决方案✨4.1 方案一在 Samba 服务端启用 NTLMv1本文采用快速修复编辑/etc/samba/smb.conf在[global]部分添加ntlm auth yes重启 Sambasudosystemctl restart smbd优点无需改动 Windows 客户端立即生效。缺点NTLMv1 安全性较低56 位加密容易被中间人攻击。仅建议在内网可信环境中临时使用。✨4.2 方案二强制 Windows 使用 NTLMv2推荐彻底解决修改 Windows 本地安全策略彻底拒绝 NTLMv1运行secpol.msc。本地策略 → 安全选项 → “网络安全: LAN Manager 身份验证级别”。设置为“仅发送 NTLMv2 响应。拒绝 LM 和 NTLM”级别 5。运行gpupdate /force并重启电脑。之后可以将 Samba 的ntlm auth恢复为默认或注释掉该行连接依然正常。优点提升网络安全符合微软安全基线。缺点可能需要批量修改客户端老旧的设备如 Windows XP可能无法连接。五、经验教训与排查心得最小化配置是调试利器samba是很成熟的共享技术了出现问题时先尝试最小化的配置还有问题再继续分析。当复杂配置不工作时从一个最简配置开始逐步增加参数能快速定位问题参数。“用户名或密码错误”不一定是密码问题DeepSeek 指出遇到此类提示优先查看服务端日志是否有认证记录。如果没有基本可以确定是协议或会话建立阶段的问题。抓包是终极手段当日志信息不足时tcpdump和 Wireshark 能清晰展现 TCP 握手、SMB 协商过程快速定位是服务器没响应还是客户端主动中断。新旧版本的差异不容忽视Ubuntu 18.04 和 22.04 虽然都是 LTS但 Samba 默认安全策略已发生重大变化。生产环境升级前务必测试。修改 Windows 策略时要注意级别含义不是所有“允许 NTLMv2”的级别都会拒绝 NTLMv1只有级别 5 才是真正拒绝。六、结语通过这次排查我深刻体会到在遇到网络共享问题时不要被表面的错误提示迷惑。从基础的用户密码检查到服务端日志分析再到网络抓包最后通过对比不同版本行为锁定根本原因每一步都不可或缺。AI 在这个过程中给我提供的详细指导和分析思路。最终我选择了在 Ubuntu 22.04 的smb.conf中添加ntlm auth yes作为临时方案。如果你也遇到同样情况可以根据自己的网络环境选择上述任一解决方案。如果文章有帮助的话点赞、收藏⭐支持一波谢谢