ZimaCube上の見覚えのないSMB共有：安全なトラブルシューティング

ファントム共有がサーバーから提供されていることを確認する

ZimaCubeの所有者は、2回のRAID5セットアップ失敗後に作成された空のSMB共有を、引き続き表示してマウントできました。ZimaOS 1.2.2では現在の共有を通常どおり追加・削除できましたが、以前の名前がネットワーク共有の選択画面に残っていました。

ZimaCubeに接続したことのないMacにも、同じ古い名前が表示されました。この確認により、1台のクライアントに限定されたキャッシュではないことが分かり、古い状態がサーバー側にあることが示されました。

サーバーを変更する前に、この低リスクの確認を繰り返してください。新しいクライアントまたはクリーンなプロファイルから取得した一覧と、ZimaOS Filesに表示されるアクティブな共有を比較します。どの項目が実在し、どれが空の状態でマウントされるかを記録してください。

チームは、避けられない場合を除き、ユーザーにRAIDデータの再構築や再読み込みを強制しないことを修復方針として示しました。その後、共有の問題が既存のRAIDデータに影響しないことを確認しました。

これは、ストレージの完全性と共有一覧の整理を切り分けるものです。まず現在のアレイと実在する共有を確認してください。RAIDが正常でデータにアクセスできるなら、ファントム名はアレイを再作成する必要がある証拠ではありません。

アレイ自体が劣化している、または見つからない場合は、そこで中止し、別個の復旧インシデントとして扱ってください。ストレージの修復とSMBの整理を同時に行うと、どの変更がどの問題に影響したのか判断できなくなります。

ZimaOSチームのメンバーは、当時、ファイル操作とストレージ操作が共有の整理と連動していなかったことを確認しました。別のユーザーからは、共有フォルダーの名前を変更または削除しても、古いSMB名が有効なまま残るという関連症状も報告されました。

元の問題は、ZimaOS 1.2が電源サイクル後にRAID構成を保持できなかったことから始まりました。1.2.1および1.2.2への更新によりRAID構成の保持失敗は止まりましたが、古い共有レコードは残りました。

ZimaOS 1.2.3でも削除されませんでした。チームは1.2.4での修正を予定しており、それ以前にリモート支援を提供すると申し出ましたが、1.2.4によって投稿者の項目が削除されたことを確認する後続投稿は、このトピックにはありません。このバージョンの境界を維持してください。

投稿者は、/etc/samba/smb.casa.confに古い定義を見つけました。そのファイルを編集、削除、置換しても再起動後には保持されず、ネットワーク一覧にファイル自体より多くの名前が表示されることもありました。

この動作は、別のコンポーネントが共有状態を再生成または提供していたことを示します。手動編集を繰り返すと、ZimaOSの管理状態との不一致が生じるだけで、永続的な修復にはつながらないおそれがあります。

実験的に加えた変更を元に戻し、アクティブなRAIDには手を加えず、サポートされているUI、更新手順、またはリモートサポートのプロセスを利用してください。修復後は、1つの構成ファイルを確認するだけでなく、再起動後に新しいクライアントから検証する必要があります。

サポートされている更新を適用してもファントム項目が削除されない場合は、ZimaOSのバージョン、Filesの共有一覧、クライアントの共有選択画面、空の状態でマウントされる名前を記録してください。同じ一覧が新しいクライアントにも表示されることも記載します。

ストレージの証拠から独自に必要と判断されない限り、RAIDの再構築を承認せず、共有状態の修復を依頼してください。チームは、予定していた更新の前にゴースト共有を削除するため、特にリモート支援を提案していました。

修復後は一度再起動し、既存のクライアントと新しいクライアントの両方から再接続して、アクティブな共有だけが表示され、期待どおりのパスを開けることを確認してください。この一連のテストにより、修復が完了したことを検証できます。

このケースでは違います。ZimaCubeに以前接続したことのないMacにも、同じ項目が表示されました。

いいえ。投稿者は、1.2.3では修正されなかったと明確に報告しています。

チームは1.2.4での修正を予定していましたが、スレッドには最終的なユーザー検証がありません。