![](https://seccdn.libravatar.org/avatar/87ef52ae0ad894245032a45670bb708e.jpg?s=120&d=mm&r=g)
Habe bereits eine Antwort allerdings PM erhalten, die so einiges klärt. Ich poste sie hier, falls noch jemand dasselbe Problem hat oder haben wird - wie auch immer... ;-) Am Sonntag, 21. November 2004 14:27 schrieben Sie:
Am Samstag, 20. November 2004 19:35 schriebst du:
(...). Oder kurz: Wer sich als erster anmeldet ist der einzige mit Sound. Dasselbe Problem tritt übrigens auch beim Brennen auf. Wenn bereits ein Benutzer angemeldet ist bekommt der 2 keinen Zugriff auf die Laufwerke. K3b sagt dann immer: "Es konnten keine Geräte gefunden werden, es kann nur ein Abbild erstellt werden".
Dieses Problem hat mich sehr viel Zeit gekostet. Also beide. Da spielen zeimlich viele Dinge mit rein. Ab SuSE 8.2 der resmgr, das cdrecord von SuSE ist so gepatcht, daß es diesen nutzt, um schreibenden Zugriff auf die Brenner-Devices zu bekommen. Normalerweise wird nur der Nutzer des ersten X-Servers zugelassen. Das kann man in /etc/resmgr.conf umstellen: # # This rule grants access to users logged in locally # allow desktop tty=/dev/tty[1-9]* || tty=tty[1-9]* || tty=:*
Eigentlich steht dort am Ende der Zeile ein ":0", der Stern erlaubt aber eben über jeden X-Server eingeloggtem Benutzer Zugriff auf eine Reihe von Geräte-Dateien (siehe weiter oben in der Datei). Das Brenn-Problem sollte sich also mit obiger Zeile lösen lassen. Achja, als Schnell-Test, wenn unter dem zweiten Benutzer cdrecord -scanbus schon nicht funktioniert, wird es k3b auch nicht tun.
Der Sound ist deutlich komplizierter: Preiswerte Sound-Karten (z. B. AC97) haben nur einen Kanal, d. h. es können gar nicht zwei Programme gleichzeitig das Sound-Device benutzen. KDE umgeht das mit dem artsd (Soundserver, siehe KDE-Kontrollzentrum): Dieser krallt sich das Sound-Device und mischt den Sound der KDE-Applikationen. Siehst du schon das Problem durch diese Kombination? KDE des zweiten Benutzers kann seinen artsd nicht starten, weil der des ersten schon das Sound-Device blockiert! Im KDE-Kontrollzentrum kann man aber einstellen, nach wieviel Sekunden Inaktivität sich der Soundserver schlafen legt und damit das Device freigibt. Nach dieser Zeit könnte dann KDE des zweiten Benutzers seinen artsd starten. Könnte! Die Rechte sind aber falsch gesetzt, der zweite Benutzer hat gar keine Schreibrechte auf die relevanten (und zahlreichen) benötigten Geräte-Dateien. Man kann ihnen von Hand Gruppen-Schreibrechte geben (die Gruppe audio gibt es schon und die Sound-Geräte-Dateien gehören auch dieser Gruppe), aber nach einem Neustart/-login hat wieder nur der als erstes angemeldete Benutzer Schreibrechte (eigentlich der Benutzer vom ersten X-Server ":0"). Warum? Die Datei /etc/logindevperm macht so ziemlich genau das, was der Name verheißt: Sie setzt beim (X-)Login die Geräte-Datei-Berechtigungen. Und zwar auf 0600, also Schreib- und Leserechte nur für den Eigentümer, nicht für die Gruppe. 0660 müßte bei den geteilten Geräte-Dateien stehn. Sound ist meiner Erfahrung nach aber leider nicht nur eine einzige Geräte-Datei bzw. eine einzige Zeile in obiger Datei, es kommen noch Mixer und irgendwelche anderen Dinge dazu. Bei mir unter Verwendung von ALSA genügen diese Datein: jan@linux:~> chmod 0660 /dev/snd/controlC0 /dev/snd/pcmC0D0p /dev/snd/timer Herausgefunden habe ich das unter dem zweiten Benutzer mit: tv@linux:~> strace aplay /opt/kde3/share/sounds/KDE_Error.wav 2>&1 | o Damit sieht man nämlich recht gut, welche Dateien nicht geöffnet werden können. Sprich, in /etc/logindevperm in folgender Zeile die 0600
:0 0600 /dev/snd/*
durch 0660 ersetzen (siehe oben): :0 0660 /dev/snd/* :
Wäre froh, wenn mir jemand beim Sound hilft, das mit dem Brennen ist eher unwichtig, da ich nicht jeden Tag eine CD brenne. ;-)
Es kann sein, daß nach obiger Prozedur immer noch kein Sound kommt, weil beim KDE-Start des zweiten Benutzers noch das Sound-Device blockiert ist. Ich habe hier (zuätzlich zu obigem) auf das dmix-Plugin von ALSA gesetzt. Damit ist es möglich auch bei preiswerten Karten mehrere Kanäle zu nutzen, sprich es spielt artsd, aber eine Ebene tiefer und damit auch für XMMS (ohne arts-Output-Plugin) und sonstige Nicht-KDE-Programme (die aber ALSA unterstützen). Dafür habe ich mirein aktuelles ALSA bei packman geholt: http://packman.links2linux.de/?action=217 Es bringt eine Datei namens /etc/asoundrc.dmix mit, diese kopiert man nach /etc/asound.conf und startet ALSA neu (rcalsasound restart), alles als root oder mit sudo. Danach könnten mehrere Programme gleichzeitig unter einem Benutzer auf das Sound-Device zugreifen. Wieder könnten! Denn das dmix-Plugin bzw. dessen Inter-Prozeß-Kommunikation legt eine Datei in /tmp ab, mit den Rechten 0600. Diese Datei heißt auch immer anders, sodaß man sie nicht mit /etc/logindevperms erschlagen könnte. Die Lösung (ich habe mir den Source von ALSA dafür angeguckt :-) ): In /etc/asound.conf gibt es Zeilen wie ipc_key ... Unter all diese Zeilen schreibst du einfach diese Zeile: ipc_perm 0660 Und schon können auch die Mitglieder der Gruppe audio ALSA mit dem dmix-Plugin benutzen und das sogar gleichzeitig.
Wie du siehst ist das alles eigentlich sehr logisch ... ;-) Zu deiner Problematik und dem dmix-Plugin findest du auch Informationen in den SUSE-ML, in google suchen nach site:lists.suse.com dmix alsa Auf das ipc_perm ist scheinbar aber noch keiner gekommen. .-) Und beim Brenn-Problem verweise viele auf die alte Methode über die Gruppenrechte (wie eben beim Sound), aber ein korrekt konfigurierter resmgr ist um Längen eleganter! site:lists.suse.com resmgr
HTH, Jan
Patrick