Camera stopped recording after clean install of 3.10.10 on docker synology

[RonaldBlom]

Camera is not able to record anymore.

These log entries in error.log: ERROR [uv.recording.svc] [RecordingService] Unable to do emergency shutoff check, shutting off recordings: Mount point for /var/cache/unifi-video/hls not found in RecordingService-EmergencyShutOffCheck

This is what i am using: docker run -d \ --cap-add DAC_READ_SEARCH \ --privileged \ --network="host" \ --name Unifi-Video-Controller_31010 \ -v /volume1/docker/unifi-video:/var/lib/unifi-video \ -v /volume1/docker/unifi-video/videos:/usr/lib/unifi-video/videos \ --tmpfs /var/cache/unifi-video \ -e TZ=Europe/Amsterdam \ -e PUID=99 \ -e PGID=100 \ -e CREATE_TMPFS=no \ -e DEBUG=1 \ pducharme/unifi-video-controller

Everything is running fine, but only recording of camera not working anymore.

Someone same issue? please assist on this?

Thanks, Ronald

[RonaldBlom]

Solved the isssue myself. first tried --tmpfs /var/cache/unifi-video/hls \

then I got failures on the /usr/lib/unifi-videos/videos, which I copied from older install and was working there. But after changing it to below it was working. This was also givin by Pducharme as config. So just did not read good enough. -v /volume1/docker/unifi-video/videos:/var/lib/unifi-video/videos \

But the --tmpfs was not working for me. Is that only for me?

[stshontikidis]

Also just upgraded the image and had this issue, don't have my logs handy or access to the container (will try and post later). Turns out that the unifi-video user does not have write access to /var/cache/unifi-video I went into the container and updated the directory so the user had write access. This is not the actual fix because the fix will not persist if the container is destroyed. Was going to dig further when I got some time.

[RamboRogers]

I'm using this image, and I'm getting this error.... I noticed the /var/cache/unifi-video was owned by root and chown it to unify-video:unifi-video, but I'm still getting the same error.

1585589009.614 2020-03-30 13:23:29.614/EDT: ERROR [uv.recording.svc] [RecordingService] Unable to do emergency shutoff check, shutting off recordings: Mount point for /var/cache/unifi-video/hls not found in RecordingService-EmergencyShutOffCheck

[stshontikidis]

is that a typo or is the user actually unify-video is that possibly your issue? Fairly certain once the unifi-video directory had proper permissions it was a go... Is the hls directory in there? maybe you need to create that and give the proper ownership as well, possibly unifi is not smart enough to re-create that dir if it is missing.

[l3anks]

Having similar issues on fedora 31 using podman. Can’t get recordings to work at all using latest or testing releases

Logs show

1586092693.233 2020-04-05 08:18:13.233/CDT: WARN [uv.recording.info] [RecordingService] Emergency shutoff enabled, not processing motion event in AnalyticsEvtBus-2 1586092686.515 2020-04-05 08:18:06.515/CDT: WARN [uv.recording.info] [RecordingService] Emergency shutoff enabled, not processing motion event in AnalyticsEvtBus-2

1586092708.407 2020-04-05 08:18:28.407/CDT: ERROR [uv.utils] Unable to get disk usage:/var/lib/unifi-video/videos : No such file or directory in StatsUpdaterTask 1586092648.407 2020-04-05 08:17:28.407/CDT: ERROR [uv.utils] Unable to get disk usage:/var/lib/unifi-video/videos : No such file or directory in StatsUpdaterTask

Perms and owner of different paths look correct inside the container.

I’ve tried tmpfs changes as well and no luck.

[rojaxthegreat]

Just did a fresh install of this and it didn't create /var/cache/unifi-video/hls automatically. After I made the folder videos started appearing again. However restarting the container wipes it and i have to create it again

[mattp-gh]

I'm getting the same issues / error with podman on Centos8. Have verified the permissions to my videos mount are correct and I can touch files from within the container as the unifi-video user to both the tmpfs location and the videos path. Seems something in tomcat having a real dislike to writing to disk. Also noting that the disk space indicator in the UI showing 0 disk space used and no bar no matter the disk space. I have tried both fresh install of 3.10.11 and my previous working 3.10.10 docker container.

Interestingly, one of my other containers running unifi is working fine.

My podman run command is below (note I've taken tmpfs out as it wasn't making any difference to being able to record or not). My errors are the same as l3anks.

