Network share not mounting from reboot (Frigate)

Configuration
1

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.

1 Like
2

same here,
only if there was a sensor for the external storage state.
i’m also making a workarround right now.
how is your code?
my:

alias: frigate restart na 30 ha started
description: “”
triggers:

  • trigger: homeassistant
    event: start
    conditions:
    actions:
  • delay:
    hours: 0
    minutes: 1
    seconds: 0
    milliseconds: 0
  • action: hassio.addon_restart
    metadata: {}
    data:
    addon: ccab4aaf_frigate-fa
    mode: single
3

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.

4

Hi,

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

5

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.

2 Likes
6

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) :thinking:

7

Where is your nfs/cifs share mounted through HA?
(It’s gonna be either /share/something or /media/something

put that path in frigate.yml

E.g.:

database:
  path: /media/frigate/db/frigate.db

then:
mv /config/frigate.db* /media/frigate/db/

Make sure the directory exists before starting frigate as it won’t create the DB there as per usual.

3 Likes
8

Excellent, this works :+1:t3:

Thank you, @reedy

1 Like
9

Thanks @reedy ! This worked a treat. Less automations and things to worry about. Wish still that the original issue would be “fixed” so I don’t need to move files and update configs to get it to work “out of the box”.

10

Tried @reedy’s change and set my database to /media/frigate/frigate.db. I copied my /config/frigate.db* files to /media/frigate but my frigate now fails to start with an error like:

2025-03-08 21:20:08.634255940  Exception in thread Thread-3:
2025-03-08 21:20:08.634261607  Traceback (most recent call last):
2025-03-08 21:20:08.634263690    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 3263, in connect
2025-03-08 21:20:08.635957187      self._state.set_connection(self._connect())
2025-03-08 21:20:08.635961919    File "/opt/frigate/frigate/db/sqlitevecq.py", line 14, in _connect
2025-03-08 21:20:08.636066990      conn: sqlite3.Connection = super()._connect(*args, **kwargs)
2025-03-08 21:20:08.636090665    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 3607, in _connect
2025-03-08 21:20:08.636761365      self._add_conn_hooks(conn)
2025-03-08 21:20:08.636764433    File "/usr/local/lib/python3.9/dist-packages/playhouse/sqlite_ext.py", line 1084, in _add_conn_hooks
2025-03-08 21:20:08.637767847      super(SqliteExtDatabase, self)._add_conn_hooks(conn)
2025-03-08 21:20:08.637770577    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 3617, in _add_conn_hooks
2025-03-08 21:20:08.638262712      self._set_pragmas(conn)
2025-03-08 21:20:08.638264764    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 3632, in _set_pragmas
2025-03-08 21:20:08.638779976      cursor.execute('PRAGMA %s = %s;' % (pragma, value))
2025-03-08 21:20:08.638801719  pysqlite3.dbapi2.OperationalError: locking protocol

If I don’t copy over the DB, then it gets this error:

2025-03-08 21:26:18.757398055  Traceback (most recent call last):
2025-03-08 21:26:18.757401523    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 3322, in execute_sql
2025-03-08 21:26:18.757402542      cursor.execute(sql, params or ())
2025-03-08 21:26:18.757405939  pysqlite3.dbapi2.OperationalError: database is locked
2025-03-08 21:26:18.757407014  
2025-03-08 21:26:18.757407815  During handling of the above exception, another exception occurred:
2025-03-08 21:26:18.757425543  
2025-03-08 21:26:18.757426383  Traceback (most recent call last):
2025-03-08 21:26:18.757427576    File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
2025-03-08 21:26:18.757428623      return _run_code(code, main_globals, None,
2025-03-08 21:26:18.757429397    File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
2025-03-08 21:26:18.757430171      exec(code, run_globals)
2025-03-08 21:26:18.757430970    File "/opt/frigate/frigate/__main__.py", line 64, in <module>
2025-03-08 21:26:18.757447949      main()
2025-03-08 21:26:18.757448888    File "/opt/frigate/frigate/__main__.py", line 60, in main
2025-03-08 21:26:18.757449648      FrigateApp(config).start()
2025-03-08 21:26:18.757450383    File "/opt/frigate/frigate/app.py", line 593, in start
2025-03-08 21:26:18.757458428      self.init_database()
2025-03-08 21:26:18.757459271    File "/opt/frigate/frigate/app.py", line 161, in init_database
2025-03-08 21:26:18.757459875      if len(router.diff) > 0:
2025-03-08 21:26:18.757460771    File "/usr/local/lib/python3.9/dist-packages/peewee_migrate/router.py", line 85, in diff
2025-03-08 21:26:18.757461444      done = set(self.done)
2025-03-08 21:26:18.757462293    File "/usr/local/lib/python3.9/dist-packages/peewee_migrate/router.py", line 80, in done
2025-03-08 21:26:18.757463237      return [mm.name for mm in self.model.select().order_by(self.model.id)]
2025-03-08 21:26:18.757464001    File "/usr/lib/python3.9/functools.py", line 969, in __get__
2025-03-08 21:26:18.757464719      val = self.func(instance)
2025-03-08 21:26:18.757474394    File "/usr/local/lib/python3.9/dist-packages/peewee_migrate/router.py", line 69, in model
2025-03-08 21:26:18.757475147      MigrateHistory.create_table(safe=True)
2025-03-08 21:26:18.757475954    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 7078, in create_table
2025-03-08 21:26:18.757476999      cls._schema.create_all(safe, **options)
2025-03-08 21:26:18.757477770    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 6171, in create_all
2025-03-08 21:26:18.757478474      self.create_table(safe, **table_options)
2025-03-08 21:26:18.757479273    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 6022, in create_table
2025-03-08 21:26:18.757490342      self.database.execute(self._create_table(safe=safe, **options))
2025-03-08 21:26:18.757491181    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 3330, in execute
2025-03-08 21:26:18.757491904      return self.execute_sql(sql, params)
2025-03-08 21:26:18.757492690    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 3322, in execute_sql
2025-03-08 21:26:18.757493472      cursor.execute(sql, params or ())
2025-03-08 21:26:18.757494268    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 3088, in __exit__
2025-03-08 21:26:18.757494997      reraise(new_type, new_type(exc_value, *exc_args), traceback)
2025-03-08 21:26:18.757495770    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 196, in reraise
2025-03-08 21:26:18.757496429      raise value.with_traceback(tb)
2025-03-08 21:26:18.757510212    File "/usr/local/lib/python3.9/dist-packages/peewee.py", line 3322, in execute_sql
2025-03-08 21:26:18.757511052      cursor.execute(sql, params or ())
2025-03-08 21:26:18.757511792  peewee.OperationalError: database is locked
2025-03-08 21:26:19.053281530  2025/03/08 13:26:19 [error] 179#179: *6 connect() failed (111: Connection refused) while connecting to upstream

Did you guys do something different when moving the frigate.db?

Looking online I found this thread Database is locked · Issue #712 · blakeblackshear/frigate · GitHub which says sqlite doesn’t like being on a network share.

11

Only move the db files. Leave the config/yaml in its original location (i.e with your HA config yaml).

I ONLY move the db files to the NAS.
However recently I got some errors in logs about pysqlite3.dbapi2.DatabaseError: database disk image is malformed

I will try seeing if I can mount an external HDD via USB to HA (using udev rules) and skip using a NAS location to see if it runs smoother.

12

Any luck? Getting frustrated with this…

13

No luck I dont think in a “fix”, but I did as @reedy suggested.

Keep frigate.yaml config file in its normal place (where you have your HA config.yaml etc).

Move the files to your network drive / where you want them. Equally dont, and just start fresh (Frigate will recreate needed files if they dont exist)

Add the below to your frigate config

database:
  path: /media/frigate/db/frigate.db #here I have a share called "NVR" (with a folder called "db") on my NAS, mounted to the location "media/frigate" in HA. The path here in the config should the the path as it appears in HA.

This means Frigate when starting will wait / error out until it finds the DB in the location you have told it to in the config, this means if the mount happens after frigate starts up, Frigate just waits until it “sees” the DB location.
I have not had any instances where Frigate creates DB / recordings etc on my local disk using this method.

14

I just wanted to give a hint, why this solution does seem to work for some people but not for others:

In my case, I also got the database locked error, when accessing the DB via a SMB share. But after reconfiguring the “frigate” share as an NFS share on the file server and in HA, it’s working fine.

This problem seems to occur especially with SMB shares, but not with NFS. Thus, it is possible to move the db to a network share, but you have to use NFS.

15

I have a slightly different issue. I am trying to migrate to network storage, but I simply can not locate where is /data/media/frigate even with a root shell into Home Assistant.

16

Look within /usr/share/hassio/media/frigate

17

… And 2 weeks later… :wink:

Today I finally gave up on this approach. At least with my setup there seem to be ever so little hickups in the connectivity of the NFS mount that nobody and nothing else seems to care about, but lead to peewee panicking about a lost database connection every couple of days and shutting down any frigate activity apart from flooding the log with error messages.

Unfortunately just flooding the log with errors doesn’t trigger the addon’s watchdog and so the addon just sits there complaining, until someone restarts it manually.

Thus, today I moved the frigate database back to the default folder on a local drive.

To prevent frigate from running before the frigate mount is ready, I will disable the “Start on Boot” option and (re)start the addon from a HA automation. Maybe just with a simple trigger firing 2 minutes after a HA restart or by testing the availability of the mount and starting the addon after the mount becoming available.

18

brilliant! it works very well
Huge thanks