Pulseaudio for multiple users, without system-mode daemon
This is a simple and quick solution for those of us who want to run certain programs as a different user on the same desktop, for example running several user profiles of a browser at the same time. The main problem is usually that Pulseaudio doesn’t accept connections from a user other than the one logged in on the desktop.
It’s often suggested to go for a system mode Pulseaudio daemon, but judging from the developer’s own comments on this, and the friendly messages left in the system’s log when doing this, like
Jan 18 16:35:33 ocho pulseaudio[11158]: main.c: OK, so you are running PA in system mode. Please note that you most likely shouldn't be doing that. Jan 18 16:35:33 ocho pulseaudio[11158]: main.c: If you do it nonetheless then it's your own fault if things don't work as expected. Jan 18 16:35:33 ocho pulseaudio[11158]: main.c: Please read http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode for an explanation why system mode is usually a bad idea. Jan 18 16:35:33 ocho pulseaudio[11158]: module.c: module-hal-detect is deprecated: Please use module-udev-detect instead of module-hal-detect! Jan 18 16:35:33 ocho pulseaudio[11158]: module-hal-detect-compat.c: We will now load module-udev-detect. Please make sure to remove module-hal-detect from your configuration
it’s probably not such a good idea. Plus that in my case, the sound card wasn’t detected in system wide mode, probably because some configuration issue, which I didn’t care much about working on. The bottom line is that the software’s authors don’t really want this to work.
Opening a TCP socket instead
The simple solution is given on this forum thread. This works well when there’s a specific user always logged on, and programs belonging to other dummy users are always run for specific purposes.
The idea behind this trick is to open a TCP port for native Pulseaudio communication, only it doesn’t require authentication, as long as the connection comes from 127.0.0.1, i.e. from the host itself. This opens the audio interface to any program running on the computer, including recording from the microphone. This makes no significant difference security-wise if the computer is accessed by a single user anyhow (possible spyware is likely to run with the logged in user ID anyhow, which has full access to audio either way).
This solution works on Fedora Core 12, but it’s probably the way to do it on any distribution released since 2009 or so.
Edit: It has been suggested in the comments below to use a UNIX socket instead of TCP. Haven’t tried it, but it seems like a better solution.
To do as the desktop’s user
So let’s get to the hands-on: First, copy /etc/pulse/default.pa into a file with the same name in the .pulse directory, that is
cp /etc/pulse/default.pa ~/.pulse/
And then edit the file, adding the following line at the end:
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1
At this point, restart the pulseaudio deamon,
$ pulseaudio -k $ pulseaudio -D
To do as the “fake” user
Now switch to the second user, and create a file named client.conf under that user’s .pulse subdirectory
$ echo "default-server = 127.0.0.1" > ~/.pulse/client.conf
Note that default.pa and client.conf are in completely different directories, each belonging to a different user!
Surprisingly enough, that’s it. Any program running as the second user now has sound access.
Reader Comments
Hi Eli,
thank you very much for this post, works perfectly on Debian Wheezy :-)
do you think this will work better then what Valve is doing with SteamOS running Pulse in system wide mode in SteamOS?
Actually, I suppose it will work slightly worse (with a negligible difference) because of the overhead of the TCP connection. I picked this solution to avoid tweaking my system too much.
Works perfectly with Debian Jessie (testing, in June 2014).
Thanks for the tip.
I found this post using a search engine and it worked perfectly for me on Kubuntu 14.04.1 (Ubuntu with KDE).
I run firefox as another less priviledged user and after
applying this configuration sound from firefox is working fine again. Thank you very much for publishing this.
Best regards, Peter.
You can also do this using a unix socket to avoid some overhead of TCP:
/etc/pulse/default.pa:
load-module module-native-protocol-unix auth-anonymous=1 socket=/tmp/my-pulse-socket-name
/etc/pulse/client.conf:
default-server = unix:/tmp/my-pulse-socket-name
Dude,you are lifesaver! Thank you very much!
Very nice, thanks
Wow! That was easy! I’ve been strugling with this problem for a while and I found this solution really clever!
Thank you very much!
Great! Thank you!
Awesome, thanks. Works like a charm on UB 15.10
Thanks for this tip, it works really nicely (also with unix sockets). Here is what I found in addition:
- On gentoo with pulseaudio 7.1 (and probably in many current distributions) the per-user config directory is ~/.config/pulse instead of ~/.pulse
- You do not have to copy /etc/pulse/default.pa, but can instead create ~/.config/pulse/default.pa starting with the following directive:
- In order to avoid problems stop any programs that are running for the secondary user before restarting the pulseaudio daemon.
Found this on a search. It works great and fixed an issue I was having. Thanks so much.
Note that you can also set network access using paprefs (Debian package of same name). In paprefs, choose Network server => Enable network access to local sound devices & Don’t require authentication.
There’s no need to copy/edit default.pa or to create a client.conf for the secondary user(s).
Paprefs uses gconf and stores its config in ~/.gconf/system/pulseaudio/modules/remote-access/\%gconf.xml (you’d better remember this if you also use a default.pa and are wondering why something doesn’t work).
Thanks for the socket tip, anonymous.
Easy and worked right of the bat!
I have a xrdp terminal running by my PC, and now both the PC and the terminal have audio coming out of the PC!
Thanks, the solution before Pulseaudio 9.0 but does not anymore on ArchLinux :( May be due to some security changes in the new version.
Thanks for writing up such a clear and straight forward solution. Thanks also to those that have posted comments that add further refinements such as using a UNIX socket.
I refined the solution to direct output from different users to different sinks, for example:
default-server = unix:/tmp/share-pulse
default-sink = alsa_output.usb-FiiO_DigiHug_USB_Audio-01.analog-stereo
The sink names can be obtained from the output of ‘pactl list’ when logged in as the server’s user.
The solution works perfectly, even to this day!
pulseaudio 10.0-2
Hello. Used the UNIX socket variant by anonymous commenter with the .include by canaaerus. Works. Before that, used an even simpler trick which is to add a specific user to the audio group. That user, and only that user, can then use audio (including recording) at any time. This may be better security-wise than opening that users’ pulseaudio daemon to all other users. For example, user A is in group audio, user B is not. Programs running as user A can play music at any time. User B can join videoconference. When console switches to user A, user B’s videoconference should get isolated (no sound input or output). The solution explained on this page loses the nice isolation property.
Works perfectly for me ;-)
WOW that’s awesome! Many thanks :-)
i have the same issue on embedded, but i have only one user here and can not switch to another user. can you help me ?
Thanks a lot!!!!!!!!!
The solution with the socket seems to be better at first glance, but I switched back to the TCP approach because simultaneous output by both users did not work (say, I paused a YouTube video from user A, switched to user B and tried to play something else).
Maybe simply a permissions problem with the socket file?
I did find this post when having the similar problem on KUbuntu 18.04 with firefox as of today.
The solution still works great ! Thanks a lot !
Thank you very much.
I used this solution for a longer time, but switched to unix socket. With this solution, there is no “master” user and you can control which users are allowed to use the socket by the “audio” group.
I followed this guide:
https://dhole.github.io/post/pulseaudio_multiple_users/
it’s not working for me. there is no ~/.pulse directory in my Xubuntu 18.04.
i have 25 users on my laptop with typically 10 or more logged in at the same time. i jump from user to user often. i just want the music to keep on playing.
Still works in 2019. Thank you. The only suggestion, is that you should’ve written in caps “VERY EASY SOLUTION” on the first line. I was inclined to skip the article at first
Skaperen, you’ve to create the directory yourself, if it’s not present
This helped fix my daughters problem of no sound running minecraft client on centos 7 under a separate minecraft user account. It was hard to understand why it didn’t work at first.
Works great on Mint 19.3, thanks!!
Other UX-related protocols such as X11 allow more fine-grained control — for example, one can run
xhost +SI:localuser:mysecondaccountto SPECIFICALLY whitelist a second account, without opening up the display server to anything-whatsoever able to emit packets from localhost. MariaDB allows piggybacking off unix-username for authentication, too.Does PulseAudio have any similar controls? A blanked whitelist for TCP 127.0.0.1 may work, but it seems inelegant.
What a shitty hack. Why can’t I have audio work across different users like it does on other operating systems? I swear to God Lennart Poettering foisted PulseAudio on us just to keep Linux from being competitive with Windows.
This gruesome hack has been borrowed by EasyOS and it has caused me grief when trying to run pa server because it hogs onto the socket arghhhh
Works great with Debian 12.7 and Devuan 5. Just use ~/.config/pulse instead of ~/.pulse Thanks!