I have recently spotted something that is causing issues with Frigate.
I followed the documentation in Frigate to have my recordings placed on my NAS so my local drive isn’t eaten up (500GB SSD. HA is running on Proxmox)
I moved the Frigate DB to /config/
I used HA (Settings → System → Storage → Add Network Storage)
Started up Frigate and it all was working great.
Then I noticed if HA was to reboot in anyway, the mount would not happen as it sees there is an existing fold/file in the location (media/frigate).
Here is the Supervisor Error
ERROR (MainThread) [supervisor.mounts.mount] Cannot mount bind_frigate at /data/media/frigate because it is not empty
What I suspect is happening is during a reboot, HA starts up all the Addons.
Frigate is set to start up on boot.
It attempts to look at the media folder and realises its not there (the mount hasnt taken place by HA) so it creates a directory (now this is created on the local drive!)
Then the mount process I guess kicks in, sees stuff in /media and throws and error.
Frigate is happy so I dont notice it until I see my local drive suddenly filling up.
I have worked around this by making sure I un check “Start on Boot” for Frigate. Then created and automation that waits a few mins for HA to start up and then turns on Frigate giving the Network Drive time to mount.
This is not ideal. Does anyone know if this is “normal”. I assume this a sequence thing for when HA boots up. The mount should happen before any Addons start to avoid this issue and have any addons that use mounted drives not try create their own folders.
Yeah or I dont know how feasible a “proper fix” is but that would be better. Make sure all configured mounts happen before addons are started, as a sort of pre req.
My automation is the same, but I added a 5min delay.
I recently enabled gpu passthrough in esxi for frigate as openvino intel can now be used. YAY!
But snapshots don’t work with a pci device passthrough. Backups now only work with backup software utilising a powercli script to shutdown the HAOS vmguest first.
This causes the issue mentioned above. It’s nothing to do with frigate but HAOS itself not mounting things before starting addons(docker containers)…
I noticed this was mostly happening to people using CIFS to mount smb shares.
I’ve switched to using NFS to mount the frigate share to /media/frigate instead.
Now when HA gets restarted every night the nfs mount comes up first then frigate starts without writing to the local disk and causing the above issues.
I beleive this is due to the way nfs is called during systemd. The unit files enable it much earlier during start up.
Also if you are running frigate in docker (Not as an addon in HAOS) you’ll need to add the nfs mount in the compose.yml under - volumes
If you dont want to have a manual “watchdog” for frigate you can use the built in one.
Work arounds are not needed…
In frigate config:
Keep start on boot enabled
Turn on watchdog
Make sure in your frigate.yml you have the DB path set to somewhere on your NFS/CIFS - This is the key, frigate will not start if it can’t find it’s DB. Then it won’t go creating it on local storage.
This gives time for HAOS to mount the remote storage and when the watchdog restarts frigate all the DB and data will be there.
Sounds logical and tempting but how to accomplish this?
However I reconfigure:
database:
path: /config/frigate.db
it wont get accepted if the given path points to outside of the docker container (HA Supervised installation with Frigate as a HA Add-on from the Add-on store)