문맥
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
버그에도 불구하고 두 설치 모두 작동합니다. 밤에 기록이 있는지
확인하기 위해 뒤로 스크롤하면 (연결이 끊어진 경우) 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손상되는 것으로 나타났습니다.