Yea I removed it but am still getting the same error and a endless restart loop.

Turns out it was the detector model I was using.

I was using yolov9, after switching to v8 it started working just fine.

13 hours ago, JWMutant said:

Turns out it was the detector model I was using.

I was using yolov9, after switching to v8 it started working just fine.

Did you created a V9 model?

On 5/13/2026 at 3:31 PM, Glodenox said:

I ran into an issue where the Docker container didn't want to start any more after the upgrade to Unraid 7.3.0, with the following error:

Error response from daemon: error while creating mount source path '/etc/localtime': mkdir /etc/localtime: file exists

In the end, it turned out that the /etc/localtime symlink on my Unraid instance was pointing towards a file in /usr/share/zoneinfo/ that doesn't exist (any more?). Changing the timezone of the Unraid instance in the settings fixed that reference, and as such fixed the docker bind mount. I hope it helps someone else, so they don't lose half an hour trying to figure this out as well.

Either way, this doesn't seem like a bug with the container. I'm not sure if it is fully related to 7.3.0, but that's what things seem to point to for me.

Just to be sure: Did you create a ticket for that issue?

1 hour ago, p0p said:

Just to be sure: Did you create a ticket for that issue?

I think the problem resides on the Unraid side, not on the container side.

Edited July 1Jul 1 by yayitazale

I had a similar issue when 7.3.x came up and i had to add this key to the frigate docker:

-faxxe

On 6/30/2026 at 4:26 PM, yayitazale said:

https://docs.frigate.video/frigate/installation#ports

8971	Authenticated UI and API access without TLS. Reverse proxies should use this port.

EDIT: You're right, https://docs.frigate.video/configuration/tls, so I just modified the template so that future new installations will use HTTPS by default for the web UI.

Thanks

All good. Happy to help resolve it to the communities benefit..

I’m still having problems with the tensor docker when it comes to recording footage and am pretty sure by now that it’s not my config. But after trying to problem solve for the past 3 days I’m giving it a break for a day before I tackle it again.

It’s basically not capturing any footage.

Any in regards to your earlier question I stupidly downloaded a pre-compiled yolov9 which was the original issue with the detector not working. After compiling. V8 myself I had no more problems

Ok so I have been a busy not so young guy.

When I first started using frigate I loved the whole idea, loved how easy it was to use and set up.

My setup is using an unassigned drive to hold my footage which is an SSD as I didnt want to be spinning up my array for every recording captured. The problem I ran into was I have 2 cameras on a street that sees alot of fitness nuts walking up and down the street, so the SSD started to fill up pretty quick. I didnt want to have to spend each day reviewing and deleting footage in case I missed something important that happened during the night.

So I put my thinking cap on and created a rather automated system that archives footage to the array as well as a whole host of other things not including making sure the database doesnt still think the footage is still there when it has been archived.

I am almost at the stage where I am ready to do a public release..... anyone want to test it for me?

My work in progress https://github.com/JWMutant/frigate-archive

Edited July 17Jul 17 by JWMutant

5 hours ago, JWMutant said:

Ok so I have been a busy not so young guy.

When I first started using frigate I loved the whole idea, loved how easy it was to use and set up.

My setup is using an unassigned drive to hold my footage which is an SSD as I didnt want to be spinning up my array for every recording captured. The problem I ran into was I have 2 cameras on a street that sees alot of fitness nuts walking up and down the street, so the SSD started to fill up pretty quick. I didnt want to have to spend each day reviewing and deleting footage in case I missed something important that happened during the night.

So I put my thinking cap on and created a rather automated system that archives footage to the array as well as a whole host of other things not including making sure the database doesnt still think the footage is still there when it has been archived.

I am almost at the stage where I am ready to do a public release..... anyone want to test it for me?

My work in progress https://github.com/JWMutant/frigate-archive

This is pretty much useless in an UnRAID environment, where the OS already has a built-in system for periodically moving files from the cache pool (designed for use with SSDs) to the disk array (designed for use with HDDs)...

except when the ssd is not part of the cache pool, and unraid cant restore footage and update the database... I can.

23 minutes ago, JWMutant said:

except when the ssd is not part of the cache pool, and unraid cant restore footage and update the database... I can.

Okay, this is useful for a very small percentage of deployments. In any case, if this is really that useful, I think it would be better for you to contribute these features to the main Frigate development branch—not as a separate project—since that’s what a Free Software project created and maintained by a community is for.

https://github.com/blakeblackshear/frigate

Has anyone seen this and know of a fix? after 7.3 unraid update frigate causes my unraid system to lock up as soon as i try to log into unraid. I can ssh into the system but it hangs at the login screen. I was able to track down the image to the frigate docker, once broke the only way to recover is to run this

docker rm -f 7e9a6551969e

/etc/rc.d/rc.docker restart

This seems to kill and delete the docker and I can reboot and log in as normal. But as soon as I try to add the docker again i get the same issue. Not sure if its a unraid issue or a image issue. Will try using docker compose to see if it helps.

1 hour ago, reyes136 said:

Has anyone seen this and know of a fix? after 7.3 unraid update frigate causes my unraid system to lock up as soon as i try to log into unraid. I can ssh into the system but it hangs at the login screen. I was able to track down the image to the frigate docker, once broke the only way to recover is to run this

docker rm -f 7e9a6551969e

/etc/rc.d/rc.docker restart

This seems to kill and delete the docker and I can reboot and log in as normal. But as soon as I try to add the docker again i get the same issue. Not sure if its a unraid issue or a image issue. Will try using docker compose to see if it helps.

Ok seems that docker compose has the same issue with the docker.

Here is the error from the frigate log

I was able to find the main issue which was that after the update it automatically had the plugins still setup. The Intel GPU TOP plugin was installed and looked fine. But something was not. I uninstalled it and re-installed it and most of my errors have gone away. Still fighting a lockup but that was a big issue.