Can Home Assistant Run Reliably With Its Data on a Network Share?

Home Assistant can use network storage reliably for backups, media, and some shared files, but putting the live configuration directory or default SQLite Recorder database on SMB or NFS is a much more demanding design. The safer default is local persistent storage for active Home Assistant state and a network share for data that benefits from remote capacity or independent backup.

The difference is transactional behavior and startup dependency. A backup archive can wait for the NAS; the Home Assistant configuration and database may be required before the network share is mounted or healthy. A short NAS outage should not turn a healthy local controller into an empty or corrupted installation.

Separate Backup and Media Shares From Live Application State

Start by naming what you want to move. Backup archives and media files are naturally suited to a NAS because they are large, transferable objects and do not have to be opened for continuous transactional writes by Home Assistant Core.

Live application state is different. The config tree includes UI-managed storage and other files that Home Assistant expects to read and update during normal operation, while Recorder continuously writes state and event history.

The ZimaSpace private-cloud example separates Home Assistant recovery from bulk NAS storage, which is the useful architecture here: network capacity can grow independently without making every control action depend on the storage share.

SQLite Adds Locking and Consistency Requirements

The default Home Assistant Recorder database is SQLite. That database expects filesystem behavior that is easy to provide on local storage and less predictable across network filesystems, reconnects, and mount implementations.

SQLite is not designed as a network database server, and network filesystem locking can be unreliable or incomplete depending on the platform. That makes a remote SQLite file a different risk from simply reading media over SMB.

If you need a database on another host, use a supported client/server database and accept the operational responsibility that comes with that external dependency. Do not assume moving the SQLite file itself creates the same architecture.

Mount Timing Can Break Startup Even When the Share Works Later

A network share may be writable once the system is fully booted but still be unavailable when Home Assistant first needs the database or configuration. That creates a startup-order problem that a later manual write test cannot detect.

A Home Assistant user who placed Recorder SQLite on SMB saw zero-byte and corrupt database files during startup even though the share could be written from the host. The discussion specifically raised mount timing and the suitability of SQLite on a network share.

Test cold boot, host reboot, NAS reboot, and a temporary share outage. A design that works only after manually remounting the NAS is not reliable enough for whole-home control.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Network Latency Can Make History Slow Without Breaking Control

Remote database or config I/O adds network latency to small reads and writes. That may first appear as slow history graphs, database maintenance, or startup rather than failed automations.

A Home Assistant Kubernetes deployment reported that SQLite over NFS and a remote SQL path produced poor database responsiveness, leading the author to move the active database path closer to the Home Assistant workload.

Measure the specific symptom. If local control remains fast while history is slow, the database path is likely affecting historical features rather than the physical automation itself. If the share also hosts critical config, an outage can expand the failure into the whole service.

Prefer Local State and Network Backup for a Small Server

For most home servers, keep /config and the default SQLite database on a reliable local SSD or other persistent device. Send backups to the NAS, store media there, and use network shares for large data that benefits from central capacity.

This split is easier to diagnose: local database latency belongs to the Home Assistant host, while a missing backup or media file belongs to the NAS path. The network remains useful without becoming a synchronous dependency for every state write.

Move active state to remote storage only when the share, mount ordering, locking semantics, latency, failure behavior, and restore path have all been tested under cold start and temporary network loss.

FAQ

Is a NAS a good place for Home Assistant backups?

Yes. A NAS is often a good independent destination for backup archives, especially when the copy survives failure of the Home Assistant system disk. Keep another copy elsewhere if the NAS and Home Assistant host still share the same physical failure domain.

Should I put the default Home Assistant SQLite database directly on SMB or NFS?

Usually not. Keep SQLite on local reliable storage unless you have a specific tested reason to do otherwise. If the database must be remote, a supported client/server database is a cleaner architecture than treating the SQLite file as an ordinary network document.