List Linux groups when checking device access

The short answer

To see which groups your account belongs to, run groups or id -nG in a terminal. To see who belongs to a particular group, such as video or audio, run getent group followed by the group name. These commands answer the group question quickly. They do not always explain whether you can use a webcam or its built-in microphone, because many modern desktop distributions grant device access through the login session rather than through group membership.

Commands for listing groups

groups              # groups of the current shell process
id -nG              # same information, names only
id                  # user ID, primary group and all group IDs with names
groups alice        # groups recorded for user alice in the account database
id -nG alice        # same, using id
getent group video  # members of the video group
getent group audio  # members of the audio group
getent group        # every group known to the system

getent reads from whatever account sources the system is configured to use, which can include network directories, so it is more complete than reading the local group file directly. One limitation applies: the member list that getent group prints shows supplementary members only. A user whose primary group is video will not appear in that list, even though they are in the group. The id command shows both primary and supplementary groups.

Why your current shell may disagree with the account database

groups and id without a username report the groups attached to the running process, which were fixed when you logged in. With a username, they report what the account database says now. If someone has just added you to a group, for example with usermod -aG video yourname, the database changes immediately but your existing session does not. Comparing groups with groups yourname makes the difference visible. The usual remedy is to log out and back in; newgrp can start a single shell with the new group, but it does not update the rest of the desktop session or applications already running.

Which groups matter for a webcam and its microphone

A USB webcam with a built-in microphone typically appears to Linux as two separate devices: a video device and an audio capture device. They have different device files and can have different permissions, so being able to see the picture does not prove the microphone is accessible, and the reverse is also true.

Function | Typical device files | Group commonly associated

Camera video | /dev/video0, /dev/video1 and so on | video

Webcam microphone (sound card capture) | files under /dev/snd/, such as pcmC1D0c for capture | audio

Device numbering varies with what else is connected, and group names and defaults vary between distributions, so treat the table as a common pattern rather than a guarantee. To see the actual owner, group and permission bits on your system, list the device files directly.

ls -l /dev/video*
ls -l /dev/snd/
arecord -l          # lists ALSA capture devices, including a webcam mic

When group membership is not the whole story

On many systemd-based desktop distributions, the user logged in at the active local seat receives access to camera and sound devices through access control lists added to the device files, not through the video or audio group. In that case groups may show neither video nor audio while the webcam and its microphone still work. You can check for these per-user entries with getfacl.

getfacl /dev/video0
getfacl /dev/snd/pcmC1D0c

A line naming your user in the output indicates session-based access. Because that access is tied to the active session, it generally does not apply to remote logins or background services. Group membership, by contrast, applies whenever the account runs, which is why some distribution documentation advises against adding desktop users to the audio group: it grants device access beyond the active session and can interfere with how the sound server manages the hardware. Check your distribution's guidance before changing groups.

Practical implications for capturing speech

• Most desktop applications do not open the microphone device directly; they go through a sound server such as PipeWire or PulseAudio, which runs as your user. If the sound server can see the webcam microphone, conferencing apps usually can too, regardless of what groups shows.
• If arecord -l lists the webcam's capture device but an application shows no microphone, the problem is more likely input selection in the app or sound settings than group permissions.
• If arecord -l reports no capture devices, or reports permission errors, compare the device file permissions and ACLs with the output of id to see whether your account is covered.
• If you capture audio from a service, a remote shell or a scheduled job, session ACLs will not apply, and group membership on the device files becomes the relevant check.
• Applications installed as Flatpak or Snap packages have their own camera and microphone permissions, separate from Linux groups; a correct group setup will not override a sandbox denial.

What this guide cannot confirm

No evidence specific to particular webcams, distributions or releases was available for this guide, so it does not state which groups any given system uses by default, and it makes no claims about microphone quality or compatibility of specific models. The commands and mechanisms described are standard Linux behaviour, but the output on your machine is the authoritative answer: run id, list the device files, and check their ACLs before changing any group membership.