I've reported the issue originally at debian, here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812557. Most of the report is c&p from there :) I'be updated debian testing (didn't update in a while) and after I upgraded, sound from programs that run as a different user stopped working. When some other user tries to run: "/usr/bin/pulseaudio --start --log-target=syslog" it fails with errors like: Jan 24 22:01:58 lindsay pulseaudio[10238]: [pulseaudio] main.c: User-configured server at {d07a5e247c911a2ac8ca6d8652d822c1}unix:/run/user/1000/pulse/native, refusing to start/autospawn. Jan 24 22:08:13 lindsay pulseaudio[11867]: [pulseaudio] main.c: User-configured server at lindsay, refusing to start/autospawn. Both users, the user that opened the desktop environment (let's call him userA) and the other user trying to run pulseaudio/firefox (let's call him userB) are member of group audio. Also, userA uid is 1000 and userB uid is 1001. Usually, as autospawn is enabled, when running firefox as userB and sound was needed, pulseaudio was started and audio just worked. Now everything works fine, except audio doesn't play. Probably because it fails as above when trying to start pulseaudio. To run firefox I use: "sudo -u userB -- firefox" and a previous "xhost" to allow userB to use the X display. I've found the following work-around, though, to make this work again and this is why I'm reporting it to pulseaudio. If userA logins to the desktop env and opens a console and as userB (I'm doing "su - userB") runs: pax11publish -r; /usr/bin/pulseaudio --start --log-target=syslog then audio works again. Also, as suggested by Felipe in the debian bug, disabling the x11 publish module, via disabling the autostart of start-pulseaudio-x11 (by removing/moving away the /etc/xdg/autostart/pulseaudio.desktop file), makes audio work again (a pulseaudio is started as userB when doing this workaround too). To check if audio works, and to be sure is nothing related to firefox, I run as userA in the desktop env: sudo -u userB -- aplay /usr/share/sounds/alsa/Front_Center.wav After doing the "pax11publish ..." command above, this command works. Before it does not. And, of course, this also fixes the audio in firefox. Please let me know if I can help you in any way Thanks a lot, Rodrigo
So userA and userB run in the same graphical login session? I suppose you want to use the same audio hardware for both users. Starting separate pulseaudio servers will likely cause problems, because both pulseaudio instances can't use the sound card at the same time. Therefore, I think it's best to use only one pulseaudio instance, just like you use only one X instance. userB doesn't have access to /run/user/1000/pulse/native, which is why userB tries to start its own pulseaudio instance. And even if userB has access to the socket, pulseaudio will reject the connection attempt by a different user. There are a few steps to make this work: Copy /etc/pulse/default.pa to /home/userA/.config/pulse/default.pa and change this line load-module module-native-protocol-unix to load-module module-native-protocol-unix auth-anonymous=true After that change anyone having access to the socket will be allowed to connect. Then give userB access to /run/user/1000/pulse/native (setfacl can probably be used to grant access to only that user, but I don't know the exact command). It's probably also a good idea to not rely on the x11 property to point userB to userA's pulseaudio socket, so you can add "default-server = /run/user/1000/pulse/native" to /home/userB/.config/pulse/client.conf (I'm assuming that userB is only used from within userA's login sessions, so we don't need to support the case where userB logs in separately).
Thanks! I didn't know that with 2 pulseaudio they won't be allowed to user the sound card at the same time. I reported the bug because this *used* to work (i.e. creating 2 pulseaudio). But, with that restriction, I'm fine doing it this way if this setup is supported =) Also, your assumption is correct. userB is only used within userA's login sessions. But, I tried those steps, and keeping the /etc/xdg/autostart/pulseaudio.desktop file and it doesn't work. I run firefox, or a an aplay command, and audio doesn't work. I did exactly those steps, when running (as userA): $ sudo -u userB -- aplay /usr/share/sounds/alsa/Front_Center.wav It fails with: ALSA lib pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave aplay: main:722: audio open error: No such file or directory Nothing new in syslog when I run this, so not sure what info do you need. Permissions on /run/user/1000/pulse/native are srwxrwxrwx+ (I also added the acl, just in case pulse, but nothing changed). I'm sorry this is probably not enough to debug, but what other info can I give you? Thanks a lot! Rodrigo
Oh, wait, it was a silly mistake. It was because the parent folders, /run/user/1000/ and /run/user/1000/pulse/, weren't readable by userB. But /run/user/1000 is a tmpfs, I'm not sure how to change these permissions easily. Do you know? If it's not possible, I'm not sure this is a solution :-/
I mean, how to change the permissions in a way that works across reboots
I thought you already had some xhost command that you have to run every time? Setting up the pulseaudio permissions wouldn't be any more inconvenient. Maybe I'm misunderstanding something.
I'd like this to be way more simple, so it doesn't break so easily, but good point. I can do that and it works. Thanks! I guess, then, that a new pulseaudio fails to start is not a bug, but a bugfix/feature, right? :)
I don't actually know why it stopped working, unless you upgraded from a very old version. I don't think there have been any relevant changes in this area for a while.
If you wish to have the socket somewhere else, you can pass socket=/somewhere/else to module-native-protocol-unix the same way you pass auth-anonymous=true.
Great, thanks a lot! :-)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.