Can't log in after update

[djuniah]

Was just logged into my unifi-video container and saw an update was available (i think i went from 3.10.8 to 3.10.10, but i can't see it right now since i can't log in), and after updating the container, it's saying that my username/password are no longer valid. These credentials are saved in both my web browser and the mobile app, and both are reporting that they are invalid. I had logged in with them just a few minutes before running the upgrade, so i know they were valid prior. There are no errors in the logs either.

Edit: Downgrading to 3.10.8 got the login working again. I saw another user reporting the issue on page 4 of the official release notes: https://community.ui.com/releases/UniFi-Video-3-10-10/e50d7b17-9743-47bb-9815-16652daf83dd?page=4

[dcplaya]

Have the same issue. Downgrade fixes it for now

[fryfrog]

In your downgraded container, docker exec in and ps aux and look at your full mongodb command, show us. Go back to latest and do the same thing. It is probably starting up the wrong type of DB. :/

[fryfrog]

You could probably also make a backup in 3.10.8 and do a restore into a clean 3.10.10.

[chelming]

I'm not seeing anything weird in the mongod log, but in the chrome console I'm seeing a 403 for the login api. api/2.0/login:1 Failed to load resource: the server responded with a status of 403 ()

[chelming]

Interestingly, I get the same error with a clean 3.10.8.

[chelming]

idk what I did but I was able to get a fresh 3.10.10 set up and restored from my 3.10.8 backup 👍

[Rene-Olskjaer]

Same issue, downgraded to 3.10.8

3.10.8 : bin/mongod --config /usr/lib/unifi-video/conf/mongodv3.0+.conf 3.10.10: bin/mongod --config /usr/lib/unifi-video/conf/mongod-wt.conf

[lmtr]

I hit the same issue overnight. I also had to downgrade to 3.10.8 to get it back up and running again. I have learned my lesson and have now exported my settings... just in case this go rogue again.

[OddSquirrel]

Tried to update to 3.10.10 from 3.10.6, no go. Ok, went back. Nada. Tried about every release from 3.9.12 to beta and for whatever reason I can't get my container back to a functioning state.

Mind you, since the backup I downloaded was only a folder and I can't just choose a folder when restoring I tried a completely new, clean setup. Even deleted the video content, so there was nothing left on my NAS (Synology 918+).

I can register a user, but as soon as I try to log in all I get is a spinning wheel on the login button, that's it. Would anybody be able to help me out? I'd really appreciate it. :)

[dcplaya]

Only way I know how to properly update is by restoring a backup and then re-analyzing the video files.

I think the issue is how this new version interacts with the database vs the old way. I saw somewhere UBNT changed how it interacts recently to be more "correct" but it ended up screwing people using dockers that implemented it themselves. But I can't find that post again so take that with a grain of salt.

[ssbarnea]

I am wondering if that is UBNT incompetence or is an orchestrated efforts to make people move to their hosted solution. They somehow managed to make any upgrade process even worse with every new release. Instead of improving over time it seems to make it harder to keep it running.

[iscofield]

Just got bit by this as well. Downgrading to 5.10.8 worked for me.

[paulcarlucci]

The mongo database in my container is 3.4. Looks like it has to be upgraded to first 3.6 in order for it to accept the idea of being upgraded to 4.0. I have the usual /var/lib/unifi-video as a volume mapped to the local host.

Take a backup: cd /var/lib/unifi-video and cp -av db db.34

I have a db-wt that seems to be unused, probably from a previous failed attempt. mv db-wt db-wt.bak

Start the container. In this case that hash is the "latest" image that was failing, 3.10.2 I believe. docker run -it -v /var/lib/unifi-video:/var/lib/unifi-video 6b5e60e23d34 /bin/bash

Ephemerally install mongodb inside this running container apt update apt install mongodb

Confirm you have 3.6 ready to roll mongodb --version

Create /logs cd /; mkdir /logs

On mine I had to rm mongod.lock from the db directory.

Fire up mongodb 3.6 using the 3.6 config included in the image. On mine I had to include --smallfiles as well. mongod --config /usr/lib/unifi-video/conf/mongodv3.6+.conf --smallfiles

Control-z, bg, then mongo 127.0.0.1:7441

Once you're in run this against mongo: db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

Should show you have the 3.4 feature set. Bump it to 3.6 db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )

Shut down mongo and exit db.adminCommand( { shutdown: 1 }) exit

cd to /var/lib/unifi-video and rename "db" to "db-wt"

exit the shell prompt to bail out of the container and shut it down.

You now have a database that's been upgraded to 3.6. From here, you can pray hard, start the container on :latest, and see what happens. It's a lot of typing, but it worked for me. The big thing is make sure you have your backups of the db directories just in case you have to start over or simply revert to the last know working container. Good luck!

[fryfrog]

@paulcarlucci, those are great instructions!

The :3.10.8.3.6 tag has mongodb 3.6 in it and the :3.10.8.4.0 tag has mongodb 4.0 in it, if that makes things any easier. And actually, there is a startup script that should be checking the version of mongodb you're using and the featureCompatibility and increasing it if that is appropriate.

But the old mongodb format to wiredtiger change would be very similar to your instructions too! But instead of changing feature compatibility, you'd dump the old db while it was running the old db and then restart it to run wiredtiger and then load that.

What :version of the container are you running that has 3.6? Probably pinned to one of the older ones?

[paulcarlucci]

I was only ever tracking :latest. MongoDB 3.6 isn't actually bundled into the image, just the config file. If you look at the instructions you'll see I installed 3.6 by hand into container and then executed the call to upgrade the database structures from 3.4 to 3.6. From there it was then able to come up on an unmodified :latest docker image.

A decent fix for this could be to either have one build of the image with 3.6 as an intermediate step, or to simply construct a 3.6 upgrade container with the only job to be to start up the database, do the upgrade step, and then exit out so that an unmodified :latest image can be started against the database. Admittedly, the instructions are a bit cumbersome, but that's what needs to happen to get from 3.4 to 4.0.

[fryfrog]

Right, that is what I mean. There is a Docker image w/ 3.6 and one w/ 4.0. (and the old ones have 3.4 obviously). And the run.sh script does update the feature compatibility flag. But the problem is they must have changed how they decide to run the db. It flipped around from using wired tiger to not using wired tiger to using it again. And the decision on that, I couldn't really ever figure out. I think it might have been based on mongodb version? Or who knows. :/

[nuismer]

Can someone explain how to do the downgrade? I am using this docker on unraid and I cannot login in after the upgrade.

[fryfrog]

You can specify a version w/ a tag, like :3.10.9.