排查Windows 挂载 Samba 报“文件被另一进程使用”与 DENY

给团队搭建了一个Samba服务器，结果遇到问题了。 Windows/macOS 混合客户端环境下：Windows 映射网络驱动器时提示 “进程无法访问文件，因为另一个程序正在使用此文件”；进入服务器查看 smbstatus，发现共享根目录下存在 DENY_ALL 独占锁。

更迷惑的是，静置一段时间后，即使服务器上的 DENY_ALL 状态并未消失，Windows 却又能够正常访问了。本文将从 SMB 协议底层机制、VFS 模块冲突及配置优化三个维度，完整还原该问题的排查逻辑与终极解决方案。

一、故障现象与环境抓取

1. 客户端表现

Windows 客户端： 首次映射驱动器或双击打开共享路径时，弹窗报错 0x80070020 或提示“被另外一个进程使用”。
恢复特征： 维持连接不动，等待 1~3 分钟后再次双击，可顺畅进入目录。

2. 服务端状态检查

在 Linux Samba 服务器端执行 smbstatus -L，抓取到如下锁定信息：

Locked files:
Pid          User(ID)   DenyMode   Access     R/W        Oplock            SharePath   Name   Time
--------------------------------------------------------------------------------------------------
7669         1000       DENY_ALL   0x100080   RDONLY     NONE              /share      .      Tue Jun  9 11:28:53 2026
5883         1000       DENY_ALL   0x100080   RDONLY     NONE              /share      .      Tue Jun  9 07:54:24 2026

二、核心病灶深度剖析

1. `DENY_ALL` 作用域：根目录句柄锁 (`.`)

观察 smbstatus 中的 Name 列，被锁定的目标为 .（即 /share 共享根目录本身），而非某个子文件。 Access 0x100080 代表客户端正在请求 FILE_READ_ATTRIBUTES（读取文件属性）与 SYNCHRONIZE（同步）。Windows 资源管理器（Explorer）在初始化挂载时，会极其激进地向服务器申请根目录的独占或元数据校验句柄。一旦此时已有其他会话（如后台索引、杀毒软件或 Mac 客户端）持有了该目录的 DENY_ALL 共享模式，Samba 会直接拒绝 Windows 的初始句柄请求。

2. 为什么静置一段时间后又能访问？

这是由于 Windows SMB 驱动（mrxsmb）的降级重试机制与错误缓存超时：

首次访问时，Windows 尝试获取根目录的强控制句柄失败，直接向用户抛出冲突错误。
随后 Explorer 在后台调整策略，放弃请求强锁句柄，改用低权限的 SMB2_FIND 命令直接列出目录子项。
一旦跳过了根目录属性强校验，后续访问子文件不再触发该 DENY_ALL 锁，访问遂恢复正常，但底层 smbstatus 依然会残留上一次会话未完全释放的锁记录。

3. 深层死锁根源：`vfs_fruit` 与 `veto files` 的逻辑内耗

经核查 Samba 的 smb.conf，发现配置文件中同时开启了 Apple 兼容模块与文件黑名单：

vfs objects = catia streams_xattr fruit
veto files = /._*/.DS_Store/desktop.ini/

这构成了引发死锁的核心矛盾：

vfs_fruit 机制： 专门用于将 macOS 的 AppleDouble (._*) 及 .DS_Store 转换存储至 Linux 扩展属性（xattr）中。
veto files 机制： Samba 在底层 VFS 接口处直接封锁了对包含 ._* 路径的任何读写。
死锁逻辑： 当 macOS 或 Windows 客户端试图读写元数据时，vfs_fruit 尝试接管，却被 Samba 自身的 veto files 在底层拦截，向 SMB 协议层抛出 STATUS_SHARING_VIOLATION（共享违例）。Windows 收到该错误码后，将其直接翻译为“文件被另一进程使用”。

此外，vfs objects 的加载顺序也是常见陷阱。Samba 官方明确规定：fruit 必须位于 streams_xattr 之前。若将 streams_xattr 置于前面，文件流解析会提前被接管，导致 fruit 的逻辑判断全面失效。

三、归档型 Samba 共享最佳实践配置

对于纯文件归档、高并发读取且不存在多人协同写同一个文件的场景，应当在服务端彻底抹平无谓的独占锁与协议内耗。

1. 修正后的 `smb.conf`

[global]
   # 1. 严格纠正 VFS 模块加载顺序：catia -> fruit -> streams_xattr
   vfs objects = catia fruit streams_xattr

   # 2. macOS 属性映射与锁定优化
   fruit:aapl = yes
   fruit:metadata = stream
   fruit:locking = none
   fruit:veto_appledouble = yes
   fruit:model = Macmini

   # 3. 彻底禁用阻碍挂载的文件锁与缓存协商（归档场景专用）
   reset on zero vc = yes
   smb2 leases = no
   oplocks = no
   level2 oplocks = no
   kernel oplocks = no
   locking = no
   posix locking = no
   strict locking = no

   # 4. DOS 属性与扩展属性支持
   ea support = yes
   store dos attributes = yes
   map archive = no
   map hidden = no
   map system = no
   map readonly = no

   # ... 基础网络与日志配置 ...

[share]
   path = /share
   browsable = yes
   read only = no
   guest ok = no

   # 5. 瘦身 veto files：交给 fruit 处理 Apple 元数据，仅拦截 Windows 系统垃圾文件
   veto files = /desktop.ini/Thumbs.db/ehthumbs.db/autorun.inf/
   delete veto files = yes

2. 关键参数解析

vfs objects = catia fruit streams_xattr：保证 SMB2/3 Alternate Data Streams（ADS）与 macOS 元数据被正确解析，避免 VFS 抛出共享违例。
fruit:veto_appledouble = yes：由 vfs_fruit 模块在底层自动屏蔽和清理 ._* 文件，无需再将其写入 veto files，彻底消除协议层冲突。
**locking = no & posix locking = no**：通知 Samba 忽略客户端发起的 DENY_ALL 等独占模式请求，确保网络映射及文件读取通道始终畅通。（注意：在 Samba 4.x 中，旧参数 share modes = no 已被废弃，应统一使用 locking = no）。

四、客户端句柄清理与验证

修改配置并重启 Samba 服务（systemctl restart smbd）后，Windows 客户端的重定向驱动（mrxsmb）可能仍残留有旧连接的失效句柄缓存。

需在 Windows 客户端打开终端（CMD）清理缓存：

:: 清理所有旧的 SMB 共享连接
net use * /delete /y

:: 重新挂载网络驱动器
net use Z: \\your-samba-ip\share

再次执行 smbstatus，根目录的 DENY_ALL 锁定情况将不再引发挂载报错，Windows 映射网络驱动器恢复秒级响应。

BLCL的博客小馆