☰

如何防止 samba 在客户端断开连接后持有文件锁？

tag-icon • tag-icon linux samba server-message-block
如何防止 samba 在客户端断开连接后持有文件锁？

这里我有一个 Samba 服务器（Debian 5.0），它配置为托管 Windows XP 配置文件。

客户端连接到该服务器并直接在 samba 共享上处理他们的配置文件（配置文件不会被复制到本地）。

有时，客户端可能无法正常关闭，因此 Windows 不会释放文件锁定。查看 Samba 锁定表时，我们可以看到即使客户端不再连接，许多文件仍处于锁定状态。在我们的例子中，这似乎发生在 Mozilla Thunderbird 和 Firefox 创建的锁定文件中。以下是 Samba 锁定表的示例：

# smbstatus -L | grep DENY_ALL | head -n5
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
15494        10345      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user1   app.profile/user1.thunderbird/parent.lock   Mon Nov 22 07:12:45 2010
18040        10454      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user2   app.profile/user2.thunderbird/parent.lock   Mon Nov 22 11:20:45 2010
26466        10056      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user3   app.profile/user3.firefox/parent.lock   Mon Nov 22 08:48:23 2010

我们可以看到这些文件被Windows打开并施加了DENY_ALL锁。

现在，当客户端重新连接到此共享并尝试打开这些文件时，samba 会说它们已被锁定并拒绝访问。

有什么办法可以解决这种情况吗？或者我遗漏了什么？

编辑：我们希望避免禁用 Samba 服务器上的文件锁，因为是启用这些功能的充分理由。

答案1

以下步骤曾多次帮助我解决这一确切问题：

  1. 登录 samba 服务器。
  2. 运行“smbstatus”。
  3. 在输出的第三部分中找到对文件具有锁定的进程的 pid。
  4. 验证它是否与 smbstatus 输出的第一部分和第二部分中的预期用户和主机名匹配。
  5. 运行“ps -ef”并查看具有该 pid 的 smbd 已经运行了多长时间。
  6. 如果它在计算机上次重新启动之前就已运行，则它就是一个剩余的 smbd。只需杀死这一个 smbd。（并确保你得到的是正确的 smbd — 它应该是父 pid 不等于 1 的 smbd。）

答案2

看一下：

reset on zero vc = yes / no

看看是否能解决你的问题。

从smb.conf手册页中：

此布尔选项控制传入会话设置是否应终止来自同一 IP 的其他连接。这与默认的 Windows 2003 行为一致。当您的网络不稳定并且 Windows 决定重新连接而旧连接仍有打开共享模式的文件时，将此参数设置为是必要的。这些文件无法通过新连接访问。客户端在新连接上发送零 VC，Windows 2003 终止来自同一 IP 的所有其他连接。这样锁定的文件就可以再次访问了。请注意，启用此选项将终止伪装路由器后面的连接。

编辑：
我刚刚考虑了另一种可能的解决方案。您可以在相关共享上执行类似操作。

veto oplock files = /*.lock/

这只会阻止 .lock 文件上的 oplock。

答案3

我遇到了类似的问题，客户端在复制大型文件时崩溃，重启后文件被锁定。幸运的是，这种情况并不经常发生，但必须终止 samba 进程仍然很烦人。 reset on zero vc似乎只是解决方案，但它据称已从 Samba4 中删除，尽管 Fedora (27) 上的版本 4.7.6 仍然有它（可能是由 RH 修补的）。无论如何，它不会有太大帮助，因为手册页现在说，它仅适用于 SMB1（不应再使用），并且对 SMB2 和 SMB3 连接不起作用，处理此问题的唯一方法是在 Micheal 链接的帖子中提到。我不知道删除的原因是什么，也不知道有什么不好reset on zero vc，我认为使用 tcp 超时来达到这个目的更像是一种黑客行为。无论如何，一些合理的做法可能是

socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3

这将在最后一次通信后约 40 秒（30+3*3）终止连接，这通常足以注意到崩溃并重新启动（假设服务器的 tcp 堆栈足够智能，可以在客户端在重新启动后拒绝其保持活动数据包时关闭连接）。

请注意，这会增加网络负载，但我怀疑即使有很多客户端，这种影响也不会很明显。

答案4

Samba 中一些非常聪明的人决定删除此选项，并且没有替代方案。

到目前为止，对于 SMB 兼容性，这确实是默认的 win 行为。

除非用户精通 Linux 命令行以及如何终止打开的文件/进程，否则您必须重新启动 SMBD 或服务器本身来清除此问题。

太棒了，Samba.org。

相关内容