fryfrog

@Mellowevo8, make an issue on github and we'll try to help you. Please include as much detail as you can.

The fix for 3.9.2 is in and a pull request is up, it'd be reasonable to wait and just go to 3.9.2 and they'll be fine. https://github.com/pducharme/UniFi-Video-Controller/pull/69

I *just* ran through this flow on my own test container and it worked fine. Since you're not far along, maybe blow away your config and try again? Can you post your `docker run` command and maybe tell us about what you're running it on?

We had no idea how many people were having issues and how many weren't. In the issue we're taking this problem on, I suggested that @Pducharme get tags working and then flip back to 3.9.2. That way everyone can upgrade and only those w/ issues can easily stay at 3.9.0 while we figure out wtf is going on. Can you tell us about your setup that is working in https://github.com/pducharme/UniFi-Video-Controller/issues/56 ?

If 3.9.2 was working for you, you could just re-upgrade to it. There is an issue on the github that has instruction for doing that. If it wasn't, you'll need to manually downgrade your cameras. I had to do that after manually *upgrading* them

@Pducharme has pushed a downgrade, so you can just pull the latest and you'll be back on 3.9.0.

Anyone running unifi-video 3.9.2 docker? I'm having a bunch of problems w/ it and I haven't had much luck narrowing things down. My cameras get stuck on "managing", logs say the server is sending a re-manage command w/ both the docker ip (which won't work) and the right ip (which will). But they never come online. I even updated their firmware manually, hoping it'd help. That just made downgrading to 3.9.0 not work. And it *also* isn't showing up in the "cloud" at https://video.ubnt.com anymore. Will troubleshoot more tomorrow I think it must be related to whatever runs on port 7440, my 3.9.2 logs are full of errors related to that: https://ptpb.pw/PtPT Edit: Downgraded camera firmware and went back to 3.9.0 and it is working again.

I'm afraid I don't use Unraid, so I can't really help you on that end. But this is Docker, so anything you want to do... you have to feed into it. The run command will have a series of arguments that tell you about where the various external files (config, videos, logs) are stored. It is a map that says "here in real life" and "here inside the docker". You can shuffle that around as you see fit, as long as you maintain the *contents* of those directories and point them properly. For example, if right now you have `/data/videos` as where the videos live and the mapping from real -> docker `/data/videos` -> `/usr/lib/unifi-video/data/videos`, on the outside you can move `/data/videos` to `/whatever/the/hell/you/want` as long as you copy the contents there (so unifi-video doesn't suddenly miss its file) and fix the map. So in the above post, it'd look like `-v /whatever/the/hell/you/want:/usr/lib/unifi-video/data/videos`. See? This would be I think the "docker" way of fixing this and honestly, the simplest. You *could* actually pass in a new path like `-v /whatever/the/hell/you/want:/this/is/inside` and *inside* the unifi-video app's settings, change the recordings path to `/this/is/inside`. I don't think this is as elegant and clean, but it would work. The downside is that if you wipe your unifi-video, you'll have to remember you did this when you re-set it up.

You can, it is just very well hidden. If you've fed a *new* path into your docker container to use, Settings -> System Configuration -> Recording Path. Mine is currently set to `/usr/lib/unifi-video/data/videos` which I believe is the default. -v /data/unifi-video/data:/var/lib/unifi-video \ -v /data/unifi-video/videos:/usr/lib/unifi-video/data/videos \ -v /data/unifi-video/logs:/var/log/unifi-video \ You can *also* just feed a different path into the docker container. You'd want to *stop* it, move the data from the *old* location to the *new* location, change the paths in your run and then start it back up.

I actually included this in an update of the README.md in the pull request to update to 3.8.0 and suggested editing the first post. Thanks for replying and including the information so others will see it too. I had the same issue during testing. https://github.com/pducharme/UniFi-Video-Controller

https://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-5-4-15-Stable-has-been-released/ba-p/1910910 5.4.14 and now 5.4.15 are the current stable builds of UniFi.

I hate to say it, but this is exactly the reason I moved from my native install of unifi-video on Arch Linux (I even maintain the AUR package for it!) to this docker in Ubuntu. My cameras were constantly disconnecting and re-connecting. They kind of worked, but hadn't recorded anything for weeks. Reset them, tossed them against this docker image and... bam, they're fine. I was never able to figure out what the problem even was. If your VM is working, maybe that is a sign to stick with it.

You can't, but it shouldn't matter. That is what the port forwards are for. I didn't do anything special and my cameras were perfectly happy even w/ its IP not in their network. If you want to experiment, you could remove all the port forwards and use the `--network host` option instead. But there is no docker option I know of that'll let it have its own IP on the LAN, like you'd expect from a vm.

I setup an Ubuntu Server VM and got the same error as you with the options from the README, https://ptpb.pw/Brmb/shell Edit: And it works fine if I use --privileged Edit: Whoah, even with --cap-add ALL it has the same error. Might really need to run it as --privileged Edit: Found it, you need --security-opt apparmor:unconfined I've made a pull request to add this to the readme, I'm not going to add it to the defaults until it is obvious that *most* users will need it. I also improved the "failure" of starting so that it would actually exit when it failed instead of looking like it was still working fine.

