How to Tell Whether Home Assistant Is Using the Expected Configuration File

Home Assistant is using the expected configuration file only when the runtime-reported configuration directory, the mounted host path, and a controlled validation test all point to the same file.

This confusion is common when /config exists inside a container but maps to a different directory on the host, or when an old bind mount and a newly edited copy both contain configuration.yaml. First record the runtime path, trace its mount without changing it, compare file identity and timestamps, then use a harmless reversible marker to prove which tree the running instance reads.

Record the Configuration Directory Reported by the Running Instance

Open System Information from the running Home Assistant instance and record the configuration directory exactly as shown. Also record the installation type, Core version, container or VM name, and the time of the last successful restart. This establishes the runtime view before host paths complicate it.

Community explanations show why /config can refer to an internal path while the corresponding host directory differs by installation. The useful distinction is inside versus outside the container, not one universal filesystem location.

If the reported directory contains the file you edited inside the same runtime namespace, continue to file proof. If it does not, stop editing that copy. If the UI is unavailable, inspect the running process or container arguments and mounts rather than guessing from an old tutorial.

Trace the Host Path Through the Active Mount

Inspect the running container or Compose service and find the source mapped to the runtime configuration directory. Resolve relative paths from the actual Compose project directory. For a VM or HAOS installation, distinguish the guest path from storage visible to the hypervisor.

A Home Assistant project issue documented confusion where the UI showed the path inside the container while the actual HAOS host data lived elsewhere. That host-versus-container path case supports tracing the mount, not copying its exact path to another installation.

Compare the active mount source with the directory in your editor or file share. If they differ, do not merge them yet. Preserve both trees, note their modification times and sizes, and identify which one contains the current entity registry, automations, and recent log activity.

Prove File Identity With a Safe Controlled Change

Before testing, run the configuration check against the same runtime and make a backup of the active tree. Add a harmless, uniquely named comment or other reversible marker to the suspected file, save it, and confirm the timestamp changes where the runtime mount points.

Use the normal configuration validation path, then reload only the relevant reloadable domain when possible. If a full restart is required, restart once after validation and inspect the log for the file or integration you changed. A restart without path proof can simply reload the wrong file again.

The related ZimaSpace article on Home Assistant's data path helps separate a visible frontend state from the persistent configuration and registry files that produced it.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Correct the Mount and Verify Persistence

If the wrong source is mounted, stop Home Assistant, preserve both directories, and correct only the mount definition that recreates the container. Confirm ownership and permissions before start. Do not copy an older tree over newer state unless you have explicitly chosen which data wins.

After startup, repeat the runtime path, mount, timestamp, configuration check, and marker test. A passing result proves the expected file is read, the current registries remain present, and the same mapping survives one container recreation or host restart.

Roll back to the previous mount if Home Assistant starts empty, loses integrations, or reports permission errors. Escalate with the installation type, runtime directory, mount source and destination, and sanitized directory listing when the mapping remains ambiguous; delete duplicate trees only after recovery is independently verified.