VLC installed from snap can't access v4l devices

[minneyar]

I'm using Ubuntu 16.04 and have a USB camera at /dev/video0 that I'm trying to access. /dev/video0 is read/writable by the "video" group, and I'm running as a user in that group. When I install VLC 2.2.2 from the apt repository, it can open /dev/video0 with no problems. However, I'd like to use VLC 3, and when I install it via snap and try to open the video device, it fails. Here's an excerpt from the log:

Code: Select all

$ vlc -vvv /dev/video0 VLC media player 3.0.6 Vetinari (revision 3.0.6-0-g5803e85) [00000000009e33b0] main libvlc debug: VLC media player - 3.0.6 Vetinari [00000000009e33b0] main libvlc debug: Copyright © 1996-2018 the VideoLAN team [00000000009e33b0] main libvlc debug: revision 3.0.6-0-g5803e85 ... [00007fbc480009e0] main input debug: `v4l2:///dev/video0' gives access `v4l2' demux `any' path `/dev/video0' [00007fbc4c000d10] main input source debug: creating demux: access='v4l2' demux='any' location='/dev/video0' file='/dev/video0' [00007fbc4c000e90] main demux debug: looking for access_demux module matching "v4l2": 21 candidates [00007fbc4c000e90] v4l2 demux debug: opening device '/dev/video0' [00007fbc44000980] main meta fetcher debug: looking for meta fetcher module matching "any": 1 candidates [00007fbc4c000e90] v4l2 demux error: cannot open device '/dev/video0': Operation not permitted [00007fbc44000980] lua meta fetcher debug: Trying Lua scripts in /home/user/snap/vlc/770/.local/share/vlc/lua/meta/fetcher [00007fbc4c000e90] v4l2 demux debug: opening device '/dev/video0' [00007fbc44000980] lua meta fetcher debug: Trying Lua scripts in /snap/vlc/770/usr/lib/vlc/lua/meta/fetcher [00007fbc4c000e90] v4l2 demux error: cannot open device '/dev/video0': Operation not permitted [00007fbc4c000e90] main demux debug: no access_demux modules matched [00007fbc4c0020c0] main stream debug: creating access: v4l2:///dev/video0 [00007fbc4c0020c0] main stream debug: (path: /dev/video0) [00007fbc4c0020c0] main stream debug: looking for access module matching "v4l2": 26 candidates [00007fbc4c0020c0] v4l2 stream debug: opening device '/dev/video0' [00007fbc4c0020c0] v4l2 stream error: cannot open device '/dev/video0': Operation not permitted [00007fbc4c0020c0] main stream debug: no access modules matched [0000000000c16300] main playlist debug: dead input

I don't know a lot about snap packaging, but right now my only theory is because it was installed in "strictly confined" mode. I tried installing it in classic mode, but it seems like it just ignores that:

Code: Select all

$ sudo snap install vlc --classic Warning: flag --classic ignored for strictly confined snap vlc

As expected, there is no change in how it behaves. On the other hand, I can install it in development mode:

Code: Select all

$ sudo snap install vlc --devmode vlc 3.0.6 from VideoLAN✓ installed

And now it works, and opening the video stream works just fine. On the other hand, I feel like I shouldn't be completely disabling security confinement and installing in development mode for everyday use. Is there any way to fix this?

[Jean-Baptiste Kempf]

Probably missing some rights. But that is weird, because we asked for camera authorization.

[cosmo6666]

I've had a similar problem for quite some time, but I now have some information which might be useful. I'm running VLC 2.2.2 on Ubuntu 16.04, two workstations, side-by-side. I have multiple remote SSHFS instances, on which I have lots of multimedia content. On the workstation installed using apt, VLC runs fine. On the one installed using snapd, VLC does not find any of the properly mounted remote SSHFS filesystems.

The SSHFS filesystems are easily accessed using the file-manager (which I believe is Thunar). If I use the Parole media player, it can find the remote filesystems. However, even if I open up a sub-directory on a remote system using Thunar, VLC still won't find it.

Here's the new information: If I open up a sub-directory on one of the remote filesystems (all of which contain assorted .mp4 media files), right click on a file, and tell it to open (play) using VLC, it does that successfully. If I select all of the .mp4 files in a sub-directory, right-click on one of them, and tell it to open with VLC, it loads them all into the playlist, and starts playing the first one. If I go to another sub-directory, and do the same thing, all those new .mp4 files get added to the playlist.

So this proves VLC can access the files if passed via the select list. The question remaining: why cant VLC find the remote sub-directories on its own when I click on Media->open-directory?

I haven't had time to delve into snapd to know, but I suspect this may have something to do with the mountable filesystem snap creates for the VLC instance. My guess is that when I load VLC as an ordinary user (which I am), it may not be running as that user, and instead, as something else, possibly root. Since I mount the SSHFS filesystem as an ordinary user (not root), if VLC is not running as the ordinary user which mounted the remote SSHFS filesystem, its possible thats why its not finding the remote volume mount points using the Media->Select Directory sequence.

It seems to me whatever logged-in user runs VLC should own that instance of VLC, and therefore, should have no problem finding entry points and sub-directories of filesystems mounted by that same ordinary user. I'm just speculating, but it looks like the snapd installed version of VLC may be functioning more like an SAAS entity, and if so, one would expect this kind of problem.

Note:SSHFS uses fuse, and /etc/fuse.conf has an entry: 'user_allow_other' which is supposed to enable users other than the one that mounted the remote SSHFS to [access/mount?] it as well, with the same privileges. In my test case, user_allow_other is enabled. But I'm not sure if I'm interpreting the meaning of the flag correctly.

I think its premature to commit VLC to only use snapd at this point. However, perhaps this information will suggest some changes that will enable snapd-versions of VLC to see all the same mount points ordinary users can see, using VLC versions installable via apt.

[milandvorak]

I can confirm this is still an issue.

I'm on Ubuntu 22.04.2 LTS with VLC 3.0.18 from snap and I can't play files from sshfs mount, even if the mount is in my /home/ directory. VLC 3.0.16 installed via apt works fine.

Installing vlc snap with --devmode fixes the issue, but I don't think it's a valid fix.

I tried adding -o allow_other to sshfs command and user_allow_other to /etc/fuse.conf, but it didn't help.

The workaround described in the top post (opening vlc from the context menu) doesn't help me either. VLC just says it can't open the file.

Output of snap connections:

Code: Select all

Interface Plug Slot Notes audio-playback vlc:audio-playback :audio-playback - audio-record vlc:audio-record - - avahi-control vlc:avahi-control - - camera vlc:camera - - desktop vlc:desktop :desktop - desktop-legacy vlc:desktop-legacy :desktop-legacy - dvb vlc:dvb - - home vlc:home :home - jack1 vlc:jack1 - - mount-observe vlc:mount-observe - - mpris - vlc:mpris - network vlc:network :network - network-bind vlc:network-bind :network-bind - opengl vlc:opengl :opengl - optical-drive vlc:optical-drive :optical-drive - pulseaudio vlc:pulseaudio :pulseaudio - removable-media vlc:removable-media :removable-media - screen-inhibit-control vlc:screen-inhibit-control :screen-inhibit-control - unity7 vlc:unity7 :unity7 - x11 vlc:x11 :x11 -