Subscribing to thread the only way I can figure out how to do...

Yeah, most dockers I have seen point at /data and /config. This one is a little weird in that it mounts the data and config dirs right where the application needs them.

It is failing to fix the tmpfs mount it wants to use, can you try with --privileged instead of the two --cap-add options?

Glad to help, I was happy to find one that already exists and worked out of the box!

I got tired of how weird my native install of unifi-video on my Arch linux server was, so I went out and found pducharmes's docker image for it. And I spent some time working on it to make it even better for us non-unraid users and I think better even for unraid users. The only reason you're not seeing this error anymore is that I switched it to using the native unifi-video script to start and stop which... hides all the output. I just did a pull request for an easy to use DEBUG option if you'd like to see more of what the daemon is doing. After it is merged, you can add `-e DEBUG=1` to your run command and you'll see a lot more startup details, your "missing" error and any other spew that comes along.

Where there any recent changes / fixes for flood? I set it to both, but it doesn't start. Exec'ing in and running flood.sh in ~nobody works. Edit: It was permissions on the /config/flood/db/ directory being root:root instead of the uid/gid set in the run command.

I recently setup your delugevpn docker and it works great, today I discovered your rtorrentvpn docker image and I'm having some trouble getting it to work. It seems to get stuck somewhere around line 75 in rtorrent.sh. It stops after... 2017-03-03 12:27:30,662 DEBG 'rtorrent-script' stdout output: [info] rTorrent not running [info] rTorrent listening interface IP 0.0.0.0 and VPN provider IP 10.4.60.154 different, marking for reconfigure Fri Mar 3 12:27:35 2017 /usr/bin/ip route add 184.75.221.34/32 via 172.17.0.1 Fri Mar 3 12:27:35 2017 /usr/bin/ip route add 0.0.0.0/1 via 10.4.0.1 Fri Mar 3 12:27:35 2017 /usr/bin/ip route add 128.0.0.0/1 via 10.4.0.1 Fri Mar 3 12:27:35 2017 Initialization Sequence Completed My run command is: sudo docker run -d \ --cap-add=NET_ADMIN \ -p 9080:9080 \ -p 9443:9443 \ --name=rtorrent-vpn \ -v /data/torrents:/data \ -v /data/torrents/.rtorrent:/config \ -v /etc/localtime:/etc/localtime:ro \ -e VPN_ENABLED=yes \ -e VPN_REMOTE=america.vpn.airdns.org \ -e VPN_PORT=443 \ -e VPN_PROTOCOL=udp \ -e VPN_DEVICE_TYPE=tun \ -e VPN_PROV=airvpn \ -e ENABLE_PRIVOXY=no \ -e ENABLE_FLOOD=no \ -e LAN_NETWORK=10.0.1.0/24 \ -e NAME_SERVERS=8.8.8.8,8.8.4.4 \ -e DEBUG=true \ -e PHP_TZ=UTC \ -e PUID=1007 \ -e PGID=100 \ binhex/arch-rtorrentvpn Permissions of /config folder on parent host: 0 ✓ fryfrog@apollo /data/torrents/.rtorrent $ ls -alh total 155K drwxrwxr-x 4 rtorrent users 6 Mar 3 12:43 . drwxrwxr-x 34 rtorrent users 55 Mar 3 10:28 .. drwxrwxr-x 2 rtorrent users 3 Mar 3 12:43 openvpn drwxrwxrwx 3 rtorrent users 3 Mar 3 12:43 rtorrent -rw-r--r-- 1 root root 162 Mar 3 12:43 perms.txt -rwxrwxr-x 1 rtorrent users 29K Mar 3 12:43 supervisord.log And my full, redacted log file is: https://ptpb.pw/tNug Edit: After docker exec /bin/bash into the container, I think it is actually waiting on getting an external IP. Edit: Yup, logged in and ran... [root@7d84a5e7d901 root]# bash -x getvpnextip.sh + source /root/checkvpnconn.sh google.com 443 ++ check_site_hostname=google.com ++ check_site_port=443 ++ counter=0 ++ echo '[debug] Checking Internet connectivity...' [debug] Checking Internet connectivity... ++ nc -z -w 1 google.com 443 ++ echo '[debug] Successfully connected to hostname '\''google.com'\'' port '\''443'\''' [debug] Successfully connected to hostname 'google.com' port '443' + pri_external_ip_ns=ns1.google.com + sec_external_ip_ns=resolver1.opendns.com ++ dig TXT +short o-o.myaddr.l.google.com @ns1.google.com ++ tr -d '"' + external_ip=199.19.94.16 + exit_code=0 + [[ 0 != 0 ]] + echo 199.19.94.16 And it seems to be firing right up. But why isn't that getting done automatically?