CorneliousJD

Ever since a recent update I keep getting this in my log over and over again. How can I make sure I fix this? 2019-03-01 15:02:04,922 fail2ban.jailreader [20575]: ERROR No file(s) found for glob /fail2ban/loginLog.json 2019-03-01 15:02:04,922 fail2ban [20575]: ERROR Failed during configuration: Have not found any log file for organizr-auth jail

I was able to get mine working again and so were others by first delete the docker container entirely. Second I deleted the appdata folder for unifivideo as well. Then I installed a fresh copy of the container and let it build its own new appdata folder and all the files within it. I then restored my video recordings and restarted the container. I also added the JVM_MX variable as noted above too and RAM usage has been small and the container has been stable for me.

As personally someone who has not been having issues -- I'm adding it anyway, a quick extra variable to help reduce any potential issues is well worth it. Set your same settings of 1548M to JVM_MX as shown

Please keep us posted on this -- I'm very curious for long-term results, if it's an easy fix adding one more variable the template can be updated easily for this!

This is all i see when I show advanced docker view, it doesn't tell me how much it's using up though. I don't have a hard limit set on any containers that i know of, so I'm not sure how I can see how much it's actually using? I don't seem to be running into any issues on 3.10 though yet after I did a fresh install of it.

What process are you using to check RAM usage of the container? I'm seeing only about 12% total system RAM usage with container uptime of a few DAYS so I'm not sure if I'm hitting an issue here or not? I'd like to look deeper into it.

You know, same thing happened to me actually. I didn't think much of it at the time, though maybe some weird browser cache was causing it, but it's all showing 3.10.1 now and haven't had issues with it since. fingers crossed!

Someone else above told me how to do this, so they should get credit, not me! But... as long as you pointed your recording directory to the same as before, you just need to scan for them. -- I was able to get all my recordings back this way!

Read the posts above. We've all had the same issue. I got around it by taking my latest backup from the apodata of this container. It has auto backups, then deleting appdata and container. Then restoring from backup when the new container is in initial setup.

I'm sure SOMETHING went awry with the upgrade which is why it happened to us all at the same time, however I wouldn't go with the CK-Gen2+ yet... There's a lot of controversy around it, they said they'd offer docker images for UniFi protect, then backpedaled and said they wont support anything OTHER than the CK-Gen2 until they have it "working and stable" and then they'd see about developing a "roll your own" solution. This goes against the entire reason why I bought UniFi cameras in the first place, so I didn't have to buy special hardware for an NVR... Now they're saying, for now, we have to. That doesn't sit well with me. It's also why i haven't bought more UniFi cams yet. If/when they actually release a docker container for Protect, I'm sure most will want to move to that unless they have legacy cams that Protect wont support for some reason. Until then, I'm staying with UniFi Video for now.

Ok so I blew away the whole container and my appdata folder, set it up again on :latest and restored from backup and now I'm on 3.10.1 with my cameras actually showing up/online and all my recordings active still. Looks like we're back in business, thanks for this tip!

Good to know - I can give that a try. Is there any update on when the new update will work though without causing everything to break? Instead of messing with it so much now and potentially redoing it all again later I may just wait it out.

I only currently have one camera hooked up.

I tried that but it still won't show up in the controller at all, it doesn't give me any sort of error either?

At this point I think I need to reset the camera to defaults, but I'm not sure if that will wipe out my network settings or not and how it connects to WiFi, if it does that's not really an option because I can't get the cameras down right now from where they are. If anyone else has any suggestions that would be helpful. Thank you.

Well I've now somehow made it worse. I clicked "unmange" on the camera, and then tried to manage it again, and it got stuck in the same "Managing" state with an orange icon. I did realize my firmware mistake, I was using original UVC Micro and not the G3 Micro firmware, so I downgraded the firmware some, and that worked and took and I can log back into the camera, but now in my controller nothing shows under cameras, managed or unmanaged.

