How to Install a Mumble Server on Ubuntu 24.04

Mumble is an open-source, low-latency voice chat application popular with gaming communities and remote teams. Its server component, historically called Murmur and now packaged as mumble-server, is lightweight and encrypts all traffic. In this guide you will install the Mumble server on Ubuntu 24.04, configure it, set the SuperUser password, open the firewall, organize channels with access control lists (ACLs) and optionally replace the self-signed certificate with one from Let's Encrypt.

Prerequisites

To follow this guide you need:

A server running Ubuntu 24.04 LTS, for example a CubePath VPS. Mumble needs very few resources: 1 vCPU and 512 MB of RAM comfortably handle dozens of users.
A non-root user with sudo privileges.
The Mumble client installed on your computer, available from the official site for Windows, macOS and Linux.
Optionally, a domain name such as mumble.your_domain with an A record pointing to the server, if you want users to connect by name or use a Let's Encrypt certificate (Step 7).

Step 1 - Installing the Mumble server

Ubuntu 24.04 provides Mumble server 1.5 in the universe repository. Install it:

sudo apt update
sudo apt install mumble-server

The package creates a mumble-server system user, installs the configuration in /etc/mumble/mumble-server.ini and enables a systemd service. Check that the service is running:

sudo systemctl status mumble-server --no-pager

● mumble-server.service - Mumble Server
     Loaded: loaded (/usr/lib/systemd/system/mumble-server.service; enabled; preset: enabled)
     Active: active (running)

Confirm that it listens on the default port, 64738, over both TCP (control channel) and UDP (voice):

sudo ss -tulpn | grep 64738

udp   UNCONN 0      0        0.0.0.0:64738      0.0.0.0:*    users:(("mumble-server",pid=1432,fd=31))
tcp   LISTEN 0      50       0.0.0.0:64738      0.0.0.0:*    users:(("mumble-server",pid=1432,fd=29))
...

Step 2 - Setting the SuperUser password

Mumble has a built-in administrative account called SuperUser that bypasses all permission checks. You use it to create the initial channels and give admin rights to your own registered account. The Debian package sets its password through dpkg-reconfigure:

sudo dpkg-reconfigure mumble-server

The tool asks three questions:

Autostart mumble-server on server boot? Answer Yes.
Allow mumble-server to use higher priority? Answering Yes gives the process higher CPU and network priority, which helps keep latency low on a busy server.
Password to set on SuperUser account: enter a long, random password.

Step 3 - Configuring the server

Open the configuration file:

sudo nano /etc/mumble/mumble-server.ini

The file is well commented and most settings have sensible defaults. Find and adjust the following keys (remove the leading ; from lines that are commented out):

; Message shown to users when they connect
welcometext="<br />Welcome to our Mumble server.<br />"

; Port for both TCP and UDP
port=64738

; Password required to connect. Leave empty for a public server.
serverpassword=your_server_password

; Maximum number of simultaneous users
users=50

; Maximum voice bandwidth per user, in bits per second
bandwidth=72000

; Name of the root channel shown in the client
registerName=My Mumble Server

; Only allow clients that present a certificate
certrequired=true

; Temporarily ban an IP after 10 failed attempts within 120 seconds
autobanAttempts=10
autobanTimeframe=120
autobanTime=300

Some notes on these settings:

serverpassword is a shared password for everyone. It is the easiest way to keep a private server private. Leave it empty if you prefer to rely on channel ACLs.
bandwidth is expressed in bits per second. 72000 (72 kbit/s) gives very good Opus voice quality; the default of 558000 allows the highest quality settings in the client.
certrequired=true rejects clients without a certificate. Every Mumble client generates a certificate on first launch, so this only blocks unusual or scripted clients and makes registered identities more reliable.
Leaving registerPassword and registerHostname commented out keeps the server out of the public Mumble server list.

Restart the service to apply the changes:

sudo systemctl restart mumble-server

Check the log for errors:

sudo journalctl -u mumble-server -n 20 --no-pager

A healthy start includes lines such as Server listening on 0.0.0.0:64738.

Step 4 - Opening the firewall

Allow SSH first so you keep access, then open the Mumble port for TCP and UDP:

sudo ufw allow OpenSSH
sudo ufw allow 64738/tcp
sudo ufw allow 64738/udp
sudo ufw enable

Verify the rules:

sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
64738/tcp                  ALLOW       Anywhere
64738/udp                  ALLOW       Anywhere
...

Step 5 - Connecting, registering users and creating channels

Connecting as SuperUser

In the Mumble client, open Server, then Connect, and click Add New. Fill in:

Address: your_server_ip or mumble.your_domain
Port: 64738
Username: SuperUser

Connect and enter the SuperUser password. The first time, the client warns that the server certificate is self-signed. You can accept it, because the client then remembers the certificate and warns you if it ever changes. Step 7 shows how to use a trusted certificate instead.

