Comment éviter la dérive des permissions dans les dossiers de données de Home Assistant

La dérive des permissions se produit lorsque les données de Home Assistant sont toujours présentes, mais que le processus qui les monte désormais détecte une propriété, des correspondances UID/GID, des modes d’accès ou un contexte de sécurité différents de ceux du processus qui les a créées. La défaillance survient souvent après une migration de l’hôte, une restauration, une modification du mode Docker, une copie depuis un NAS ou l’exécution manuelle de chown/chmod.

Pour l’éviter, documentez le modèle de montage et de propriété attendu avant toute modification, préservez les métadonnées lors des copies et testez les accès en lecture et en écriture après la recréation. Ne remédiez pas à chaque défaillance avec chmod -R 777 ; cela masque la discordance et fragilise le modèle de récupération.

Documentez la limite de stockage avant de modifier les permissions

Commencez par déterminer si /config est un volume géré par Docker, un montage bind Linux, un montage réseau ou un chemin situé dans une machine virtuelle. La stratégie de propriété appropriée dépend de la couche qui possède réellement les fichiers.

Les recommandations actuelles du guide d’installation de Home Assistant en conteneur rendent ce contrat de stockage concret : le dossier hôte sélectionné est monté sur /config avec un accès en lecture/écriture. Notez précisément le chemin source, la cible du montage et le mode d’accès, plutôt que de vous fier uniquement au nom du dossier.

Notez également si Home Assistant s’exécute avec Docker standard, Docker rootless, un espace de noms utilisateur remappé ou un gestionnaire de conteneurs NAS. Les identités numériques visibles à l’intérieur et à l’extérieur du conteneur peuvent ne pas être les mêmes.

La correspondance UID/GID peut changer sans que les fichiers soient déplacés

Un dossier peut rester au même emplacement sur l’hôte tandis que la correspondance effective des utilisateurs change en arrière-plan. Cela arrive notamment lors du passage de Docker avec privilèges à Docker rootless, de l’activation du remappage des espaces de noms utilisateur ou de la restauration des données sur un hôte doté de comptes locaux différents.

La documentation actuelle de Docker sur la correspondance UID/GID montre que les modes rootless et les espaces de noms utilisateur traduisent les identités des conteneurs en identifiants hôte différents. Un fichier qui semble correctement détenu sur un hôte peut donc devenir impossible à modifier après un changement de modèle de déploiement.

Comparez la propriété numérique avec ls -ln ou des outils équivalents au lieu de vous fier uniquement aux noms de comptes, qui peuvent correspondre à des numéros différents sur le nouvel hôte.

Préservez les métadonnées lors de la copie des données de Home Assistant

Un outil de migration ou une copie de fichiers via une interface graphique peut préserver le contenu des fichiers, mais pas la propriété, les bits de mode, les ACL, les attributs étendus ou les étiquettes de sécurité. Les fichiers YAML peuvent alors rester lisibles tandis que les bases de données, le stockage masqué, les certificats ou les dossiers nécessaires aux écritures échouent ultérieurement.

Utilisez une méthode de copie qui préserve les métadonnées réellement utilisées par votre plateforme. Après le transfert, comparez des fichiers et dossiers représentatifs de la source et de la destination avant de démarrer Home Assistant.

Le guide de ZimaSpace sur la gestion des comptes et des permissions comme une politique domestique reproductible s’applique ici : la propriété doit relever d’une infrastructure délibérée, et non d’une suite de corrections ponctuelles.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Conservez le montage en lecture/écriture uniquement là où Home Assistant doit écrire

Home Assistant doit pouvoir mettre à jour sa configuration persistante et sa base de données. Un montage recréé accidentellement en lecture seule peut autoriser le démarrage et les lectures, tout en provoquant ultérieurement l’échec des écritures, des sauvegardes, des validations de base de données ou des modifications de configuration.

Les chemins hôtes montés avec bind peuvent être exposés en lecture/écriture ou en lecture seule. Le guide Docker sur le partage de fichiers montre que le mode de montage effectif détermine si un conteneur peut modifier le dossier hôte. Vérifiez le montage du conteneur en cours d’exécution au lieu de supposer que le fichier Compose a été appliqué comme prévu.

À l’inverse, ne rendez pas accessibles en écriture des dossiers hôtes sans rapport simplement parce que Home Assistant doit accéder à un seul chemin de configuration. Gardez la limite de permissions aussi étroite que possible.

Effectuez un test d’acceptation des permissions après chaque restauration ou recréation

Un démarrage réussi ne prouve qu’une partie du contrat du système de fichiers. Home Assistant peut lire les fichiers existants, mais échouer ultérieurement lorsqu’il doit écrire dans la base de données, créer une sauvegarde, mettre à jour un registre ou enregistrer un tableau de bord.

• Vérifiez que la configuration et les intégrations attendues se chargent.
• Effectuez une modification sans risque gérée depuis l’interface et vérifiez qu’elle est conservée après le redémarrage.
• Vérifiez que Recorder enregistre un nouveau changement d’état.
• Créez une petite sauvegarde si le type d’installation le permet.
• Consultez les journaux pour repérer les erreurs d’accès refusé, de système de fichiers en lecture seule ou d’écriture de base de données.

Si le test échoue, corrigez précisément le propriétaire, le groupe, l’ACL, la correspondance d’espace de noms ou le mode de montage qui contrôle le chemin. La dérive des permissions est corrigée lorsque le déploiement documenté peut recréer les bons accès sans commandes d’urgence manuelles.