Weird, I don't think my firmware got updated - but I did try to go download an older release and update via web UI of the camera and it just says it's unsupported.

Ah thanks, this did work. Something else weird going on though is now my camera says it's offline, even though I can see it in the list with an orange dot that says managing. The IP address it shows is valid and I can hit the web UI of the camera itself.

As always guys, thanks for what you do! This was a super quick/easy transition for me. Just pointed to the same appdata and my reverse proxy I had setup still worked, no issues so far on everything. I had way more ports mapped on my OLD container for some reason, but I'm not sure what they were honestly even all doing. Attached here just incase, but I didn't re-create them, just left the defaults in the new template alone and all seems good.

Let it run long enough again this time and it starts locking up the server pretty much until I end this container, but I gathered some logs 2019-02-18 08:38:49.997164 [warn] PUID not defined (via -e PUID), defaulting to '99' 2019-02-18 08:38:50.179288 [warn] PGID not defined (via -e PGID), defaulting to '100' 2019-02-18 08:38:50.341849 [info] Permissions already set for volume mappings Starting unifi-video... (unifi-video) checking for system.properties and truststore files... done. /run.sh: line 107: 7858 Aborted mongo --quiet localhost:7441 --eval "{ ping: 1}" > /dev/null 2>&1 /run.sh: line 107: 8125 Aborted mongo --quiet localhost:7441 --eval "{ ping: 1}" > /dev/null 2>&1 /run.sh: line 107: 8802 Aborted mongo --quiet localhost:7441 --eval "{ ping: 1}" > /dev/null 2>&1 /run.sh: line 107: 8884 Aborted mongo --quiet localhost:7441 --eval "{ ping: 1}" > /dev/null 2>&1 /run.sh: fork: retry: Resource temporarily unavailable /run.sh: fork: retry: Resource temporarily unavailable Then when I closed the container it ended with this. /run.sh: line 107: 26679 Aborted mongo --quiet localhost:7441 --eval "{ ping: 1}" > /dev/null 2>&1 Waiting for mongodb to come online...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... EDIT: For now I changed my repo to pducharme/unifi-video-controller:3.9.11 and it's at least up and online now. Although all my previous recordings appear to be gone

I changed to :testing to see if that would change anything, but it was sitting at "UniFi Video is Upgrading" for well over an hour, so I closed it and removed :testing from the version and it's still doing the same thing, all my logs show now are 2019-02-18 08:38:49.997164 [warn] PUID not defined (via -e PUID), defaulting to '99' 2019-02-18 08:38:50.179288 [warn] PGID not defined (via -e PGID), defaulting to '100' 2019-02-18 08:38:50.341849 [info] Permissions already set for volume mappings Starting unifi-video... (unifi-video) checking for system.properties and truststore files... done. And the WebUI is just "UniFi Video is Updating" and spinning over and and over and doesn't seem to actually be doing anything now.

Something broke last night with the latest update, woke up to all cameras offline making the offline "beep" noise it does, docker was started but logs showing it aboriting mongo and webUI wouldn't load.

Awesome, that makes it easy, thanks!!!

Had found this out from the github page right as you posted it. I didn't realize when I was asking that it was something container-specific, I thought it was something I could increase/decrease for each container somewhere in unRAID settings. Thanks for the post - I'm back up and running and I found the file at hand that was causing the issue, a database file I'm backing up another way every week anyhow and that's only a big log for HomeAssistant - excluded that from the backups and I think we should be good to go now, thank you very much! For the inotify watch limit, is that a setting somewhere in unRAID that I can change though if I keep getting that error? Thanks in advance!

Do you have a resource that you can point me to that shows how to do this? I'm not familiar with the process as I haven't needed to increase it for any other containers yet, so this is new to me - thanks! EDIT - Have 128GB of RAM in the server running unRAID so I should be able to give it a sizeable bump. EDIT2 - I see this container has a special place for that, whoops! Increasing it to 2048 for now to just make sure that solves all the issues for me first - I can reduce it later if I feel the need.