Couldn't open settings.db

Channels DVR Server Troubleshooting
#1

Hello. I'd like to move channels from a mint linux direct install to a docker running on my Openmediavault server. The docker starts, but then restarts and restarts...and I am never able to access the control panel via the browser. The only log entry is "2020/04/30 19:33:16 couldn't open settings.db: no such device" over and over. The two files in my data directory are as such:

-rw-r--r-- 1 root root 3906 Apr 30 14:20 channels-dvr.log
-rw------- 1 root root 16384 Apr 30 13:28 settings.db

Any thoughts? Next stop is to dig around my Mint install to see perms and such...

btw, love channels :slight_smile:

#2

Since you migrated to a Docker container, did you make sure that the files are in the expected locations?

#3

Did you use the restore UI, or how did you migrate?

#4

Ah, good questions both. I just set up a new fresh docker container without pulling any content from my existing setup. So I didn't actually "migrate" the DVR database yet.

Since I never got the web interface to load, I couldn't use the restore UI anyway.

Also, my "working" setup is on a completely separate machine.

#5

Try following this guide: https://getchannels.com/docs/articles/migrate-dvr-to-new-computer/

It will be a little different for you, because you’ll be moving your data directory to a directory that you’ll need to mount into your docker container.

#6

If you're getting that settings.db error on a fresh docker install then something weird is happening. If you blow it away and setup a new container does it still show those errors?

#7

Hi Maddox, it's the install that's not working first. I'm between step 1 and 2 of " Set up your new Channels DVR Server" at the guide. (btw, I've successfully used that guide to move the DVR from windows to mint in the past :+1: )

Aman,
I had the container shut down, removed the directories related to the dvr (data and so on), then ran the container again. In the docker log (using Portainer), I see

Installing Channels DVR..
Downloading Channels DVR 2020.03.27.1730 (linux-x86_64) to //channels-dvr......
Channels DVR has been downloaded.
Running Channels DVR..
Running Channels DVR..
Running Channels DVR..

Check the web interface at https://192.168.1.253:8089/, no dice.

the files in data are recreated and in the channels-dvr.log I see:

2020/04/30 22:20:57 couldn't open settings.db: no such device
2020/04/30 22:21:00 couldn't open settings.db: no such device
2020/04/30 22:21:01 couldn't open settings.db: no such device
2020/04/30 22:21:03 couldn't open settings.db: no such device
2020/04/30 22:21:05 couldn't open settings.db: no such device
2020/04/30 22:21:08 couldn't open settings.db: no such device

Btw, OMV is Debian based.

Also, the setup on the mint machine where the working DVR is today looks identical regarding the perms in the data folder...

#8

This is a pretty strange error. Sounds like whatever mount you're providing for the data directory is not working correctly. Could be a problem with the kernel version or version of docker.

#9

:smiley: maybe I'll just install it directly instead of in a docker.

I tried changing owners to match a urbackup docker, which uses my login instead of root, but that didn't help.

Here's something interesting I noticed... channels log thinks the time is 5 hours ahead of the system time...

#10

The plot thickens... I removed the config directory again (which forces the docker to reinstall channels). This time, I mapped the config directory to a drv-by-label instead of a union generated by mergerfs. Now the behavior is different. The web interface never connects and the log file now contains

./run.sh: exec: line 9: ../latest/channels-dvr: Permission denied

over and over, each time the container restarts. :thinking:

#11

I think I got it... Noexec. The channels config folder is on a data share, which was mounted noexec by the openmediavault setup. Thread about it here. Now I'll have to make sure the fix persists through a reboot and then I'll migrate from the mint machine to this server. :grin: