権限ドリフトは、Home Assistantのデータ自体は残っているものの、現在そのデータをマウントしているプロセスが、作成時のプロセスとは異なる所有者、UID/GIDマッピング、アクセスモード、またはセキュリティコンテキストで認識する場合に発生します。この問題は、ホストの移行、復元、Dockerモードの変更、NASへのコピー、手動でのchown/chmod操作の後によく現れます。
変更前に想定するマウント方法と所有権モデルを文書化し、コピー時にメタデータを保持し、再作成後に読み取りと書き込みの両方をテストすることで防止できます。すべての失敗をchmod -R 777で解決しようとしないでください。これでは不一致が隠れるだけで、復旧モデルも弱くなります。
権限を変更する前にストレージの境界を文書化する
まず、/configがDocker管理ボリューム、Linuxのバインドマウント、ネットワークマウント、またはVM内のパスのいずれであるかを確認します。適切な所有権戦略は、実際にファイルを管理しているレイヤーによって異なります。
Home Assistantの現在のContainerインストールガイドでは、このストレージ契約が具体的に示されています。選択したホストフォルダーを読み書き可能な状態で/configにマウントします。フォルダー名だけに頼らず、正確なソースパス、マウント先、アクセスモードを記録してください。
また、Home Assistantが標準Docker、rootless Docker、ユーザーネームスペースの再マッピング、またはNASのコンテナ管理ツールのどれを通じて実行されているかも記録します。コンテナ内外で認識される数値IDは、同じとは限りません。
ファイルを移動しなくてもUIDとGIDのマッピングは変わる
ホスト上のフォルダーパスが同じままでも、その下で有効なユーザーマッピングが変わることがあります。これは、rootful Dockerからrootless Dockerへ移行した場合、ユーザーネームスペースの再マッピングを有効にした場合、または別のローカルアカウント構成のホストへデータを復元した場合によく起こります。
Dockerの現在のUID/GIDマッピングのドキュメントでは、rootlessモードとユーザーネームスペースモードによって、コンテナのIDが異なるホストIDへ変換されることが説明されています。そのため、あるホストでは正しく所有されているように見えるファイルが、デプロイモデルの変更後には書き込み不可になることがあります。
新しいホストではアカウント名が異なる番号に対応する可能性があるため、アカウント名だけに頼らず、ls -lnなどのツールで数値の所有権を比較してください。
Home Assistantのデータをコピーする際はメタデータを保持する
移行ツールやGUIのファイルコピーでは、ファイルの内容は保持されても、所有権、モードビット、ACL、拡張属性、セキュリティラベルが保持されないことがあります。その結果、YAMLファイルは読み取れても、データベース、隠しストレージ、証明書、または書き込みに必要なディレクトリで後から失敗する場合があります。
使用しているプラットフォームで必要なメタデータを保持できるコピー方法を使用してください。転送後、Home Assistantを起動する前に、代表的なファイルとディレクトリについてコピー元とコピー先を比較します。
ZimaSpaceのアカウントと権限を家庭内で繰り返し適用できるポリシーとして扱うというガイドの考え方は、ここにも当てはまります。所有権は、その場しのぎの修正の積み重ねではなく、意図的に設計されたインフラであるべきです。
Home Assistantが書き込む必要のある場所だけを読み書き可能なマウントにする
Home Assistantは、永続化された設定とデータベースを更新できなければなりません。マウントが誤って読み取り専用で再作成されると、起動や読み取りはできても、その後の書き込み、バックアップ、データベースのコミット、設定変更などが失敗する可能性があります。
ホストパスのバインドマウントは、読み書き可能または読み取り専用として公開できます。Dockerのファイル共有ガイドでは、実際のマウントモードによって、コンテナがホストディレクトリを変更できるかどうかが決まると説明されています。Composeファイルが意図どおり適用されたと決めつけず、実行中のマウントを確認してください。
逆に、Home Assistantが1つの設定パスへアクセスする必要があるからといって、無関係なホストディレクトリまで書き込み可能にしないでください。権限の境界は狭く保ちます。
復元や再作成のたびに権限受け入れテストを行う
正常に起動したからといって、ファイルシステムの契約がすべて満たされたとは限りません。Home Assistantは既存ファイルを読み取れても、後からデータベースへの書き込み、バックアップの作成、レジストリの更新、ダッシュボードの保存が必要になった際に失敗することがあります。
- 想定した設定とインテグレーションが読み込まれることを確認します。
- UIから管理できる害のない変更を1つ行い、再起動後も保持されることを確認します。
- Recorderが新しい状態変更を書き込むことを確認します。
- インストール形式が対応している場合は、小さなバックアップを作成します。
- 権限拒否、読み取り専用ファイルシステム、データベース書き込みエラーがログにないか確認します。
テストに失敗した場合は、そのパスを管理している所有者、グループ、ACL、ネームスペースマッピング、またはマウントモードを個別に修正します。文書化されたデプロイ手順で、手動の緊急コマンドを使わずに正しいアクセス権を再現できるようになったとき、権限ドリフトは解消されています。
サポートとヒント
もっと読む

Home Assistantのデータベースにメンテナンスまたは交換が必要な兆候
大容量のHome Assistantデータベースでは通常、保存期間の管理やパージ作業が必要です。繰り返し発生する破損や整合性エラーは、交換を検討すべき強い兆候です。

Home Assistantは動作が遅くなる前に、同時に何人のユーザーに対応できますか?
Home Assistantには、実用上の固定されたユーザー数上限はありません。実際のダッシュボードとエンティティの更新を使ってアクティブなクライアントをベンチマークし、再現性のある遅延が発生する前に止めてください。

Home Assistantはアップグレードで問題を起こさずに外部データベースを利用できますか?
外部のRecorderデータベースはアップグレード後も維持できますが、可用性、スキーマ移行、バックアップ、復元、バージョン管理に関する独自の責任が生じます。

