CIFS が Windows 共有への接続をランダムに失う

CIFS が Windows 共有への接続をランダムに失う

私は数か月間、Windows 共有内の Debian Jessie からリモートでマウントされたディレクトリをいくつか持っていました。

ここ数週間、マウントポイントからランダムに切断されるという苦情が続いており、

sudo mount -a

マウント接続を回復するには、数回実行する必要があります (サーバーは週に 1 回または 2 回使用されます)。

たとえば、マウントは、一定期間使用しないと回復しないことがよくあります。

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

今日、偶然にもmount -a再度実行したところ、最初の試行では次のエラーが発生しましたが、2 回目の試行でのみ機能しました。

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_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)

何をするか?

答え1

ここで興味深い関連記事を見つけましたcifs マウントされたフォルダーが切断され続ける (Ubuntu サーバー)、同様の問題(同じエラー、Samba で共有)について話しています。

残りの回答を追う上でここで関連する情報は、コマンドを発行してフィールドmountに注意を払えば確認できるように、CIFS マウントはデフォルトで SMBv1.0 プロトコルを使用するということです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 Developer Network - [MS-SMB2]: バージョン管理と機能のネゴシエーション - 1.7 バージョン管理と機能のネゴシエーション

また、CIFS v1.0 は時代遅れであるだけでなく、プロトコルの新しいバージョンと比較して非常に非効率的で安全ではないことにも注意する必要があります。

からMS ブログ - SMB1 の使用をやめる

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 マウントする

関連情報