UNIFIVIDEOPID=podman run -dt --name unifi-video -p 6666:6666 -p 7004:7004/udp -p 7080:7080 -p 7442:7442 -p 7443:7443 -p 7444:7444 -p 7445:7445 -p 7446:7446 -p 7447:7447 --cap-add SYS_ADMIN --cap-add DAC_READ_SEARCH -v /srv/unifi-video:/var/lib/unifi-video -v /dvr/unifi-video:/videos -e "TZ=Australia/Melbourne" -e PUID=$UNIFIUID -e PGID=$UNIFIGID -e DEBUG=1 docker.io/pducharme/unifi-video-controller

[ARandomOWL]

I had something similar, since changing from Unifi creating the tmpfs internally, to Docker creating the tmpfs (using --tmpfs, as is now recommended by pducharme).

It seems the directory /var/cache/unifi-video already existed and tmpfs wasn't getting mounted their. In addition, the dir was read-only for group/other, and the new recommendation is to run Unifi as non-root using -e "PUID=...". The fix for me was to destroy and recreate the container (docker-compose up -d did not suffice). Now tmpfs is correctly mounted at /var/cache/unifi-video with the Docker default 1777 perms, and recording is successful.

[tculpepp]

Just want to add to this. I discovered this same issue, logs full of the same error. I Was already running the container as non-root and the "hls" directory was not created. I destroyed and re-created the container and all seems well again. Strange.

[RamboRogers]

I remade the container using the updated flags, working great. Thanks to the author for maintaining this for us all :-)

[tculpepp]

So after destroying and remaking the container all was well for 2 days, then the hls directory was removed and all recordings stopped. Destroyed and rebuilt with the same run command and all is well again. My run command is below:

docker run \ -d \ --name unifi-video \ --restart unless-stopped \ --cap-add DAC_READ_SEARCH \ --net=ha-net \ --ip=192.168.xxx.xxx\ -v <config directory>:/var/lib/unifi-video \ -v <videos directory>:/var/lib/unifi-video/videos \ --tmpfs /var/cache/unifi-video \ -e TZ=America/Chicago \ -e PUID=<unifi-video UID> \ -e PGID=<unifi-video GID> \ -e CREATE_TMPFS=no \ -e DEBUG=1 \ pducharme/unifi-video-controller

[thoschworks]

Similar problems here.

I plan to setup a cron-job on the docker-host, which stops and destroys the existing container, and start a new container once a day.

[fryfrog]

I just saw this thread, sorry for the delay...

I popped into my container and the folder is owned by unifi-video:unifi-video, looks like the following:

root@212bfe86e874:/var/cache/unifi-video# ls -alh
total 512
drwxrwxrwt 4 root        root         80 May 15 14:54 .
drwxr-xr-x 6 root        root          6 May 15 14:54 ..
drwx------ 2 unifi-video unifi-video  40 May 15 14:54 exports
drwxrwxr-x 2 unifi-video unifi-video 580 May 19 12:53 hls

And my docker run looks like this:

            docker run --rm \
                              --name unifi-video \
                              --cap-add DAC_READ_SEARCH \
                              --cap-add NET_BIND_SERVICE \
                              --cap-add SYS_PTRACE \
                              --cap-add SETUID \
                              --cap-add SETGID \
                              -p 10001:10001 \
                              -p 1935:1935 \
                              -p 6666:6666 \
                              -p 7080:7080 \
                              -p 7442:7442 \
                              -p 7443:7443 \
                              -p 7444:7444 \
                              -p 7445:7445 \
                              -p 7446:7446 \
                              -p 7447:7447 \
                              -v /data/unifi-video/data:/var/lib/unifi-video \
                              -v /data/unifi-video/videos:/var/lib/unifi-video/videos \
                              --tmpfs /var/cache/unifi-video \
                              -e JVM_MX=2048M \
                              -e UMASK=002 \
                              -e PUID=957 \
                              -e PGID=957 \
                              -e CREATE_TMPFS=no \
                              -e TZ=America/Los_Angeles \
                              -e DEBUG=1 \
                              pducharme/unifi-video-controller:testing

[nicxvan]

It seems to be triggered if I change any settings. I was trying to set up zones better and that killed the recordings.

[RonaldBlom]

After issues with camera (which was defect cable) I reinstalled unifi-video again from scratch. Whit new and clean dir. And I had the same issue again. All I did last time it was not working. But now I found the final solution for me. Maybe not the best and secure option, but it works for me. --tmpfs /var/cache/unifi-video:rw,noexec,nosuid,size=65536k,mode=777,uid=99 I will try to narrow this down to 770 or something.

