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