コンテキスト
Ubuntu 20.04.5 LTSがインストールされているコンピュータの大規模企業ネットワークには、2つの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
バグにもかかわらず、両方のインストールが動作します。夜に履歴があるかどうかを
確認するためにスクロールすると（接続が失われた場合）、Docker関連のネットワーク変更ストリームのみが表示され、マウントについては何も表示されません。share_B
...
[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
...
定期ポーリングのインストール
破損が発生した時期を見つけようとしている間に、stat問題のインストール結果を定期的に確認するために、以下のcrontabエントリを作成しました。
ログを検索できるタイムスタンプを見つけることができるというアイデアです。
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破損することがわかりました。