Audiogerätezugriff scheitert in aktueller Sitzung · Linux Fix Lab

Symptome und Geltungsbereich

PipeWire kann ALSA-PCM wegen Permission denied nicht öffnen.
Audio funktioniert in aktiver GUI, scheitert aber über SSH oder andere Seat-/Sitzung.

Betroffene Umgebung

Desktop-Audio unter systemd-logind oder vergleichbarer Seat-Verwaltung; Headless-Sitzungen brauchen bewusstes Zugriffsmodell.

Erkennbare Meldungen (synthetische Beispiele)

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

Sitzung und Geräte-ACL prüfen; Anwendungsdateirechte und Mikrofon-Stummschaltung gehören nicht zu dieser Signatur.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Der Prozess gehört möglicherweise nicht zu aktiver lokaler Sitzung mit nötigem Gerätezugriff.
Defekte Login-/PAM-Integration, alte ACLs oder Bluetooth-Besitz eines zweiten Benutzers können Sitzungsreparatur benötigen.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

SESSION_ID durch betroffene Sitzung aus loginctl ersetzen. Eigenschaften lesen; Sitzung wird weder aktiviert noch beendet.

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

Ergebnis einordnen: Inaktive oder entfernte Sitzung kann fehlenden Seat-basierten Gerätezugriff erklären. Headless-Audio bewusst konfigurieren, statt Desktop-Seat vorzutäuschen.

Prüfschritt 2

Node durch betroffenen Wiedergabe-PCM aus ALSA-Erkennung ersetzen. Eigentümer und ACL lesen, ohne Rechte zu verändern.

getfacl /dev/snd/pcmC0D0p

Ergebnis einordnen: Wirksames rw-Recht des tatsächlichen Desktop-Benutzers einschließlich ACL-Maske prüfen. Fehlender Zugriff plus inaktive Sitzung stützt Untersuchung der Seat-Richtlinie.

Nächste Schritte nach Befund

Vorgesehene lokale Login-Sitzung herstellen

Wenn Audio aus sudo, SSH oder inaktiver Sitzung gestartet wurde, Client im aktiven grafischen Konto mit dessen Benutzer-Audioserver ausführen. Wenn eigener Login-Pfad normale Sitzungsregistrierung umgeht, PAM-/logind-Integration der Distribution reparieren und neu anmelden.

Vorsicht: /dev/snd nicht weltweit beschreibbar machen oder Desktop-Audio als Root ausführen. Abmelden unterbricht alle Arbeit der Sitzung.

Wiederherstellung / Rücknahme: Dokumentierte Login-Konfiguration wiederherstellen, falls Änderung Sitzungsaufbau stört; bekannten funktionierenden Login-Pfad zur Rettung nutzen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Dedizierten Headless-Audiozugriff planen

Wenn unbeaufsichtigtes Audio gewollt ist, eigenes Konto und dokumentiertes Dienst-/Gerätezugriffsmodell der Distribution nutzen. Für Bluetooth WirePlumbers Seat-Monitoring nur für diese eigene Instanz prüfen, damit Display-Manager-Besitz nicht als Codecfehler gilt.

Vorsicht: Seat-Monitoring abschalten verändert Bluetooth-Gerätebesitz und kann Konkurrenz erzeugen. Desktop-Instanzen bei normaler Sitzungsrichtlinie belassen.

Wiederherstellung / Rücknahme: Dedizierten Override entfernen und bisherige Dienstrechte sowie Start-Richtlinie wiederherstellen, falls Besitzkonflikte entstehen.