Snap app denied access to /dev/video0 by AppArmor after kernel update on Ubuntu 22.04

Environment

Ubuntu 22.04 desktop upgraded kernel recently; camera is a UVC webcam exposed as /dev/video0; application installed as a snap (example: snap 'cheese' or a snap-packaged videoconferencing client).

Symptoms

Snap application shows a black preview and immediately exits or freezes when attempting to open the camera. Native (apt) applications such as guvcview can open the camera successfully.

Observations

dmesg and journalctl show AppArmor DENIED messages referencing the snap process trying to open /dev/video0. 'snap connections <snap-name>' shows the 'camera' interface exists but appears connected; /dev/video0 owner/group is root:video and user is in the video group. After running 'snap connect <snap>:camera' and rebooting, AppArmor DENIED entries persist.

Already attempted

Connected the snap's camera interface, added user to video group, reinstalled the snap, rebooted, tested the camera with a non-snap program (works), created a udev rule to set /dev/video0 permissions (no effect on AppArmor denial), tried running the snap in devmode (worked, but devmode disables confinement and is not acceptable long term).

Question

What steps will allow the confined snap to access the camera persistently without disabling confinement, and what diagnostics should I run to determine whether this is a snapd/AppArmor regression after the kernel update?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

snapd or kernel update changed how the 'camera' interface is enforced, causing snap claims to be ignored or misrouted. 75%

Snap was confined against a different device node (by by-id path) and the kernel now presents the device under a different path. 20%

AppArmor profile for the snap no longer matches the device node path (e.g., device symlink path changed after udev/driver changes). 15%

Summary

AppArmor is blocking the snap from opening the camera device, even though the camera interface appears connected. The snap confinement relies on interface plugs and kernel AppArmor policies; a kernel or snapd change can alter how device nodes or labels are matched, causing previously working snaps to receive DENIED. The fact native apps can open the device and the snap works in devmode indicates the hardware and udev permissions are fine and the problem is confinement policy or interface mapping.

Suggested Fixes

Diagnostic step 1

Inspect denials with 'journalctl -k' and 'journalctl -e' and copy the exact AppArmor denial lines (include executable path, requested syscall, and device path) for diagnosis.

Diagnostic step 2

Run 'snap connections <snap-name>' and confirm 'camera' shows as connected; if it does not, run 'sudo snap connect <snap-name>:camera' and re-test (this is reversible).

Diagnostic step 3

Use 'aa-status' to confirm AppArmor is enabled and look up the profile name shown in the DENIED messages; temporarily set that profile to complain mode with 'sudo aa-complain <profile>' to test whether AppArmor is the blocker (reversible, but do not leave in complain mode in production).