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

在这里，我有一个配置为承载Windows XP配置文件的Samba服务器（Debian 5.0）。

客户端连接到该服务器，并直接在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. 登录到samba服务器。
2. 运行“ smbstatus”。
3. 在输出的第三部分中找到已锁定文件的进程的pid。
4. 验证它是否与smbstatus输出的第一部分和第二部分中的预期用户名和主机名匹配。
5. 运行“ ps -ef”，查看带有该pid的smbd运行了多长时间。
6. 如果自从上次重新启动计算机之前一直在运行，则它是smbd的剩余部分。杀死一个Smbd。（并确保您获得正确的一个-它应该是父pid不等于1的那个。）

看一下：

reset on zero vc = yes / no

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

从smb.conf手册页：

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

编辑：
我只是想过另一种可能的解决方案。您可以在有问题的共享上执行类似的操作。

veto oplock files = /*.lock/

这只会防止对.lock文件进行oplock。

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

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

除非用户精通linux命令行以及如何杀死打开的文件/进程，否则您必须重新启动SMBD到或服务器本身以清除它。

Samba.org做得好极了。

我遇到了类似的问题，客户端在复制大文件时崩溃，并且文件在重新启动后被锁定。幸运的是，这种情况并不经常发生，但是杀死samba进程仍然很烦人。 reset on zero vc似乎仅仅是解决方案，但据说它已从Samba4中删除，尽管Fedora（27）上的版本4.7.6仍然有（可能是由R​​H修补的）。就像手册页现在所说的那样，它并没有多大帮助，它只能与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堆栈足够智能，可以在客户端关闭时关闭连接）重新启动后拒绝其keepalive数据包）。

请注意，这会增加您网络上的负载，但是我怀疑即使有很多客户端，它是否也很明显。

您可以按以下方式按份额禁用oplock：

[acctdata]
oplocks = False
level2 oplocks = False

默认的oplock类型为Level1。smb.conf文件中按份额启用了Level2操作锁定。或者，您可以在共享中按文件禁用oplock：

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

如果您遇到操作锁问题（从Samba的日志条目中可以明显看出），则可能需要安全使用并禁用操作锁和Level2操作锁。

禁用内核操作锁定内核操作锁定是一个smb.conf参数，当UNIX进程试图打开缓存的文件时，该参数通知Samba（如果UNIX内核具有向Windows客户端发送操作锁定中断的能力）。此参数解决了在Samba服务器上启用oplock的情况下在UNIX和Windows之间共享文件的问题：UNIX进程可以打开Windows客户端Oplocked（缓存）的文件，而smbd进程不会发送oplock中断，这会使文件暴露给数据损坏的风险。如果UNIX内核具有发送oplock中断的功能，则内核oplocks参数使Samba能够发送oplock中断。内核oplock在smb.conf文件中按服务器启用。

kernel oplocks = yes

默认为“否”。

资源