停電後にZimaOSのボリュームが読み取り専用になった場合は、権限の問題ではなく、ファイルシステムの保護イベントとして扱うべきです。この1.4.0のケースでは、WindowsがI/Oエラーを報告し、ZimaOSのファイルブラウザーには「read-only file system」と表示されました。最終的に、ユーザーはfsckでアクセスを復旧しました。
この修復が成功したことは有用な証拠ですが、ファイルシステムの種類とアンマウント状態を確認せずに、同じコマンドをそのまま実行するのは危険です。ファイルシステムごとに必要な修復ツールは異なり、マウント中のボリュームを対象に無闇に修復を行うべきではありません。
障害の状況
このサーバーでは2TBのRAID1アレイを使用していました。停電後、Windows SMB経由でファイルを安定して開けなくなり、ZimaOSのファイルブラウザーで直接フォルダーを作成することも、RAIDのマウントが読み取り専用になったため失敗しました。
この組み合わせは重要です。クライアント側のアクセスエラーと、ホスト側の読み取り専用ファイルシステムのメッセージが同時に発生している場合、問題はSambaの権限より下位の層にある可能性があります。ユーザー、ACL、共有設定を変更する前に、ストレージまたはファイルシステムの整合性を確認すべきことを示しています。
フォーラムでの修復はユーザーによって検証済み
ユーザーはモニターとキーボードを接続し、昇格された権限でログインしました。その後、fdisk -lでLinuxファイルシステムのデバイスを特定し、RAIDデバイスに対してfsck -fを実行しました。エラーが残っていたため再度チェックし、再起動しました。報告によると、これで通常の読み書き動作が復旧しました。
これは実際にユーザーが検証した結果ですが、IceWhaleが作成した復旧手順ではありません。より安全な原則は、まず正確なファイルシステムを特定することです。e2fsckのマニュアルでは、限定的な読み取り専用の場合を除き、マウントされたextファイルシステムをチェックしないよう警告しています。
リスクの低い復旧手順を使用する
修復を行う前に、ボリュームへ書き込みを行うアプリや同期ジョブを停止してください。重要なデータをまだ読み取れる場合は、最も重要なファイルを別の正常なストレージへコピーします。再起動やアレイの変更を行う前に、プール構成と現在のエラーを記録してください。
読み取り専用ボリュームのチェックリストでは、ext4、XFS、Btrfs、ZFSについて、この手順を詳しく説明しています。すべてのZimaOSアレイに同じfsckコマンドを実行すべきだと考えるよりも、こちらを出発点にする方が適切です。
現在のZimaOSターミナルにアクセスする方法
現在のZimaOSでは、開発者モードからSSHと内蔵Webターミナルを利用できます。現在のSSH設定では、これらのアクセス方法を説明しています。
ターミナルから、まずデバイスとファイルシステムの種類を確認してください。通常のシステムを稼働させたまま対象ボリュームを正常にアンマウントできない場合は、その場で修復を強行せず、適切なメンテナンス環境またはリカバリー環境を使用してください。
同じ障害をデータ損失に発展させないために
UPSは突然のシャットダウンを減らすのに役立ちますが、バックアップの代わりにはなりません。RAID復旧の限界では、ミラーリングされたアレイにも、独立した復元可能なコピーが必要な理由を説明しています。
まとめ
このフォーラムのケースは、ファイルシステムの修復によって実際に解決されました。しかし、教訓は「停電のたびにfsck -fを実行する」ことではありません。正しい教訓は、読み取り可能なデータを保全し、ファイルシステムとデバイスを特定し、必要に応じてアンマウントし、そのファイルシステム固有の修復ツールを使用してから、書き込みを復旧することです。
