How to Fix Permission Denied Error for `/dev/video0` on Linux

Camera device nodes like /dev/video0 are owned by root and the "video" system group by default, so a regular user account needs to be added to that group before it can access the camera without using sudo for every single app. Run sudo usermod -aG video $USER, then fully log out and back in — group membership changes never take effect within an already-running session.

Why Linux Blocks User Access to Camera Nodes

Linux treats hardware device nodes as regular files with regular Unix ownership and permissions, and camera nodes are no exception — /dev/video0 is typically owned by the root user and the "video" group, with permission set so that only root and members of that group can read from it. This is a deliberate security boundary: without it, any user or process on a shared or multi-user system could silently access the camera.

A newly created user account is not automatically added to the video group on every distribution, particularly on minimal server-style installs or after certain manual account creation methods — this is the single most common cause of a "Permission denied" error when a camera is otherwise correctly detected and has working drivers.

Commands to Fix Device Node Permissions

Step 1: Check your current group membership

With groups. If "video" isn't listed, that confirms the cause.

Step 2: Add your user to the video group

With sudo usermod -aG video $USER.

Step 3: Fully log out and log back in

(or restart). Group membership is only re-evaluated at login, so this step cannot be skipped — simply opening a new terminal window is not enough.

Step 4: Confirm the fix

By running groups again, and check ls -l /dev/video0 to see the group ownership directly.

Step 5: Test in your browser.

↑ Use the widget above for a normal, no-sudo-required confirmation that the permission fix actually worked.

Running an app with sudo as a workaround will make that specific run work, but it's not a real fix — it doesn't resolve the underlying permission for normal, non-elevated use, and running graphical browsers as root is generally discouraged for unrelated security reasons.

This Applies Across Distributions

This same group-membership requirement is genuinely universal across Linux distributions, even though the specific group name has varied historically on a small number of less common distributions — "video" is the standard, current name used by Ubuntu, Debian, Fedora, and the large majority of others you're likely to encounter, so this fix transfers directly if you ever move between distributions.

It's worth checking whether you're using a security-hardened Linux setup if this fix doesn't fully resolve the issue after a proper logout and login — some corporate or specialized security-focused distributions restrict device access more tightly than a standard desktop install. Those environments sometimes layer additional access controls, like AppArmor or SELinux policies, on top of the standard Unix group permission system covered here, and would need their own specific policy adjusted in addition to your group membership.

Docker or other container-based setups add one more layer worth knowing about: a containerized application needs the video device explicitly passed through to the container (typically via a --device flag), since container isolation means group membership on the host system alone is not automatically visible inside it.

A Few More Things to Check on Linux

Am I actually in the video group, and does that matter?

Linux gates /dev/video0 access through the video group at the OS permission level, independent of any app or browser setting. Check membership with groups $USER in a terminal — if video isn’t listed, add yourself with sudo usermod -aG video $USER, then fully log out and back in for the change to take effect. Without this, every application will fail to open the camera regardless of any other setting.

How do I confirm the camera is even detected before troubleshooting software?

Run v4l2-ctl --list-devices (or the simpler ls /dev/video*) in a terminal before changing any application setting. This confirms whether the kernel sees the hardware at all — if no device node appears, the problem is detection or a driver, and no amount of app-level configuration will fix it. If a device does appear, you’ve confirmed the hardware layer is fine and the problem sits higher up, in permissions or a specific application.

Does my laptop or external webcam have a physical privacy switch?

Some laptops and most dedicated external webcams include a physical shutter or hardware switch that mechanically blocks the lens or cuts power, entirely separate from any Linux permission or driver setting. Check the camera housing itself, and the laptop’s screen bezel near the lens, before assuming a software fix is needed — a closed physical shutter produces exactly the same black frame as a permissions problem.

Once this is fixed, testing your webcam online is a quick way to confirm the camera is fully working again, not just detected.