CIFS 隨機失去與 Windows 共享的連接
幾個月來，我已經在 Windows 共享中從 Debian Jessie 遠端安裝了幾個目錄。
在過去的幾周里，我一直抱怨從掛載點隨機斷開連接，並且不得不做一個
sudo mount -a重新獲得安裝連接，幾次（伺服器每週使用一次或兩次）。
例如，坐騎在一段時間未使用後通常不會恢復。
Windows 管理員還告訴我 Windows 伺服器有一段時間沒有重新啟動。
今天，巧合的是，
mount -a再次嘗試時，它僅在第二次嘗試中起作用，而第一次嘗試出現以下錯誤：sudo mount -a mount error(104): Connection reset by peer Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) mount error(112): Host is down Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)目錄是
/etc/fstab這樣安裝的：
//10.2.1.2/XX/ZZ/YY /mnt/mount_point cifs credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0770,dir_mode=0770,uid=1001,gid=1001 0 0在執行 mount 命令時，您還可以看到該選項
echo_interval預設在 60 秒時被啟動。
$mount //10.2.1.2/XX/ZZ/YY on /mnt/mount_point type cifs (rw,relatime,vers=1.0,cache=strict,username=someusername,domain=XXX,uid=1001,forceuid,gid=1001,forcegid,addr=10.2.1.2,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)該怎麼辦？
我在這裡發現了一篇有趣的相關文章，cifs 掛載的文件夾保持斷開連接（ubuntu 伺服器），談到了類似的問題（同樣的錯誤，Samba 共享）。
這裡的相關花絮，為了遵循其餘的答案，CIFS 掛載預設使用 SMBv1.0 協議，可以驗證發出
mount命令，並註意該vers=1.0欄位。
$mount //10.2.1.2/XX/ZZ/YY on /mnt/mount_point type cifs (rw,relatime,**vers=1.0**,cache=strict,username=someusername,domain=XXX,uid=1001,forceuid,gid=1001,forcegid,addr=10.2.1.2,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)我還在 Stack Overflow 中發現了Mount CIFS Host 的文章已關閉
這也可能是因為協議不匹配。2017 年，微軟修補了 Windows 伺服器並建議禁用 SMB1 協議。
從現在開始，mount.cifs 可能會出現協議協商問題。
顯示的錯誤是“主機已關閉”。但是當您使用以下命令進行調試時：
smbclient -L <server_ip> -U <username> -d 256你會得到錯誤：
protocol negotiation failed: NT_STATUS_CONNECTION_RESET該文章提到協議/Wannacry 等的 Windows 更新檔正在搞亂/或更準確地說，有些人禁用了 v1 CIFS 請求功能；Windows 前端也發生了類似的問題，而且，考慮到時間，這讓我懷疑問題一定是相關的。
我們尚未在此特定伺服器 AFAIK 中禁用 v1 CIFS（並且測試證實了這一點），但是 MS 公告表明預設 SMBv1 行為已（略微）更改。
我最終遵循了提到的 Samba 問題中建議的總體構想。來自男人
mounts.cifs：
vers=SMB 協議版本。允許的值為：
- 1.0 - 經典的 CIFS/SMBv1 協議。這是預設設置。
- 2.0 - SMBv2.002 協議。這最初是在 Windows Vista Service Pack 1 和 Windows Server 2008 中引入的。請注意，Windows Vista 的初始發行版使用的方言略有不同 (2.000)，它不受支持。
- 2.1 - Microsoft Windows 7 和 Windows Server 2008R2 中引入的 SMBv2.1 協議。
- 3.0 - 在 Microsoft Windows 8 和 Windows Server 2012 中引入的 SMBv3.0 協議。
另請注意，雖然此選項控制使用的協議版本，但並非每個版本的所有功能都可用。
--verbose列印掛載的附加調試資訊。請注意，此參數必須在
-o. 例如：mount -t cifs //server/share /mnt --verbose -o user=username從手冊中可以看出，在 Windows 8 之後的最新 Windows 版本中使用至少
vers=2.0可能更有意義；命令行中帶有--verbose提到的選項的替代語法對於進一步調試可能出現的任何並發症也很有用。因此，由於我在這個問題上安裝的 Windows 伺服器是 Windows 伺服器 2008 R2，所以我輸入
/etc/fstab：
//10.2.1.2/XX/ZZ/YY /mnt/mount_point cifs credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0770,dir_mode=0770,uid=1001,gid=1001,vers=2.1 0 0然後重新安裝它以使選項生效：
sudo mount -o remount /mnt/mount_point現在我們
mount再次驗證以確認協商的協議：
$mount //10.2.1.2/XX/ZZ/YY on /mnt/mount_point type cifs (rw,relatime,**vers=2.1**,cache=strict,username=someusername,domain=XXX,uid=1001,forceuid,gid=1001,forcegid,addr=10.2.1.2,file_mode=0770,dir_mode=0770,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)我們確實可以確認我們成功地修改了正在使用的 SMB 協議。
另請參閱MS 開發人員網路 -$$ MS-SMB2 $$: 版本控制和能力協商 - 1.7 版本控制和能力協商
還應該注意的是，與較新版本的協議相比，CIFS v1.0 除了過時之外，效率極低且不安全。
SMB1 既不現代也不高效
使用 SMB1 時，您將失去對最終使用者的關鍵性能和生產力優化。
- 更大的讀取和寫入 (2.02+) – 更有效地使用更快的網路或更高延遲的 WAN。大 MTU 支持。
- 文件夾和文件屬性的對等記憶體 (2.02+) – 客戶端通過 BranchCache 保存文件夾和文件的本地副本
- 耐用的句柄（2.02、2.1）——允許在臨時斷開連接時透明地重新連接到伺服器
- 客戶端 oplock 租賃模型 (2.02+) – 限制客戶端和伺服器之間傳輸的數據，提高高延遲網路的性能並增加 SMB 伺服器的可擴展性
- 多通道和 SMB 直連 (3.0+) – 如果客戶端和伺服器之間有多個可用路徑，網路頻寬和容錯能力的聚合，以及現代超高 RDMA 基礎設施的使用
- 目錄租賃 (3.0+) – 通過記憶體提高分支機構的應用程序響應時間
有趣的是，最後一篇文章表明，如果使用 >= 2.01 的協議，在斷開連接（持久句柄）之後不太可能出現斷開連接問題，所以我再次強調，不要繼續使用 CIFS v1.0。（例如，在 1.0 中，
echo_interval=60確實保持連接，如果出現網路故障或其他一些伺服器中斷，則在使用 CIFS v1.0 時，如果沒有手動干預，掛載將無法自行恢復）作為最後一條建議，避免做
sudo mount -a，並開始做：sudo mount -o remount -a另請參閱我的問題CIFS 在同一掛載點上掛載同一共享的多個副本