ストレージ交換後もNAS共有に古いファイルが表示される場合の確認と対処法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

NAS Share Shows Old Files After Storage Replacement: Checks and Fixes

ストレージ交換後に古いファイルが表示される原因は、通常、誤ったマウントパス、古いツリーを参照し続けるエクスポート、残存したSMBセッション、または重複したサーバーIDです。

まず、消えるはずのファイル名を1つと、表示されるはずのファイル名を1つ用意します。次に、NASのローカルファイルシステム、アクティブなエクスポート先、本当に新規のクライアントセッション、そのセッションが接続したサーバーアドレスを比較します。この順番なら、2つのコピーに書き込むリスクなしに、ストレージや名前空間の問題とクライアントキャッシュの問題を切り分けられます。サービスの再読み込み、NASの再起動、2台のクライアントからのアクセス後も修正結果が一致するまで、両方のストレージセットを完全な状態で保持してください。

交換後のストレージとNASのローカル表示を比較する

消えるはずの古いファイル名を1つと、必ず表示されるべき新しいファイル名を1つ選びます。NASのシェルとWebファイルマネージャーの両方で確認し、マウントされているデバイスまたはデータセット、マウントポイント、ファイルシステムID、プールの状態、ファイルハッシュを記録して、移行マニフェストと比較します。

ZimaSpaceのNAS移行保護ワークフローでは、件数と代表データが一致するまで、ソース、移行先、検証用コピーを完全な状態で保持します。古いプールを削除したり共有を変更したりする前に、ここでもこの基準を適用してください。古い内容が表示される場合、交換後のストレージが想定した場所にマウントされていない可能性があります。

NAS自体に古いツリーが表示される場合は、マウント順序、自動マウントの失敗、バインドマウント、データセットのマウントポイント、別のマウントの下に隠れているディレクトリを調べます。サーバー側のパスとデバイスIDが意図した交換後のストレージを示すまで、クライアントキャッシュを消去しないでください。

アクティブな共有先と名前空間を確認する

稼働中のSMBまたはNFSエクスポート設定を読み取り、シンボリックリンク、バインドマウント、コンテナパス、エイリアスを最終的なファイルシステムの場所まで解決します。エクスポート先を、移行後も残っている可能性がある分かりやすい共有名ではなく、検証済みの交換後マウントと比較します。

Unraidのコミュニティ事例では、ディスク共有とユーザー共有の比較を使い、ディスク共有上に存在するファイルと古いユーザー共有の表示を区別しました。これは範囲を限定した切り分け材料として扱ってください。直接のローカルパスまたはディスクパスが最新で、名前空間だけが古い場合は、データを再コピーするのではなくエクスポート層を修正します。

設定を保存し、進行中の書き込みがないことを確認してから、影響を受けている共有サービスだけを再読み込みします。成功すれば、新しいローカル名前空間のクエリで新しいツリーが表示されます。失敗した場合は、マウントと名前空間のログを保持したまま、サービスを以前の設定に戻します。

1台のクライアントだけが古いのか、サーバーセッションが古いのかを切り分ける

共有を、これまでその共有を列挙したことのない2台目のクライアントまたは新しいユーザーセッションから開きます。サーバーアドレス、共有名、認証情報、ネゴシエートされたプロトコル、開いているハンドル、古いファイル名と新しいファイル名がクライアント間で異なるかどうかを記録します。同じファイルブラウザーを繰り返し更新するだけでは、クリーンなセッションテストにはなりません。

Synologyのコミュニティでは、SMBキャッシュによって症状が変わる事例が報告されており、SMBキャッシュの消去やSambaの再起動によって症状が変化しました。これはセッションまたはサービスキャッシュが関与している可能性を示す証拠として利用し、NAS全体でキャッシュを無効にする理由にはしないでください。

開いているハンドルを持つアプリケーションを終了し、影響を受けているマッピングだけを切断します。その分岐で原因が確認できた場合にのみ、保存済みの認証情報や紹介情報を消去して再接続します。クリーンなクライアントもすでに古い状態だった場合は、クライアント全体に及ぶレジストリ変更を適用せず、サーバーのターゲットとIDの層に戻って確認します。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

サーバーIDを確認し、修正結果を検証する

DNSの応答、IPアドレス、SMBサーバーID、エイリアス、DFS紹介、VPNルート、保存済みマッピングを比較します。交換後のNASが分かりやすい名前を再利用している一方で、古いアドレス、名前空間のターゲット、またはコンテナが以前のツリーを提供し続けている可能性があります。検証済みの直接アドレスは、恒久的な回避策ではなく、切り分けのためだけにテストします。

最小限の修正を適用します。マウントまたはエクスポート先を修正する、1つの共有を再読み込みする、1台のクライアントを再接続する、1つの紹介情報を期限切れにする、または1つのDNSレコードを更新します。ローカルパスと共有間でファイル数とハッシュを比較し、使い捨てファイルを作成して削除し、想定した権限を確認します。

メンテナンス時間帯に共有サービスとNASを再起動し、2台のクライアントと、最初に古い状態のままだったアプリケーションを再接続します。再起動後もすべてのパスで交換後のツリーが表示されるまで完了としないでください。書き込みが異なるコピーに行われた場合はロールバックし、どちらかのストレージセットを消去する前に、判別できないIDの問題をエスカレーションします。