[ Update: 1 July 2020 ]
I can’t say my blog sees a lot of action or sets the world on fire. That’s the way I like it. But, and I’m not saying it keeps me awake at nights, this blog post regularly sees a lot of hits. It’s about 4 years old now, and in raspberry pi times, that’s a long time. I can’t recall having had this problem for ages, and on all my new-builds it seems to have just, gone away. I still have issues with the rpi deciding on its device file, and I still don’t understand them, but I’ll get around to that one day …
Post from Feb 2017 …
It pretty much happens that every time I setup motion on a new build that it doesn’t work right away. There’s usually a few things I miss. Usually it’s an error reading from the camera, the logs reporting something like:
Feb 17 10:51:21 pi2 motion:  [NTC] [ALL] motion_init: Thread 1 started , motion detection Enabled Feb 17 10:51:21 pi2 motion:  [NTC] [VID] vid_v4lx_start: Using videodevice /dev/video0 and input -1 Feb 17 10:51:21 pi2 motion:  [ALR] [VID] vid_v4lx_start: Failed to open video device /dev/video0:
which invariably means the camera is broken or I’ve misconfigured my motion setup.
This one was puzzling me a little though. It’s on a raspberry pi, imaginatively titled pi2, and it was failing to read from the camera. The reason I was puzzled was that the hardware combination had worked before. What had gone wrong was the micro-SD card, and I’d done a new raspbian build, copying over the relevant motion configuration files from the old card.
Clearly the difference had to be something to do with the OS. So what was different? I’d taken the opportunity of the SD failure to download and install the latest version of raspbian and everything looked good to go.
Running motion as root worked fine, both against the vanilla configuration file, and the customised config file I wanted to use. So let’s have a look at the video file:
root@pi2:~# ls -l /dev/video0 crw-rw----+ 1 root video 81, 0 Feb 17 11:17 /dev/video0
Looks about right. Ah, the video group. I need to be in the video group. That might be it:
root@pi2:~# usermod -G video dougie
Restart motion and try again. Nope. Let’s have a closer look at that file.
On pi2 (with a new version of raspbian):
crw-rw----+ 1 root video 81, 0 Feb 17 11:17 /dev/video0
and on pi1 (another rpi, running motion fine, with a slightly older version of raspbian):
dougie@pi1:~ $ ls -l /dev/video0 crw-rw---- 1 root video 81, 0 Jan 8 22:54 /dev/video0
Very similar, but not identical. The newer version of the device file has and extra + at the end of the permissions bit, which means the file has extra security permissions set. I’ve not had cause to use Access Control Lists (ACLs) before, and it was a temptation just to chmod 777 on the file as a quick and dirty, and lazy, fix, but I thought it’d be better to take a closer look. Using the getfacl command:
root@pi2:~# getfacl /dev/video0 getfacl: Removing leading '/' from absolute path names # file: dev/video0 # owner: root # group: video user::rw- user:pi:rw- group::rw- mask::rw- other::---
I could see that I (me: dougie) did not appear on the list, although the default rpi user pi does. I rarely use the pi account. One of the first things I do is change its password, create my own user, and use that instead. So it looks like the default install for raspbian allows user pi to access /dev/video0. It also looks like I can’t access the file, despite being a member of the group video.
I found a good command summary on the (now a dead link) centos documentation website, and using that gave myself access:
root@pi2:~# setfacl -m u:dougie:rw /dev/video0
That did the trick.