Perché Home Assistant ricrea i file mancanti con il proprietario sbagliato?
Home Assistant non sceglie un nome utente host intuitivo quando ricrea un file. Il nuovo file eredita normalmente l’UID numerico, il GID, l’umask, l’ACL e le regole del filesystem del processo che lo ha creato all’interno del container.
Questo diventa evidente con un bind mount perché Linux registra le identità numeriche, mentre host e container possono associare nomi diversi allo stesso numero. Prima di modificare i permessi, arresta Home Assistant, annota i vecchi e i nuovi proprietari numerici, identifica il processo di runtime e determina se il file è stato creato da Home Assistant, da un entrypoint, da uno strumento di backup o dall’host.
Conferma quale processo ha creato il file
Confronta l’ora di creazione o modifica del file con l’avvio del container e con l’esecuzione di attività di ripristino, aggiornamento o add-on. Quindi controlla l’UID e il GID numerici sull’host e l’identità del processo Home Assistant all’interno del container. I nomi utente possono differire; i numeri sono il confronto affidabile.
Il problema alla base del container è che i file nei bind mount vengono creati con l’identità utilizzata dal processo del container. Una spiegazione indipendente del mancato allineamento del proprietario del filesystem dell’host mostra perché la semplice corrispondenza dei nomi non risolve le differenze tra UID e GID numerici.
Se il nuovo proprietario corrisponde al processo del container, la causa principale è confermata. Se corrisponde a root o a un altro processo ausiliario, esamina l’entrypoint, lo strumento di ripristino, l’attività pianificata o lo script lato host prima di modificare l’utente di runtime di Home Assistant.
Controlla il mount, l’ACL e il confine del filesystem
Conferma che il percorso sia il bind mount previsto e non un volume denominato o una directory dell’immagine nascosta dal mount. Controlla il proprietario della directory padre, la modalità, l’ACL predefinita e se il filesystem è locale, NFS, SMB o un altro percorso basato sulla rete.
Un processo può creare un file solo in base ai permessi e alla mappatura presentati dal filesystem. La mappatura delle identità NFS, il root squashing, le opzioni di mount SMB, le ACL predefinite e un’umask restrittiva possono modificare il proprietario apparente o l’accesso in scrittura anche quando l’UID del container è corretto.
Se un file temporaneo creato con l’UID di runtime riceve il proprietario previsto, passa all’identificazione del processo specifico dell’applicazione. Se riceve il proprietario errato, correggi prima il mount o la mappatura del filesystem; modificare la configurazione di Home Assistant non supererà quel livello.
Correggi solo la mancata corrispondenza del proprietario confermata
Arresta Home Assistant prima di modificare il proprietario dei database, dei registri o dei file di configurazione attivi. Crea un backup o uno snapshot, quindi modifica solo il percorso interessato assegnandolo all’UID e al GID di servizio verificati. Conserva i bit di esecuzione, le ACL e i permessi speciali invece di applicare una modalità ampia, come l’accesso in scrittura a tutti.
Aggiorna la definizione del deployment in modo che dopo la ricreazione venga utilizzata la stessa identità di runtime, oppure documenta perché l’immagine debba essere eseguita con la propria identità predefinita e fai corrispondere a essa il percorso sull’host. Evita un chown all’avvio dell’intero albero a ogni boot: può essere lento, nascondere errori di progettazione e modificare file appartenenti ad altri servizi.
La guida di ZimaSpace per prevenire la deriva dei permessi offre la checklist operativa più ampia per mount, proprietà, test di scrittura e comportamento del ripristino dopo aver corretto la mancata corrispondenza immediata del proprietario.
Verifica il proprietario dopo la ricreazione e una scrittura reale
Avvia Home Assistant e attiva esattamente l’operazione che ha ricreato il file. Conferma che il nuovo file abbia il proprietario numerico previsto, che Home Assistant possa aggiornarlo e che il processo di backup lato host possa leggerlo. Un avvio riuscito senza una scrittura non dimostra che la correzione sia efficace.
Riavvia una volta e ricrea il container dalla configurazione salvata. Il proprietario, l’ACL e il comportamento in scrittura devono rimanere stabili dopo entrambi gli eventi. Controlla i log per errori di permesso negato, database in sola lettura, backup non riusciti o errori di configurazione delle integrazioni.
Rivolgiti al manutentore dell’immagine o all’amministratore dello storage se l’identità che crea i file cambia inaspettatamente tra le versioni, un filesystem di rete riscrive la proprietà o un servizio necessario non può condividere il percorso in sicurezza. Conserva gli ID numerici, la definizione del mount, il tipo di filesystem e una riproduzione minima.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Come ottimizzare le connessioni al database di Home Assistant per container simultanei
Ottimizza un database Recorder esterno in base alle connessioni attive e alla latenza misurate, senza aumentare il numero massimo di connessioni né copiare il...
Come evitare duplicati di processi o importazioni in Home Assistant
Usa tracce e chiavi operative univoche per rendere sicuri i nuovi tentativi di automazioni e importazioni, evitando di generare azioni o record duplicati.
Come riparare Home Assistant dopo che il volume del database si è riempito
Recupera da un volume Recorder completamente pieno senza eliminare prima le prove, poi riduci la crescita e dimostra che la cronologia e le automazioni...
