Ubuntu 22.04 Samba 连接故障排查记：从“用户名或密码错误”到 NTLM 版本不兼容

😁博客主页😁：🚀https://blog.csdn.net/wkd_007🚀

🤑博客内容🤑：🍭嵌入式开发、Linux、C语言、C++、数据结构、音视频🍭

🤣本文内容🤣：🍭介绍解决samba连接不了的问题排查过程 🍭

😎金句分享😎：🍭你不能选择最好的，但最好的会来选择你------泰戈尔🍭

⏰发布时间⏰：

本文未经允许，不得转发！！！

🎄一、概述
🎄二、排查过程（逐步逼近真相）
- [✨2.1 基础排查：用户密码与凭据缓存](#✨2.1 基础排查：用户密码与凭据缓存)
- [✨2.2 修改 Windows 本地安全策略（无效尝试）](#✨2.2 修改 Windows 本地安全策略（无效尝试）)
- [✨2.3 服务端日志分析：没有认证记录](#✨2.3 服务端日志分析：没有认证记录)
- [✨2.4 网络抓包：锁定协议协商失败](#✨2.4 网络抓包：锁定协议协商失败)
- [✨2.5 最小化配置测试：找到突破口](#✨2.5 最小化配置测试：找到突破口)
- [✨2.6 深入理解：NTLMv1 vs NTLMv2](#✨2.6 深入理解：NTLMv1 vs NTLMv2)
- [✨2.7 为什么修改 Windows 安全策略无效？](#✨2.7 为什么修改 Windows 安全策略无效？)
🎄三、根本原因总结
- [✨方法一：在 Wireshark 中分析 NTLMSSP_AUTH 包](#✨方法一：在 Wireshark 中分析 NTLMSSP_AUTH 包)
- [✨方法二：查询 Windows 注册表 `LmCompatibilityLevel`](#✨方法二：查询 Windows 注册表 LmCompatibilityLevel)
🎄四、解决方案
- [✨4.1 方案一：在 Samba 服务端启用 NTLMv1（本文采用，快速修复）](#✨4.1 方案一：在 Samba 服务端启用 NTLMv1（本文采用，快速修复）)
- [✨4.2 方案二：强制 Windows 使用 NTLMv2（推荐，彻底解决）](#✨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 用户和密码：

bash 复制代码

sudo smbpasswd -a wkd   # 重新设置密码

然后在 Windows 上：

打开"凭据管理器"，删除所有与 192.168.2.xx 相关的凭据。

以管理员身份运行命令提示符，执行：

cmd 复制代码

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 详细日志，看能否捕捉到认证失败的具体原因：

bash 复制代码

sudo vi /etc/samba/smb.conf
# 在 [global] 中添加：
log level = 3 passdb:5 auth:10
sudo systemctl restart smbd

然后让 Windows 尝试连接，再查看日志：

bash 复制代码

sudo tail -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 抓包对照分析。

在服务器上执行：

bash 复制代码

sudo tcpdump -i ens160 -n host 192.168.2.180 and port 445 -vv

在 Windows 上，DeepSeek 让我使用 Wireshark 抓包，过滤器输入：ip.addr == 192.168.2.89 && tcp.port == 445。

结果分析：

TCP 三次握手正常完成（SYN, SYN-ACK, ACK）。
Windows 发送了 SMB Negotiate Protocol Request，其中包含支持的 dialects（SMB1 到 SMB2.???）。
服务器回复了一些数据包，但最终 Windows 发出了 RST 包中断连接。
在 Wireshark 中查看 Negotiate Protocol Response 包，没有找到，说明服务器根本没有给出有效的 SMB 协商响应。

将抓包结果反馈给 DeepSeek，它说这意味着 SMB 协议协商阶段就失败了，根本没有进入到用户身份验证阶段。难怪服务端日志里看不到认证记录。

✨2.5 最小化配置测试：找到突破口

DeepSeek 建议创建一个最小化配置文件来排除原配置中的复杂参数干扰。于是备份原配置：

bash 复制代码

sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
sudo vi /etc/samba/smb.conf

按照 DeepSeek 给出的配置模板，写入以下内容：

ini 复制代码

[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

重启 Samba：

bash 复制代码

sudo systemctl 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 Request
Security 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 中执行以下命令：

powershell 复制代码

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LmCompatibilityLevel"

返回的数值含义如下：

值	策略级别	含义
0 或不存在	级别 0	发送 LM 和 NTLM 响应（允许 v1）
1	级别 1	发送 LM 和 NTLM 响应（允许 v1，我的电脑当前值）
2	级别 2	仅发送 NTLM 响应（仍允许 v1）
3	级别 3	仅发送 NTLMv2 响应（但可能接受 v1）
5	级别 5	仅发送 NTLMv2 响应，拒绝 LM 和 NTLM（完全禁用 v1）

我的电脑 LmCompatibilityLevel = 1，证实了客户端强制使用 NTLMv1，与 Wireshark 抓包结果完全一致。

🎄四、解决方案

✨4.1 方案一：在 Samba 服务端启用 NTLMv1（本文采用，快速修复）

编辑 /etc/samba/smb.conf，在 [global] 部分添加：

ini 复制代码

ntlm auth = yes

重启 Samba：

bash 复制代码

sudo systemctl 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 作为临时方案。如果你也遇到同样情况，可以根据自己的网络环境选择上述任一解决方案。

如果文章有帮助的话，点赞👍、收藏⭐，支持一波，谢谢 😁😁😁

Ubuntu 22.04 Samba 连接故障排查记：从“用户名或密码错误”到 NTLM 版本不兼容

目录

🎄一、概述

🎄二、排查过程（逐步逼近真相）

✨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（推荐，彻底解决）

🎄五、经验教训与排查心得

🎄六、结语

✨方法二：查询 Windows 注册表 `LmCompatibilityLevel`