Dennis HilkLinux Fix LabDE

Audio, ALSA & PipeWire

Audio device access fails in the current session

Diagnose ALSA permission refusal and Bluetooth session ownership using login state and device ACL evidence, then repair access without broad device permissions.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • PipeWire cannot open an ALSA PCM due to permission denied.
  • Audio works in the active GUI but fails in SSH or another seat/session.

Relevant environment

Desktop audio under systemd-logind or an equivalent seat manager; headless sessions require an intentional access model.

Recognizable messages (synthetic examples)
pipewire[2140]: [alsa-pcm.c:1250 spa_alsa_open()] hw:0,0: playback open failed: Permission denied

Inspect session and device ACLs; application-file permissions and microphone mute are unrelated to this signature.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • The process may not belong to an active local session with the required device access.
  • Broken login/PAM integration, stale ACLs or a second user owning Bluetooth audio can require a session-layer correction.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace SESSION_ID with the affected session listed by loginctl. Read session properties; this does not activate or terminate it.

loginctl show-session SESSION_ID -p Active -p Remote -p Seat -p Type -p Name

Interpret the result: An inactive or remote session can explain missing seat-granted device access. Headless audio must be configured deliberately rather than pretending to be a desktop seat.

Check 2

Replace the node with the affected playback PCM from ALSA enumeration. Read its ownership and ACL without altering permissions.

getfacl /dev/snd/pcmC0D0p

Interpret the result: Check whether the actual desktop user has effective rw permission, including the ACL mask. Missing access plus an inactive session supports seat-policy investigation.

Evidence-guided next steps

Restore the intended local login session

If audio was launched from sudo, SSH or an inactive session, run the client from the active graphical account and its user audio server. If a custom login path bypasses normal session registration, repair the distribution’s PAM/logind integration and log in again.

Precautions: Do not chmod /dev/snd to world-writable or run desktop audio as root. Logging out interrupts all work in that session.

Recovery / rollback: Restore the recorded login configuration if the change breaks session creation; use the known working login path for recovery.

Did this solution help you?

Share this solution#

Design dedicated headless audio access

If unattended audio is intentional, use a dedicated account and the distribution’s documented service/device access model. For Bluetooth, review WirePlumber’s seat-monitoring feature only for that dedicated instance so display-manager ownership is not mistaken for a codec failure.

Precautions: Disabling seat monitoring changes who can own Bluetooth devices and may cause contention. Keep desktop instances using their normal session policy.

Recovery / rollback: Remove the dedicated override and restore previous service permissions and startup policy if ownership conflicts occur.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.