Webcam video0 resets to invalid permissions

English Multimedia
#1

Hi,

I started to experience stranhe issue in one of my 13.1 installations.
The user has webcam working fine for few days. After some time it stops working with “Permission denied”. Permissions look like:

crw------- 1 root root 81, 0 May 21 06:06 /dev/video0

Which is absolutely invalid
After “chmod 770” and “chgrp video” webcam works again. For few days. After few days permissions broken again

I have two other 13.1 installations and one 12.3 with webcams - they do not experience such permission reset.
Anybody seen this issue before?

#2

What do yoiu mean with “after a few days”. Did you reboot in the meantime or not? Did you remove/reconnect the device or not?

I ask this because in general using chmod and the like on device files do not survive a system down or a device removal. Those files are recreated using udev rules eitjer at boot, or at connection.

#3

No reboots during those “few days”, but suspend to ram. Webcams are not detached
When the issue happens - restart does not help.

#4

Issue looks like this old one: https://bugs.launchpad.net/ubuntu/+source/xawtv/+bug/488455/comments/7

#5

Hello.

I don’t know if a suspend to RAM would inflict on the ‘ownership’ of the device, but do not think changing the ownership, as exemplified above, of a block device is the way to proceed (temporarily, at best).

Are all devices you refer to USB related?

Olav

#6

All the devices are USB web cameras (uvcvideo).
And the one that regularly looses permissions - also a UVC webcam

#7

OK.

I resolve a similar issue with adding the device, /dev/xxx, to a user group (video) and by adding the user to this group; this is, however, a firewire device.
[http://wiki.linuxaudio.org/wiki/system_configuration#audio_group

Olav](http://wiki.linuxaudio.org/wiki/start)

#8

The above link does not work right, but click on ‘System Configuration’ if you’re interested.
It says ‘audio’, and is intended for audio-devices, but that does not matter; I use it for a cam-corder, and configure it under the ‘video’ group.
Earlier, this was the way I had to set it up to gain access to the device, no user privileges to it otherwise; I don’t know if it has to do with your issue, just an association.

#9

PS
By ‘earlier’ I mean this is no longer required on my system, as the device is now accessible without this step; however, your system might be a different matter.

#10

Would following lines from syslog make any sense?

2014-05-27T07:29:27.626627+03:00 linux systemd[1]: Starting udev Kernel Socket.
2014-05-27T07:29:27.626633+03:00 linux systemd[1]: Listening on udev Kernel Socket.
2014-05-27T07:29:27.626637+03:00 linux systemd[1]: Starting udev Control Socket.
2014-05-27T07:29:27.626641+03:00 linux systemd[1]: Listening on udev Control Socket.
2014-05-27T07:29:56.795573+03:00 linux systemd-udevd[265]: worker [279] /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/video4linux/video0 timeout; kill it
2014-05-27T07:29:56.796105+03:00 linux systemd-udevd[265]: seq 1639 '/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/video4linux/video0' killed
2014-05-27T07:29:56.796496+03:00 linux systemd-udevd[265]: worker [282] /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/input/input12 timeout; kill it
2014-05-27T07:29:56.796937+03:00 linux systemd-udevd[265]: seq 1640 '/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/input/input12' killed
2014-05-27T07:29:56.797311+03:00 linux systemd-udevd[265]: worker [290] /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.2 timeout; kill it
2014-05-27T07:29:56.797709+03:00 linux systemd-udevd[265]: seq 1255 '/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.2' killed
2014-05-27T07:30:15.721580+03:00 linux systemd-udevd[265]: worker [282] terminated by signal 9 (Killed)
2014-05-27T07:30:15.722095+03:00 linux systemd-udevd[265]: worker [279] terminated by signal 9 (Killed)
2014-05-27T07:30:15.722494+03:00 linux systemd-udevd[265]: worker [290] terminated by signal 9 (Killed)

What “timeout” means and does “kill” mean something bad?

#11

And for now I use this to restore correct permissions for video0:

# ls /dev/video0 -l
crw------- 1 root root 81, 0 May 27 07:29 /dev/video0
# modprobe -r uvcvideo
# modprobe uvcvideo
# ls /dev/video0 -l
crw-rw----+ 1 root video 81, 0 May 27 22:03 /dev/video0
#12

This probably needs a bug report to be submitted. It will be a udev issue, possibly related to one matching rule being applied before another.