CIFSは、Windows共有への接続がランダムに切断されます。

CIFSは、Windows共有への接続がランダムに切断されます。

私は数ヶ月間、Debian JessieからWindows共有に複数のディレクトリをリモートでマウントしてきました。

過去数週間、マウントポイントのランダムな接続の切断について不満を吐き出してきました。

sudo mount -a

マウント接続を再取得するには数回かかります(サーバーは週に1〜2回使用されます)。

たとえば、マウントはしばらくの間使用しなくても回復しないことがよくあります。

Windowsの管理者は、Windowsサーバーがしばらく再起動されなかったと言いました。

今日は偶然mount -a再試行したときに2回目の試みでのみ機能しましたが、1回目の試みでは次のエラーが発生しました。

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

echo_intervalmountコマンドを実行すると、このオプションがデフォルトで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)

何をすべきか?

答え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でもこの投稿を見つけました。マウントCIFSホストがダウンしました。

これはプロトコルの不一致によっても発生する可能性があります。 2017年、MicrosoftはWindows Serverにパッチを適用してSMB1プロトコルを無効にすることをお勧めしました。

これ以降、mount.cifsでプロトコルネゴシエーションの問題が発生する可能性があります。

表示されるエラーは「ホストがダウンしました」です。しかし、デバッグするとき:

smbclient -L <server_ip> -U <username> -d 256

エラーが発生します。

protocol negotiation failed: NT_STATUS_CONNECTION_RESET

この記事では、プロトコル/WannacryなどのWindowsパッチがめちゃくちゃになったり、より正確には、一部の人がv1 CIFS要求機能を無効にしたと述べています。同様の問題がWindowsで発生しており、タイミングを考慮すると疑わしいです。関連している。

私が知っている限り(そしてテスト結果を確認する限り)、この特定のサーバーで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 Server 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は、古いバージョンだけでなく、最新バージョンのプロトコルと比較して非常に非効率的で安全でないことにも注意してください。

~からMSブログ - SMB1を無効にする

SMB1は現代的でも効率的でもありません。
SMB1を使用すると、エンドユーザーにとって重要なパフォーマンスと生産性の最適化が失われます。

  • 改善された読み取りおよび書き込み(2.02+) - より高速なネットワークまたは待ち時間の長いWANをより効率的に使用します。大規模なMTUサポート。
  • フォルダとファイルのプロパティのP2Pキャッシュ(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 は、同じマウントポイントに同じ共有の複数のコピーをマウントします。

関連情報