根本原因是 Samba 默认启用 map to guest = bad user，导致无效用户名或空密码时自动降级为 guest 身份；应设 map to guest = never 或 bad password，并确认 security = user 和 restrict anonymous = 2。
为什么 smb.conf 里设了 valid users 还能被匿名访问？
根本原因是 Samba 默认启用 map to guest = bad user，只要用户名不存在或密码为空，就自动降级为 guest 身份——哪怕你写了 valid users = alice，攻击者用任意无效用户名+空密码照样进得去。
实操建议：
- 显式关闭降级行为：
map to guest = never（最安全）或map to guest = bad password（仅密码错时降级，需配合guest ok = no） - 确认
security = user（Samba 4.12+ 默认值），避免误配成security = share（已弃用且无法校验用户） - 检查全局段是否漏写
restrict anonymous = 2：禁止枚举用户、组、共享名，否则smbclient -L //server仍能看到所有共享
chmod 750 目录权限 + force group 为什么还是写不进去？
Linux 文件系统权限和 Samba 的 create mask/directory mask 是两套独立机制。即使目录属组正确、force group 生效，Samba 创建文件时若未显式设置组写权限（create mask = 0660），新文件默认无组写位，导致同组用户无法修改。
实操建议：
- 必须同时配置：
force group = devs+create mask = 0660+directory mask = 0770 - 注意
force group不影响现有文件权限，只作用于新建文件/目录；已有文件需手动chgrp devs /path && chmod g+w /path - 如果客户端是 Windows，还要防 NTFS ACL 覆盖：在共享段加
nt acl support = no，避免 Windows 用户右键“属性→安全”乱改权限
启用 TLS 后 smbclient 报 NT_STATUS_CONNECTION_RESET 怎么办？
这不是证书问题，而是 Samba TLS 要求客户端也启用加密通信。旧版 smbclient（如 CentOS 7 自带的 4.9.x）默认不协商加密，直连 TLS 端口（445）会被立即断开。
实操建议：
- 服务端确保
server min protocol = SMB3_11（强制最低协议版本）和tls enabled = yes，并验证证书路径：tls certfile = /etc/samba/tls/server.crt、tls keyfile = /etc/samba/tls/server.key - 客户端必须显式开启加密：
smbclient //server/share -U user --use-kerberos=required -e（-e启用加密） - 若用脚本调用，别依赖环境变量；
smbclient的--option=encrypt=yes参数比-e更可靠，尤其在批量操作时
SELinux 开启状态下，Samba 共享目录始终提示 Permission denied
不是 chmod 或 Samba 配置错了，而是 SELinux 的 samba_share_t 上下文没打到目录上。即使 ls -Z 看起来正常，父目录或挂载点可能继承了错误类型（比如 default_t）。
实操建议：
- 先确认当前上下文：
ls -Z /srv/samba/share，正确应为unconfined_u:object_r:samba_share_t:s0 - 递归修正：
sudo semanage fcontext -a -t samba_share_t "/srv/samba/share(/.*)?"，再sudo restorecon -Rv /srv/samba/share - 若共享目录在 LVM 或 NFS 挂载点上，SELinux 可能拒绝重标——此时需额外允许：
sudo setsebool -P samba_export_all_ro 1（只读）或samba_export_all_rw 1（读写）
真正卡住人的，往往是 SELinux 上下文没递归生效、TLS 客户端没加 -e、或者 map to guest 暗中放行了匿名访问。这些点不报明确错误，但让配置看起来“明明写了却没用”。