Registering your own account and making it admin

Using SuperUser for daily work is not a good idea. Instead, connect a second time with your normal client under your own name (for example alice), then, from the SuperUser session:

Right-click alice in the user tree and choose Register. The account is now tied to that client's certificate.
Right-click the root channel, choose Edit, and open the Groups tab.
Select the admin group and add alice to its members.

From now on alice has administrative rights in all channels that inherit the root ACL. Disconnect the SuperUser session and keep its password for emergencies.

Tip

Because registration is tied to the client certificate, users should back it up from Configure, Certificate Wizard, Export current certificate and import it on other devices. Otherwise a new device appears as a different user.

Creating channels

Right-click the root channel and choose Add. Give the channel a name (for example General, Team or AFK), an optional description, and set Maximum users if needed. Enable Temporary only for channels that should disappear when the last user leaves. Channels can be nested by adding them under another channel.

Step 6 - Restricting a channel with ACLs

ACLs decide who can see, enter and speak in each channel. They are evaluated from the root channel down, and later rules override earlier ones. The built-in groups you use most are:

Group	Members
`all`	Everyone connected to the server
`auth`	All registered users
`admin`	Users you added to the admin group
`in` / `out`	Users currently inside / outside this channel

As an example, make a Team channel that everyone can see but only members of a team group can enter:

Right-click Team and choose Edit.
On the Groups tab, click Add, create a group named team and add the registered users who should have access.
On the ACL tab, keep Inherit ACLs checked so the admin rules from the root still apply.
Add an entry for group all: deny Enter and Speak.
Add another entry below it for group team: allow Enter, Speak and Text message.
Click OK.

Test it by connecting with an account that is not in team: the channel is visible, but attempting to join it shows a permission denied message.

Step 7 - Using a Let's Encrypt certificate (optional)

The self-signed certificate works, but every user sees a warning on first connection. If you have a domain, you can use a Let's Encrypt certificate instead. Certbot's standalone mode needs port 80 to answer the challenge:

sudo apt install certbot
sudo ufw allow 80/tcp
sudo certbot certonly --standalone -d mumble.your_domain

The private key under /etc/letsencrypt is readable only by root, so copy the certificate to a location the mumble-server user can read. A Certbot deploy hook does this after every renewal. Create the hook:

sudo nano /etc/letsencrypt/renewal-hooks/deploy/mumble-server.sh

#!/usr/bin/env bash
set -euo pipefail

domain="mumble.your_domain"
src="/etc/letsencrypt/live/${domain}"
dest="/etc/mumble"

install -m 0644 -o root -g root "${src}/fullchain.pem" "${dest}/fullchain.pem"
install -m 0640 -o root -g mumble-server "${src}/privkey.pem" "${dest}/privkey.pem"
systemctl restart mumble-server

Make it executable and run it once to copy the current certificate:

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/mumble-server.sh
sudo /etc/letsencrypt/renewal-hooks/deploy/mumble-server.sh

Point Mumble at the copied files:

sudo nano /etc/mumble/mumble-server.ini

sslCert=/etc/mumble/fullchain.pem
sslKey=/etc/mumble/privkey.pem

Restart the server and confirm that the renewal works end to end:

sudo systemctl restart mumble-server
sudo certbot renew --dry-run

Reconnect with the client: the certificate warning no longer appears. Clients that had accepted the old self-signed certificate see a one-time notice that the certificate changed. The restart in the hook briefly disconnects users, which only happens when the certificate is renewed, roughly every two months.

Troubleshooting

Clients cannot connect. Check that the service is running and listening, and that both TCP and UDP 64738 are open in UFW and in any external firewall:

sudo systemctl status mumble-server --no-pager
sudo ss -tulpn | grep 64738

Voice works but the client shows "UDP packets cannot be sent to or received from the server". The client has fallen back to TCP, which adds latency. UDP 64738 is being blocked somewhere between the client and the server.

The server does not start after editing the configuration. A typo in mumble-server.ini or an unreadable certificate file is the usual cause. Read the journal:

sudo journalctl -u mumble-server -n 50 --no-pager

A user gets "Permission denied" when joining a channel. Open the channel's ACL tab and check the order of the entries: a later deny rule overrides an earlier allow rule. Remember that group membership only works for registered users.

Conclusion

You now have a Mumble server running on Ubuntu 24.04 with a SuperUser password, a hardened configuration, firewall rules, channels restricted by ACLs and, optionally, a trusted TLS certificate. As next steps, you can back up /etc/mumble/ together with the server's SQLite database, which holds registered users, channels and ACLs, share a mumble://mumble.your_domain link with your users, and ask them to use push-to-talk or voice activation with noise suppression for the best audio quality.

On this page