Incandescent with rage tonight, because I started fiddling rather than leaving it alone and thus I broke Frigate again, I tried a dozen things (rebooted TN, downgraded Frigate to an earlier app version, upgraded back to current, removed it entirely, reinstalled it).
My fury was second to none (because I don’t seem to learn) and then I remembered your option to get rid of the backup …problem solved and back to normal!
I wonder if I can somehow password protect the Frigate app on TrueNAS UI, then give the pw to my wife and then I can actually enjoy using Frigate rather than fixing it …
Hi all! After so much frustration, i stubled on this page. I tried deleting the bakup file, but didn’t work for me. I even tried using a custom docker yaml, but I had the same issue. My setup was as following: pool/appdataset/frigate (where frigate was a dataset), then i went to the shell and created the “config” folder. Tried deleting the config folder and create it again, I tried deleting the dataset.
Long story short: I went in shell and SUDO mkdir config. And now it’s working! Please let me know if this is helpful. clearly there’s an issue with this app, as it’s the only one I’ve ever had issues like this.
Thanks for the suggestion. I created a new config directory with sudo, but it did not work. The app did “deploy”, but would not even load the UI, and it only deployed once. After stopping and restarting, it threw the same error. Any other ideas? Have you tried stopping and restarting Frigate to make sure it still works? There are a number of things that will get it to upgrade to the latest version, but will subsequently only deploy once.
Yes, as of right now Frigate starts just fine. Another thing that I did change, but I’m not sure it helped: when i recreated the frigate dataset (pool/apps/frigate/config), I changed the dataset preset permissions from SMB to Generic. Can you also test that?
There does appear to be legitimate bug(s) here, but I’ve come up with a workaround that may work for others.
At least part of the issue seems to stem from the SMB dataset preset. I want to have SMB access to this dataset so I can manage the files directly (e.g. backups), which I why I was using SMB preset.
The following workarounds worked for me, although we’ll see how this survives future updates.
If you are starting from scratch:
Create a new dataset with the Generic dataset preset
Create the config and media folders in the shell
Install Frigate
This should work, but you can optionally make an SMB share
If you already have Frigate installed and want to preserve your existing dataset:
Shut down Frigate
Back up config.yml and Frigate.db
Edit the file system permissions for the dataset and strip the ACL, apply recursively, and save
Upgrade to the latest version - currently v0.15.1_1.1.21 (if you’re upgrading from v0.14.X, note that Frigate may modify your config to address certain breaking changes - e.g. they changed some things with recording)
This should work, but you can optionally make an SMB share or, if you already had one, edit the dataset file system permissions to allow access to your SMB users/groups
Hopefully someone fixes this, but if not, hopefully these workarounds help someone.
I’m now running into a similar issue with the Export feature. Could you update to the latest Frigate and see if you can use the Export feature? Mine says it is exporting video, but it is not and throwing a similar error in the log.
After trying a bunch of stuff, the second solution in @BackDatNASUp worked for me. The issue here is frigate not playing nice with ACL permissions. In my case, because I have the dataset set up as an SMB share.
The key is that you need to strip the ACL permissions to get back to Linux permissions. I added the ACL permissions back after the upgrade of the config file (restarting frigate). I suspect this will be an issue again when Frigate thinks my config file needs migration. Then I’ll just repeat these steps until the Frigate brains feel it neccesary to adress this fringe issue.
Thanks for the update. Does your Export feature in Frigate work after resetting the ACL permissions? Mine does not. Also, I just tried upgrading to v0.16.0_1.2.12 and am running into the same issue when it tries to upgrade the config. I really wish someone would fix this.
For anyone running into this issue when upgrading to v0.16.0, stripping the ACLs got my Frigate to deploy correctly and seems to be running without issues. The Export feature works*, even after re-applying the ACLs.
*I’ve had some inconsistent results, so I’m not sure what’s going on with this feature:
Exported successfully before re-applying ACLs
Exported successfully after applying ACLs
Adjusted ACLs again (with Frigate shut down and applied recursively), but the next Export failed on HTTPS
I repeated the Export, but on HTTP, which succeeded, leading me to believe that this was somehow related to HTTPS
I repeated the Export again on HTTPS, and it worked
No idea what’s going on with the Export feature, but at least this isn’t a painful workaround (stripping ACL to get Frigate to get over its permission issue tasks, then re-applying ACL).
Update on the Export feature working intermittently: Export works consistently when exporting a specified time range from a camera’s history. However, it does not work when exporting clips from the Review page.
I still have this issue, although I tried removing config.yaml, striping the ACL and so on.
When I look up the rights in the shell I see:
---------- 1 root root 8192 Feb 17 17:52 backup.db ---------- 1 root root 2352 Feb 17 18:08 backup_config.yaml ---------- 1 root root 2352 Feb 17 17:53 config.yaml ---------- 1 root root 159744 Feb 17 17:53 frigate.db d--------- 2 root root 2 Feb 17 17:52 model_cache
Interesting. However: sudo chmod -R 755 config on the upper config directory doesn´t work as I am not allowed to change the rights via the command prompt (operation not permitted).
I don´t know about last time but I still have this issue.
The log, copied from above:
2025-02-27 01:11:34.168611+00:002025-02-27 01:11:34.168320288 File “/usr/lib/python3.9/shutil.py”, line 308, in copymode
2025-02-27 01:11:34.168620+00:002025-02-27 01:11:34.168332090 chmod_func(dst, stat.S_IMODE(st.st_mode)) 2025-02-27 01:11:34.168629+00:002025-02-27 01:11:34.168332791 PermissionError: [Errno 1] Operation not permitted: ‘/config/backup_config.yaml’ 2025-02-27 01:11:34.484771+00:002025-02-27 01:11:34.484317213 [INFO] Service Frigate exited with code 1 (by signal 0)
The issue is that shutil.py tries to do execute a chmod command which doesn´t work if the share is an advanced ACL one. Anyone any idea how to solve this?