[thoschworks]

It seems to be triggered if I change any settings. I was trying to set up zones better and that killed the recordings.

Not here.

• Recording stopped today after 11 days runtime without any changes in the setup.
• After starting a new container I changed the motion detection areas. System is still recording.

[thoschworks]

Today the recording stopped suddenly again. No reboot. No change of the config within the container. It. Just. Stopped.

It took me a moment until I realized that I had update docker-ce which triggered a stop and restart of dockerd and of the containers.

As mentioned in the Issue #118 the problem is triggered by the (re)start of the container. (This is why it doesn't occur on the appliances sold by Ubiquity and will not be fixed by them.)

Let's have a look:

Shutdown, remove and (re)run the container via docker-compose:

thosch@tNUC:~/Projekte/Docker_unifi-video$ sudo docker-compose down
Stopping unifi-video ... done
Removing unifi-video ... done
thosch@tNUC:~/Projekte/Docker_unifi-video$ sudo docker-compose up -d
Creating unifi-video ... done

Let is everything o.k. in /var/cache/unifi-video?

thosch@tNUC:~/Projekte/Docker_unifi-video$ docker exec -it unifi-video ls -axl /var/cache/unifi-video/
total 0
drwxrwxrwt 2 root root 40 Jul  1 19:03 .
drwxr-xr-x 1 root root 58 Jul  1 19:03 ..

Ooops!

Let's try it again...

thosch@tNUC:~/Projekte/Docker_unifi-video$ docker exec -it unifi-video ls -axl /var/cache/unifi-video/
total 0
drwxrwxrwt 4 root        root        80 Jul  1 19:03 .
drwxr-xr-x 1 root        root        58 Jul  1 19:03 ..
drwx------ 2 unifi-video unifi-video 40 Jul  1 19:03 exports
drwxrwxr-x 2 unifi-video unifi-video 40 Jul  1 19:03 hls

Everything is o.k. now. But why? :thinking:

Let have some fun:

thosch@tNUC:~/Projekte/Docker_unifi-video$ docker stop unifi-video
unifi-video
thosch@tNUC:~/Projekte/Docker_unifi-video$ docker start unifi-video
unifi-video

Let's wait 60 seconds...

thosch@tNUC:~/Projekte/Docker_unifi-video$ docker exec -it unifi-video ls -axl /var/cache/unifi-video/
total 0
drwxr-xr-x 2 root root 40 Jul  1 19:05 .
drwxr-xr-x 1 root root 58 Jul  1 19:03 ..

Broken, as expected.

I contemplated about the fact, that the folders were missing just after docker-compose up and reappeared a moment later. I never saw this before, because I used docker exec -it unifi-video bash before and changed step by step to the folder and entered ls -axl. This took a while. With docker exec -it unifi-video ls -axl /var/cache/unifi-video/ I was much faster. :bulb:

O.k., what happens:

