Pourquoi Home Assistant recrée-t-il les fichiers manquants avec le mauvais propriétaire ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Why Does Home Assistant Recreate Missing Files With the Wrong Owner? - Zima Store Online

Home Assistant ne choisit pas un nom d’utilisateur hôte convivial lorsqu’il recrée un fichier. Le nouveau fichier hérite normalement de l’UID numérique, du GID, de l’umask, de l’ACL et des règles du système de fichiers du processus qui l’a créé à l’intérieur du conteneur.

Cette situation devient visible avec un montage bind, car Linux enregistre les identités numériques, tandis que l’hôte et le conteneur peuvent associer des noms différents au même nombre. Avant de modifier les permissions, arrêtez Home Assistant, notez les anciens et nouveaux propriétaires numériques, identifiez le processus d’exécution et déterminez si le fichier a été créé par Home Assistant, un point d’entrée, un outil de sauvegarde ou l’hôte.

Confirmer quel processus a créé le fichier

Comparez la date de création ou de modification du fichier avec le démarrage du conteneur, une restauration, une mise à jour ou l’exécution d’un module complémentaire. Examinez ensuite l’UID et le GID numériques sur l’hôte, ainsi que l’identité du processus Home Assistant à l’intérieur du conteneur. Les noms d’utilisateur peuvent différer ; les nombres constituent la comparaison fiable.

Le problème sous-jacent du conteneur est que les fichiers montés par bind sont créés avec l’identité utilisée par le processus du conteneur. Une explication indépendante du décalage de propriétaire entre l’hôte et le système de fichiers explique pourquoi faire correspondre uniquement les noms ne résout pas les différences d’UID et de GID numériques.

Si le nouveau propriétaire correspond au processus du conteneur, la cause principale est confirmée. S’il correspond à root ou à un autre processus auxiliaire, examinez le point d’entrée, l’outil de restauration, la tâche planifiée ou le script exécuté côté hôte avant de modifier l’utilisateur d’exécution de Home Assistant.

Vérifier le montage, l’ACL et la limite du système de fichiers

Confirmez que le chemin correspond au bind mount prévu, et non à un volume nommé ou à un répertoire de l’image masqué par le montage. Vérifiez le propriétaire du répertoire parent, son mode, son ACL par défaut, ainsi que le type de système de fichiers : local, NFS, SMB ou autre chemin reposant sur le réseau.

Un processus ne peut créer un fichier qu’en fonction des permissions et du mappage présentés par le système de fichiers. Le mappage des identités NFS, la restriction root squash, les options de montage SMB, les ACL par défaut et une umask restrictive peuvent modifier le propriétaire apparent ou l’accès en écriture, même lorsque l’UID du conteneur est correct.

Si un fichier temporaire créé avec l’UID d’exécution reçoit le propriétaire attendu, poursuivez l’analyse du processus créateur propre à l’application. S’il reçoit le mauvais propriétaire, corrigez d’abord le montage ou le mappage du système de fichiers ; modifier la configuration de Home Assistant ne contournera pas cette couche.

Réparer uniquement le décalage de propriété confirmé

Arrêtez Home Assistant avant de modifier la propriété des fichiers actifs de base de données, de registre ou de configuration. Créez une sauvegarde ou un instantané, puis modifiez uniquement le chemin concerné afin de lui attribuer l’UID et le GID vérifiés du service. Préservez les bits d’exécution, les ACL et les permissions spéciales au lieu d’appliquer un mode large, comme un accès accessible en écriture à tous.

Mettez à jour la définition du déploiement afin que la même identité d’exécution soit utilisée après la recréation, ou documentez pourquoi l’image doit s’exécuter avec son identité par défaut et faites correspondre le chemin hôte à celle-ci. Évitez d’exécuter un chown au démarrage sur l’ensemble de l’arborescence à chaque lancement ; cela peut être lent, masquer des erreurs de conception et modifier des fichiers appartenant à d’autres services.

Le guide ZimaSpace consacré à la prévention de la dérive des permissions fournit une liste de vérifications plus complète concernant les montages, la propriété, les tests d’écriture et le comportement des restaurations une fois le décalage immédiat de propriétaire corrigé.

-15% OFF

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

Single board computer zimaboard2

Vérifier la propriété après la recréation et une véritable écriture

Démarrez Home Assistant et déclenchez exactement l’opération qui a recréé le fichier. Confirmez que le nouveau fichier possède le propriétaire numérique prévu, que Home Assistant peut le mettre à jour et que le processus de sauvegarde côté hôte peut le lire. Un démarrage réussi sans écriture ne prouve pas que le problème est résolu.

Redémarrez une fois, puis recréez le conteneur à partir de la configuration enregistrée. Le propriétaire, l’ACL et le comportement d’écriture doivent rester stables après ces deux événements. Consultez les journaux pour détecter les erreurs d’accès refusé, de base de données en lecture seule, de sauvegarde échouée ou de configuration d’intégration.

Adressez-vous au responsable de l’image ou à l’administrateur du stockage si l’identité créatrice change de manière inattendue entre les versions, si un système de fichiers réseau réécrit la propriété ou si un service requis ne peut pas partager le chemin en toute sécurité. Conservez les identifiants numériques, la définition du montage, le type de système de fichiers et une reproduction minimale.