フォルダーを置き換えた後もNAS共有に古いファイルが表示されるのはなぜですか？
NAS共有に古いファイルが表示される場合、クライアントまたは共有サービスが、キャッシュされたディレクトリ情報や以前のパスを参照している可能性があります。
NAS上のフォルダーを置き換えても、すべてのSMBセッション、アプリケーション、マウント、リバースパス、名前空間が直ちに新しいディレクトリツリーへ切り替わるとは限りません。サーバーが古いパスを引き続きエクスポートしている、置き換え先が別のマウントポイント配下になっている、またはクライアントがディレクトリメタデータ、ファイル情報、オープンハンドル、キャッシュされた参照情報を保持している可能性があります。キャッシュ設定を変更する前に、ファイルシステムの表示、アクティブな共有先、完全に新しいクライアントセッションを比較するのが最も安全な診断方法です。
古いディレクトリツリーが表示されている層を確認する
影響を受けているSMBクライアントを、NASのシェル、NASのWebファイルマネージャー、最近その共有を開いていない別のクライアントと比較します。消えているはずのファイル名を1つ、新たに表示されるはずのファイル名を1つ記録してください。
NASのシェルとWebファイルマネージャーにも古いツリーが表示される場合、問題はSMBより下の層にあります。置き換えが誤ったディレクトリで行われた、必要なマウントが存在しない、または別のデータセットがそのパスを覆っている可能性があります。IBMは、SMB変更通知は変更がファイルサービスにどのように届くかに依存すると説明しています。そのため、1台のクライアントが古い状態を示しているだけでは、サーバー上のデータが古いとは限りません。
同じファイルブラウザーを何度も更新して、それを新しいテストと見なさないでください。意味のある比較には、別のクライアントプロセス、別のユーザーセッション、または同じSMBメタデータを再利用しないローカルファイルシステムの直接表示を使用します。
フォルダー置き換え後にアクティブな共有先を確認する
サーバーの共有設定を確認し、エクスポートされたパスを解決して、実際のファイルシステムオブジェクトを特定します。バインドマウント、シンボリックリンク、データセットのマウントポイント、コンテナのボリュームマッピング、またストレージマウントが有効になる前後のどちらで置き換えフォルダーが作成されたかを確認してください。
よくある障害は、管理者がマウントされていないディレクトリ内のファイルを置き換えた後、実際のストレージマウントが復帰して、その置き換え内容が隠されるケースです。Linuxのmountマニュアルでは、マウントによって以前のディレクトリ表示が隠されると説明されています。そのため、表示されているパスをアクティブなマウントテーブルと照合する必要があります。
ZimaSpaceのNASデータ移行ガイドでは、古いコピーを削除する前に、意図したソースパスと宛先パスに想定どおりのデータが含まれていることを確認するための関連手順を説明しています。
SMBのディレクトリ情報とファイル情報のキャッシュをテストする
共有を使用しているすべてのアプリケーションを閉じ、SMBマッピングを切断して、新しいセッションを確立します。その結果を、以前にそのディレクトリを列挙していない別のコンピューターまたは新しいユーザーセッションと比較してください。
WindowsのSMBクライアントは、設定された期間、ディレクトリメタデータとファイル情報をキャッシュできます。Microsoftのファイルサーバー向けチューニングガイダンスでは、ディレクトリキャッシュの有効期間によって、ディレクトリリースを利用できない場合にメタデータをキャッシュに保持できる期間が決まると説明されています。
新しいセッションでは直ちに正しいツリーが表示される一方、古いセッションでは表示されない場合、データが失われているわけではなく、共有先もおそらく正しい状態です。影響を受けたクライアントを正しく再接続し、キャッシュ値を全体的に変更する前に、セッションが想定された変更通知を受信しなかった、または適用しなかった理由を調査してください。
オープンハンドル、リース、長時間稼働するアプリケーションを確認する
NAS上のアクティブなSMBセッションとオープンファイルを一覧表示します。メディア管理ソフト、写真アプリ、バックアップツール、シェルウィンドウ、インデクサー、ファイルブラウザーは、目に見えるコピー操作が完了した後も、ディレクトリやファイルを長時間開いたままにすることがあります。
まずアプリケーションを閉じ、その後、影響を受けているSMBセッションだけを切断します。NetAppのSMBドキュメントでは、リースoplockがクライアントのキャッシュ状態を保持すると説明されています。そのため、NAS全体でリースを無効にすることは、1つの古い接続をリセットするよりはるかに大きな変更です。
特定のアプリケーションを閉じた後にだけ古いツリーが消える場合、その結果を記録し、新しいフォルダーでアプリケーションを再度テストします。修正すべき箇所はストレージプールではなく、アプリケーションの再接続、監視、または更新動作です。
DFS参照と重複したサーバー名を除外する
クライアントがNASへ、直接のホスト名、IPアドレス、DNSエイリアス、DFS名前空間、または現在は別の場所へ解決される古いサーバー名のどれを使って接続したか確認します。ファイルブラウザー上で似て見える2つのパスが、異なる共有先で終端している可能性があります。
DFSクライアントは、名前空間とフォルダーの参照情報を一定期間キャッシュします。DFSクライアントは名前空間およびフォルダーの参照情報を一定期間保持することもあるため、名前空間の変更後、一時的に古い共有先へ接続される場合があります。
正常なセッションと古いセッションについて、サーバーの識別情報、解決されたアドレス、共有名、最終パスを比較します。影響を受けたクライアントが別の共有先へ接続していることを確認する前に、すべてのDNSキャッシュやDFSキャッシュを消去しないでください。
新しい直接パスと通常のユーザーパスを比較する
クリーンなクライアントセッションから、通常のホスト名と確認済みの直接サーバーアドレスを使って、共有をそれぞれ1回ずつ開きます。これは切り分けのためだけに使用し、管理されたホスト名の恒久的な代替にはしないでください。
直接パスでは新しいツリーが表示され、通常の名前では古いツリーが表示される場合、エイリアス、参照情報、保存された資格情報、または同じ名前を使用している別のNASに注目します。Debianのmount.cifsのパスモデルは、慣れた表示名に頼るのではなく、正確なサーバーと共有先、およびローカルのマウントポイントを比較する必要がある理由を示しています。
また、ローカルNASパスとSMBパスについて、ファイル数と1つのファイルのハッシュ値を比較します。同じ古いファイルが一致する場合は、パスまたはキャッシュの選択が原因であることを示します。同じ名前で内容の異なるファイルがある場合は、置き換えが不完全、フォルダーが重複、またはアプリケーションが生成したコンテンツである可能性があります。
最小限の障害を修正し、再起動後も解決していることを確認する
誤ったフォルダーをエクスポートしている場合は共有先を修正し、パスが誤って覆われている場合は不足しているマウントを復元し、1台のクライアントだけに影響している場合は古いクライアントセッションを再接続し、名前空間が古い場所を参照している場合はDFSの共有先を更新します。
管理されたテストによってその層が原因だと証明されない限り、SMBキャッシュの保持期間を変更したり、リースを無効にしたり、共有を作り直したりしないでください。Sambaのアクティブなセッションとロックの表示を使えば、サーバー全体の変更を適用する前に、影響を受けた接続を確認できます。
サービスの再起動とホストの再起動後に、NASのシェル、Webファイルマネージャー、新しいSMBセッション、通常のクライアントパスのすべてで同じフォルダー内容が表示されれば、問題は解決しています。その確認が完了し、どのアプリケーションも古いフォルダーへの書き込みを続けていないことが分かるまで、古いフォルダーはオフラインのまま保持してください。
おすすめ商品
サポートとヒント
もっと読む
Dockerボリュームの復元でファイルの内容は再現されるのに、拡張属性が失われるのはなぜですか？
xattr のインベントリ、tar と Rsync のオプション、名前空間、保存先のサポート状況、権限、ラベル、アプリメタデータ、テストを網羅したボリューム復元の診断。
Composeファイルを変更した後も、実行中のコンテナが古いメモリ制限を維持するのはなぜですか？
ライブcgroup、再起動と再作成の違い、Composeのフィールド、ハードリミットとソフトリミット、親スコープ、スワップ、ランタイムヒープを網羅したメモリ制限の診断。
リバースプロキシを再起動すると、1つのセルフホストアプリですべてのセッションが無効になるのはなぜですか？
再起動の範囲、Cookieの所有権、シークレットのローテーション、キャッシュを利用したセッション、スティッキールーティング、認証ゲートウェイ、復旧を網羅したセッション喪失の診断。