1. On the start UniFi-Video-Software initializes the system. In one step it creates the folders under /var/cache/ (outside of a container, it must create /var/cache/unifi-video, but in the fresh container it already exists, because we mount the tmpfs mount at this position).
2. Cause of --tmpfs /var/cache/unifi-video the folder is only persistent in the memory.
3. The container is stopped (by command, by reboot, by power outage...).
4. The container is persisted on the file system of the host. :+1:
5. The mounted volumes - except the tmpfs mount - are persisted on the file system of the host. :+1:
6. The tmpfs mount with /var/cache/unifi-video was only persisted in the memory and is GONE now! :-1:
7. The container is restarted.
8. The data of the container and the non-tmpfs mounts are still persisted on the file system of the host and are available.
9. The data /var/cache/unifi-video is lost and a new and empty /var/cache/unifi-video is created in the memory.
10. The UniFi-Video-Software is not restarted. It ist just "reanimated" and is running with the last state before the container was stopped. There is no initialization phase. /var/cache/unifi-video` stays empty. The software fails to write data info the missing subfolders.

The problem could be fixed by not using --tmpfs. The cache would be written into the container and will "survive" a restart. But this could result in a slower system and a wearing of the disks.

[fryfrog]

Ah, that explains why I don't see this issue! I use systemd .service files and I run all my containers with docker run --rm which removes the container when it stops, so every restart of the service or even the server nukes the container and re-creates it!

I think even if you don't use --tmpfs, unifi-video still does use tmpfs itself. But it'll do that itself?

There is a loop that watches for the shutdown signal, I wonder if it would be crazy to add a short bit that creates the exports and hls folders?

[fryfrog]

I just pushed 0a1789ad6d6b3bde4c31e642b3582743582cae56 to master, :testing should build soon. Want to give it a try?

[thoschworks]

Ah, that explains why I don't see this issue! I use systemd .service files and [...]

I knew that I would read these words from you... :wink:

I run all my containers with docker run --rm which removes the container when it stops, so every restart of the service or even the server nukes the container and re-creates it!

I wasn't sure if this would fix the problem.

Using docker-compose up -d --force-recreate does not fix the problem. :disappointed:

I think even if you don't use --tmpfs, unifi-video still does use tmpfs itself. But it'll do that itself?

I think no, because this is a mounting mechanism of docker. A software in a container could not manipulate the mounts.

There is a loop that watches for the shutdown signal, I wonder if it would be crazy to add a short bit that creates the exports and hls folders?

This was a hack which came into my mind while I was chewing my :pizza:. (To be honest, I did not know that there is such a loop. I would have added a shell script which would have done the same...)

it doesn't work. The subfolders reappear, but...

thosch@tNUC:~/Projekte/Docker_unifi-video$ docker exec -it unifi-video ls -axl /var/cache/unifi-video/
total 0
drwxr-xr-x 4 root root 80 Jul  1 21:21 .
drwxr-xr-x 1 root root 58 Jul  1 21:12 ..
drwxrwxr-x 2 root root 40 Jul  1 21:21 exports
drwxrwxr-x 2 root root 40 Jul  1 21:21 hls

...with the wrong owner or the wrong mode. If I change the mode o+w it works.

I would prefer, if the script uses the correct owner, but I cannot assess if this is too complex or error-prone

[fryfrog]

Ah, duh. I can set it to the correct owner and/or permissions. I'll fix in a bit.

[fryfrog]

Try when it updates again, from b86aa78d025cd151cd0ebca26c1a8637dbd5064e.

[thoschworks]

Good morning!

Sorry, I live in a different time zone, so I had to sleep. 😉

Looks good.

1. Stop, (re)start container
   (docker stop unifi-video, docker start unifi-video)
   Passed :+1:
2. Stop, start dockerd (sudo systemctl stop docker, sudo systemctl start docker)
   Passed :+1:
3. Reboot
   Passed 👍
4. Power outage I won't test this... 😒

It's fixed! Great work!

Where is the fixed...? No, isn't my issue. 🤷

[thoschworks]

@RonaldBlom Does it work for you?

[dukekautington3rd]

I was chasing down this problem on #188 Thought perhaps someone else might have made my mistake.

Turns out the problem was with my tmpfs line.

    tmpfs:
      - /var/cache/unifi-video/hls

Not sure why I had it this way but... This caused the hls directory to be owned by root:root and ownership mask of 777 for a fresh start with docker-compose up -d. The recordings would work in this state. However if there was an abrupt end to the container and it's restart was incited by restart: always the hls directory would still be owned by root:root but would have the mask of 755 which resulted in error messages such as Mount point for /var/cache/unifi-video/hls not found in RecordingService-EmergencyShutOffCheck and recordings not occurring. I don't know why a destroy and rebuild would result in different file permission mask vs. an abrupt restart of the container.

after changing tmpfs to

 tmpfs:
      - /var/cache/unifi-video

hard and soft restarts of the container or host result in an hls directory owned by unifi-video:users or 99:100 and recording works perfectly. Running docker image 898d67699719

Many thanks to the team here for maintaining

[RonaldBlom]

This was in the end what did it for me: docker run -d \ --cap-add DAC_READ_SEARCH \ --privileged \ --network="host" \ --name Unifi-Video-Controller \ -v /volume1/docker/unifi-video:/var/lib/unifi-video \ -v /volume1/docker/unifi-video/videos:/var/lib/unifi-video/videos \ --tmpfs /var/cache/unifi-video:rw,noexec,nosuid,size=65536k,mode=777,uid=99 \ -e TZ=Europe/Amsterdam \ -e PUID=99 \ -e PGID=100 \ -e CREATE_TMPFS=yes \ -e DEBUG=1 \ pducharme/unifi-video-controller

[RonaldBlom]

sorry for late response