如何对 15 分钟后中断的 CIFS 安装进行故障排除?

如何对 15 分钟后中断的 CIFS 安装进行故障排除?

语境

我在装有 Ubuntu 20.04.5 LTS 的计算机上安装了大型企业网络中的两个 Samba 共享(例如共享 A 和 B)。两种安装方式一开始都很好,但共享 B 会在一段时间后停止工作。这是我在已停止工作的文件夹ls -lah中执行操作时看到的内容:~/mntshare_B

ls: cannot access 'share_B': No such file or directory
total 8.0K
drwxrwxr-x  4 user user 4.0K Sep 13 19:16 .
drwxr-xr-x 12 user user 4.0K Oct  6 18:09 ..
d?????????  ? ?    ?       ?            ? share_B
drwxr-xr-x  2 user user    0 May 15 23:17 share_A

两个共享使用相同的凭据和相同的选项/etc/fstab

//company.network.com/share_A /home/user/mnt/share_A cifs uid=1001,gid=1001,vers=3.1.1,noserverino,credentials=/root/.smbcredentials,iocharset=utf8
//company.network.com/share_B /home/user/mnt/share_B cifs uid=1001,gid=1001,vers=3.1.1,noserverino,credentials=/root/.smbcredentials,iocharset=utf8

当我sudo mount -t cifs检查用于安装座的所有选项时,我看到了这一点(无论share_B停止工作之前还是之后):

//company.network.com/share_A /home/user/mnt/share_A type cifs (rw,relatime,vers=3.1.1,cache=strict,username=user,uid=1001,forceuid,gid=1001,forcegid,addr=XXX.XXX.XXX.22,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1)
//company.network.com/share_B /home/user/mnt/share_B type cifs (rw,relatime,vers=3.1.1,cache=strict,username=user,uid=1001,forceuid,gid=1001,forcegid,addr=XXX.XXX.XXX.34,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=65536,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1)

我看到的唯一区别是 IP 地址。

问题

我怎样才能阻止坐骑share_B变得“腐败”?

我尝试过的

重新安装

我可以通过卸载共享 B 并再次安装来解决此问题:

sudo umount /home/user/mnt/share_B
sudo mount /home/user/mnt/share_B

检查日志

我查看了日志dmesg -wT,它在安装两个共享后直接显示以下内容:

[Fri Oct  7 09:32:28 2022] CIFS: Attempting to mount //company.network.com/share_B
[Fri Oct  7 09:32:28 2022] CIFS VFS: \\company.network.com error -2 on ioctl to get interface list
[Fri Oct  7 09:35:21 2022] CIFS: Attempting to mount //company.network.com/share_A
[Fri Oct  7 09:35:21 2022] CIFS VFS: \\company.network.com error -2 on ioctl to get interface list
[Fri Oct  7 09:35:21 2022] FS-Cache: Duplicate cookie detected
[Fri Oct  7 09:35:21 2022] FS-Cache: O-cookie c=XXXXXXXXXXXXXXXX [p=XXXXXXXXXXXXXXXX fl=222 nc=0 na=1]
[Fri Oct  7 09:35:21 2022] FS-Cache: O-cookie d=XXXXXXXXXXXXXXXX n=XXXXXXXXXXXXXXXX
[Fri Oct  7 09:35:21 2022] FS-Cache: O-key=[10] 'XXXXXXXXXXXXXXXX'
[Fri Oct  7 09:35:21 2022] FS-Cache: N-cookie c=XXXXXXXXXXXXXXXX [p=XXXXXXXXXXXXXXXX fl=2 nc=0 na=1]
[Fri Oct  7 09:35:21 2022] FS-Cache: N-cookie d=XXXXXXXXXXXXXXXX n=XXXXXXXXXXXXXXXX

尽管存在错误,但这两个安装都可以工作。
当我向后滚动查看夜间(share_B断开连接时)是否有任何记录时,我只看到一串(我认为是)与 Docker 相关的网络更改流,而没有看到任何有关挂载的信息。

...
[Fri Oct  7 04:02:30 2022] device veth7c5d17e entered promiscuous mode
[Fri Oct  7 04:02:30 2022] br-8a3b7730e904: port 3(veth7c5d17e) entered blocking state
[Fri Oct  7 04:02:30 2022] br-8a3b7730e904: port 3(veth7c5d17e) entered forwarding state
[Fri Oct  7 04:02:31 2022] eth0: renamed from veth97841fd
[Fri Oct  7 04:02:31 2022] IPv6: ADDRCONF(NETDEV_CHANGE): veth7c5d17e: link becomes ready
[Fri Oct  7 04:02:31 2022] br-8a3b7730e904: port 4(vetheaf796c) entered blocking state
[Fri Oct  7 04:02:31 2022] br-8a3b7730e904: port 4(vetheaf796c) entered disabled state
[Fri Oct  7 04:02:31 2022] device vetheaf796c entered promiscuous mode
[Fri Oct  7 04:02:31 2022] br-8a3b7730e904: port 4(vetheaf796c) entered blocking state
[Fri Oct  7 04:02:31 2022] br-8a3b7730e904: port 4(vetheaf796c) entered forwarding state
[Fri Oct  7 04:02:31 2022] br-8a3b7730e904: port 4(vetheaf796c) entered disabled state
[Fri Oct  7 04:02:31 2022] eth0: renamed from vethe1d01ad
[Fri Oct  7 04:02:31 2022] IPv6: ADDRCONF(NETDEV_CHANGE): vetheaf796c: link becomes ready
...

定期轮询安装

在我尝试查找损坏发生的时间时,我在下面创建了 crontab 条目来定期检查stat有问题的安装的输出。
我的想法是,我可以找到一个可以搜索日志的时间戳。

user@host:~$ crontab -l
*/10 *  *  *  * echo "$(date) $(stat --terse /home/user/mnt/share_B)" >> /home/user/temp/share_B_mount_check.log

奇怪的是,这阻止了问题的发生,因此我现在还可以通过定期轮询已安装的文件夹来解决该问题。

我尝试过轮询间隔,发现如果超过 15 分钟,安装share_B就会损坏。

相关内容