Why Does Home Assistant Recreate Missing Files With the Wrong Owner?

Home Assistant does not choose a friendly host username when it recreates a file. The new file normally inherits the numeric UID, GID, umask, ACL, and filesystem rules of the process that created it inside the container.

This becomes visible on a bind mount because Linux records numeric identities, while the host and container may attach different names to the same number. Before changing permissions, stop Home Assistant, record the old and new numeric owners, identify the runtime process, and determine whether the file was created by Home Assistant, an entrypoint, a backup tool, or the host.

Confirm Which Process Created the File

Compare the file's creation or modification time with the container start, restore, update, or add-on job. Then inspect the numeric UID and GID on the host and the identity of the Home Assistant process inside the container. Usernames can differ; numbers are the reliable comparison.

The underlying container problem is that bind-mounted files are created under the identity used by the container process. An independent explanation of the host filesystem owner mismatch shows why matching names alone does not solve numeric UID and GID differences.

If the new owner matches the container process, the primary cause is confirmed. If it matches root or another helper, inspect the entrypoint, restore tool, scheduled job, or host-side script before changing Home Assistant's runtime user.

Check the Mount, ACL, and Filesystem Boundary

Confirm that the path is the intended bind mount and not a named volume or an image directory hidden by the mount. Check the parent directory owner, mode, default ACL, and whether the filesystem is local, NFS, SMB, or another network-backed path.

A process can create a file only according to the permissions and mapping the filesystem presents. NFS identity mapping, root squashing, SMB mount options, default ACLs, and a restrictive umask can change the apparent owner or write access even when the container UID is correct.

If a temporary file created as the runtime UID receives the expected owner, continue to the application-specific creator. If it receives the wrong owner, repair the mount or filesystem mapping first; changing Home Assistant configuration will not override that layer.

Repair Only the Confirmed Ownership Mismatch

Stop Home Assistant before changing active database, registry, or configuration file ownership. Create a backup or snapshot, then change only the affected path to the verified service UID and GID. Preserve executable bits, ACLs, and special permissions rather than applying a broad mode such as world-writable access.

Update the deployment definition so the same runtime identity is used after recreation, or document why the image must run under its default identity and make the host path match it. Avoid a startup chown of the entire tree on every boot; it can be slow, hide design errors, and alter files owned by other services.

The ZimaSpace guide to preventing permission drift provides the wider operating checklist for mounts, ownership, write tests, and restore behavior after the immediate owner mismatch is corrected.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verify Ownership After Recreation and a Real Write

Start Home Assistant and trigger the exact operation that recreated the file. Confirm the new file has the intended numeric owner, Home Assistant can update it, and the host-side backup process can read it. A successful start without a write does not prove the fix.

Restart once and recreate the container from the saved configuration. The owner, ACL, and write behavior must remain stable after both events. Check logs for permission denied, read-only database, failed backup, or integration setup errors.

Escalate to the image maintainer or storage administrator if the creating identity changes unexpectedly between versions, a network filesystem rewrites ownership, or a required service cannot share the path safely. Preserve the numeric IDs, mount definition, filesystem type, and minimal reproduction.