Home Assistantのデータディレクトリを移動した後に権限を復元する方法

エヴァ・ウォン

IceWhale author

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

How to Restore Home Assistant Permissions After Moving Its Data Directory - Zima Store Online

移動したHome Assistantの権限を復元するには、まずマウントと実行時のUID/GIDを確認し、根拠がある場合に限って所有権、モード、ACL、セキュリティラベルを修正します。

データの移動では、ファイル名が維持されていても、数値IDが変わったり、隠しファイルが欠落したり、制限の厳しいACLを継承したり、コンテナに誤ったディレクトリが割り当てられたりすることがあります。再帰的な修正を行う前にHome Assistantを停止し、移動したツリーの未変更コピーを保持して、旧パスと新パスを比較してください。最初からchmod 777を実行してはいけません。診断に必要な情報を失い、不必要なアクセス権を与えてしまいます。

書き込みを停止し、移動したツリーを保全する

Home Assistantコンテナと、同じデータディレクトリに書き込むすべてのプロセスを停止します。現在のマウント定義、ディレクトリのメタデータ、コンテナの識別情報を記録し、所有権やACLを変更する前にスナップショットまたは保護されたコピーを作成してください。物理的な修復やファイルシステムの修復は、元に戻せる状態にしておく必要があります。

ある移行手順では、Home Assistantのバックアップデータをコンテナの設定ディレクトリに展開し、復元された設定ツリーがコンテナの永続状態になり、一体として扱う必要があることを説明しています。

PASSは、サービスが停止し、修復対象のパスの外部に変更されていないロールバック用コピーが存在する状態です。FAILは、別のコンテナまたはネットワーククライアントがファイルを変更できる状態です。書き込みが静止するまで続行しないでください。アクティブなデータベースやレジストリの更新中に所有権を変更すると、別の障害を引き起こす可能性があります。

まずマウントとコピーの完全性を確認する

新しいホストパスまたはボリュームが、Home Assistantで想定されている正確なコンテナパスに割り当てられていることを確認します。ファイル数、主要な設定ファイル、隠しストレージデータ、データベースの有無、シンボリックリンク、タイムスタンプをコピー元と比較してください。空または不完全なディレクトリをコンテナにマウントしている場合、権限を修正しても解決できません。

Home Assistantコンテナの移行に関する議論では、隠しストレージディレクトリもコピーする必要があり、すべてのファイルの移動を確認してから権限を確認することが推奨されています。この完全コピーの確認は、最初に行う最も影響の少ない切り分けです。

マウントまたはコピーが誤っている場合は、モードを変更せずに修正して再度比較します。完全であれば、数値IDの確認に進みます。誤った空のパスでHome Assistantを起動すると新しいファイルが作成され、元のツリーが分かりにくくなる場合があります。そのため、誤ったマウント上にあることを確認できたテスト用アーティファクトだけを削除してください。

数値UIDとGIDを一致させる

旧ツリー、新ツリー、および空のテスト用マウント上で意図したコンテナIDにより作成した使い捨てファイルについて、数値の所有者とグループを確認します。ホストが異なるとユーザー名が変わることがありますが、アクセスを制御するのは数値IDです。文書化されたIDでコンテナを実行するのか、コンテナが管理するツリーの所有権を変更するのかを決めてください。

Home AssistantとHACSに影響する権限問題が、書き込み可能なユーザーディレクトリの所有者を一致させることで解決された事例があり、所有権の不一致によって設定変更が妨げられていた経緯が記録されています。この限定的なHome Assistantの所有権事例は、システム固有の修正を一律に適用するのではなく、数値IDを根拠として使うことを支持しています。

所有権の変更は、サービスを停止した状態で、確認済みのHome Assistant管理ツリーにのみ適用します。別のサービスが意図的に所有しているファイルは保持し、ツリー外のシンボリックリンクを追跡しないでください。続行する前に、ルート、隠しストレージ、カスタムコンポーネント、データベースパスからサンプルを再確認します。

-15% OFF

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

Single board computer zimaboard2

モード、ACL、セキュリティコンテキストを限定的に修正する

ディレクトリの実行ビット、ファイルの読み取り・書き込みビット、デフォルトACL、マウントの読み取り専用フラグ、SELinuxやAppArmorのラベルを、正常に動作するコピー元またはプラットフォームの基準と比較します。最初に不一致が見つかった層を修正し、実行時IDで分離した作成・名前変更・削除プローブを再テストします。

デプロイ時のIDを理解せずに、一般的なフォーラムの回答にある安易な権限変更コマンドをコピーしないでください。広範な再帰的アクセス権限により起動は成功しても、秘密情報が公開され、新しく作成されるファイルの設定が不整合になる可能性があります。必要な実行時操作を許可できる、最も限定的な所有者・グループ権限を使用してください。

PASSは、実行時プローブが成功し、新しいファイルが意図した所有者、グループ、モード、ACL、コンテキストを継承する状態です。Unix権限を正しく設定してもFAILになる場合は、読み取り専用マウントまたは強制アクセス制御ポリシーが原因です。通常のモードをさらに広げるのではなく、その層を修正してください。

一度だけ起動し、元のワークロードを検証する

Home Assistantを一度起動し、最初に発生する権限またはパスのエラーを監視します。設定の読み込み、隠しレジストリ、Recorderへの書き込み、家庭で使用するカスタム統合、バックアップまたはメディアパス、そして再起動を1回確認してください。二次的なエラーを黙らせるために、サービスの実行中にレジストリファイルを編集しないでください。

ZimaSpaceのバックアップ手順では、未加工のファイルシステムコピーにおいて、書き込みを停止すると整合性が高まるタイミングを説明しています。移行または権限修復を再実行する場合は、サービス停止の境界を使用してください。

PASSは、2回の起動後も元の機能で読み書きでき、新しく作成されたオブジェクトが想定どおりのIDを保持する状態です。エラーが増えたり、データベースが破損を報告したり、修復後のツリーが保持していたコピーと想定される実行時ファイル以上に異なったりする場合は、ロールバックしてください。ファイルシステムのI/Oエラーやセキュリティポリシーによる拒否は、正確なパスとコンテキストを添えてエスカレーションします。