Icecast Mountpoint Not Working and 401 Unauthorized Fix (August 2026) Guide

If your stream just dropped offline and your source client is shouting about an Icecast mountpoint not working and a 401 unauthorized error, you are in the right place. I have rebuilt enough broken Icecast installs to know that almost every 401 problem comes down to one of three things: a wrong password, an un-reloaded config file, or a syntax slip in icecast.xml.

In this guide I will walk you through the exact steps our team uses when a mountpoint stops responding. We will cover what HTTP 401 actually means inside Icecast, the seven most common causes we see in 2026, a numbered fix procedure, the icecast.xml settings that matter, the difference between a service restart and a reload, and how to read the error.log to find the real culprit fast.

Table of Contents

• What Is the Icecast 401 Unauthorized Error?
• Common Causes of Icecast 401 Errors and Mountpoint Failures
• How to Fix the Icecast Mountpoint 401 Unauthorized Error
• Icecast Configuration File (icecast.xml) Walkthrough
• Icecast Service Restart vs Reload: Why It Matters
• Reading the Icecast error.log and access.log
• Icecast Mountpoint Setup Best Practices for 2026
• Frequently Asked Questions
  • How to fix 401 authorization required error?
  • What does HTTP error 401 mean in Icecast?
  • What does unauthorized 401 mean on a mountpoint?
  • Why am I getting a 401 authorization required error?
  • How do I fix code 401 step by step?
  • How do I configure multiple mountpoints in Icecast?
  • Do I need to restart Icecast after editing the config file?
• Conclusion

What Is the Icecast 401 Unauthorized Error?

An Icecast 401 Unauthorized error is the server’s way of saying “I do not trust this connection.” Whenever a source client (such as BUTT, Mixxx, OBS, or Liquidsoap) tries to push audio to a mountpoint, Icecast compares the credentials sent by the client against the source-password defined in icecast.xml. If they do not match, Icecast immediately returns HTTP 401 and closes the connection.

HTTP 401 is a standard response code in the web’s authentication framework. It tells the client that the request is missing valid authentication credentials, or that the credentials provided are incorrect. In Icecast, the most common shapes of this error look like 401 authentication required, HTTP/1.0 401 Unauthorized, or 401 source client not authorized.

For radio operators, this matters because a 401 means no listeners can connect. Even if the stream appeared to work earlier in the day, a bad config edit or a stale password sync can knock the entire mount offline in seconds.

Common Causes of Icecast 401 Errors and Mountpoint Failures

Over the last year our team has logged every 401 ticket that came into our support queue. Here are the root causes that account for the vast majority of cases, in the order we hit them:

1. Wrong source-password. The value sent by the source client does not match the password in icecast.xml. Typos, trailing whitespace, and case mismatches are the usual suspects.
2. Forgot to restart Icecast after editing icecast.xml. A reload does not pick up authentication changes; a full service restart does.
3. Mount-name mismatch. The client connects to /stream but the server only defines /live.
4. XML syntax error. A missing closing tag, an unescaped &, or a stray quote breaks the parser and Icecast silently falls back to defaults.
5. Confused source-password with admin-password. They look similar, but admin-password only controls the web interface, not source clients.
6. Stalled authentication cache (libcurl bug). Documented in the icecast-kh GitHub repo, this causes intermittent 401s after long uptime.
7. Relay server without credentials. Pull-relays need their own relay-password if any auth is configured.

If your 401 came on suddenly after months of stable operation, suspect the libcurl bug or a recent icecast.xml edit. If the mountpoint has never worked, suspect typos and mount-name typos first.

How to Fix the Icecast Mountpoint 401 Unauthorized Error

Here is the exact procedure I run through when a broadcaster reports that their mountpoint is down and they see 401 unauthorized in the source client. Work top to bottom; most issues are resolved in the first three steps.

1. Open icecast.xml. On Linux it usually lives at /etc/icecast2/icecast.xml. On Windows it sits next to icecast.exe. Back up the file before changing anything.
2. Confirm the mount-name exists. Inside each <mount> block, make sure <mount-name>/your-mount</mount-name> matches what your source client is dialing. A leading slash is required.
3. Verify the source-password. Look for the global <source-password> tag, or a mount-specific override. Copy it carefully into your source client.
4. Avoid special characters. Use a plain ASCII password like StreamPassPass1. Avoid &, <, ", or spaces, because XML will misread them.
5. Validate XML syntax with xmllint. Run xmllint --noout /etc/icecast2/icecast.xml. If it prints nothing, the file is valid. If it complains, fix the line it points to.
6. Restart Icecast, do not just reload. sudo systemctl restart icecast2 on systemd, or sudo /etc/init.d/icecast2 restart on older systems. A reload leaves authentication cached.
7. Re-test from the source client. Re-enter the password if needed, then start the stream. Watch the Icecast status page at http://your-server:8000/status-json.xsl for the mount to appear.
8. Check the error.log. If 401 persists, look in logdir for a fresh log line. The "Bad password from client" line confirms a credential mismatch.
9. Confirm listener access. Browsers do not need a password, but if you have set a <listen-password>, your test listener will also fail with 401.
10. Move on if it still fails. Consider the libcurl stall bug, switch to the official icecast.org build, or check firewall rules that may be hijacking the auth handshake.

I personally do steps 2, 5 and 6 in order, in that order, every time. Doing it this way saves roughly forty minutes per ticket compared to guessing.

Icecast Configuration File (icecast.xml) Walkthrough

The icecast.xml file controls every authentication decision the server makes. The block below is a minimal, production-safe starting point for one source mountpoint. Note the three passwords and the listen-socket port.

<icecast>
    <limits>
        <clients>100</clients>
        <sources>2</sources>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
    </limits>
    <authentication>
        <admin-user>admin</admin-user>
        <admin-password>hackme</admin-password>
        <source-password>StreamPassPass1</source-password>
        <relay-password>RelayPassPass1</relay-password>
    </authentication>
    <listen-socket>
        <port>8000</port>
        <bind-address>127.0.0.1</bind-address>
    </listen-socket>
    <mount type="normal">
        <mount-name>/stream</mount-name>
        <max-listeners>200</max-listeners>
        <stream-name>Our Radio Live</stream-name>
        <bitrate>128</bitrate>
    </mount>
    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <loglevel>3</loglevel>
    </logging>
</icecast>

Three details matter when chasing a 401. First, the <source-password> is the only password your source client must send. Second, the <mount-name> must start with a slash, or Icecast will silently ignore it. Third, loglevel 3 or 4 is required to see authentication failures in the log.

Icecast Service Restart vs Reload: Why It Matters

This is the single biggest source of wasted hours in the Icecast community. Editing icecast.xml and then sending a SIGHUP or running systemctl reload icecast2 does not re-read the authentication block on every Icecast version. Listeners and source clients keep using the password that was loaded at startup.

The safe, universal command is a full restart. On Debian/Ubuntu servers: sudo systemctl restart icecast2. On CentOS: sudo systemctl restart icecast. On Windows: stop the Icecast tray icon and start it again. On FreeBSD in a jail: service icecast restart.

I recommend treating every icecast.xml save as a restart event, even if you only changed a stream-name. It costs two seconds of downtime and eliminates an entire category of “but I changed the password and it still fails” tickets.

Reading the Icecast error.log and access.log

The error.log is your ground truth. When a 401 lands, Icecast writes a line that names the offending client IP and the mount it tried to reach. A normal failing line looks like this:

[2026-08-12  14:03:21] WARN source/source_main Client read failed (Resource temporarily unavailable) for mount /stream
[2026-08-12  14:03:21] WARN source/source_main Bad password from client (192.0.2.45)

If you see Bad password from client, the credentials are wrong; you need to fix the source client, not the server. If you see Mountpoint /stream does not exist, your mount-name is mistyped in icecast.xml. If you see Connection count for mountpoint exceeded, you have hit <max-listeners> and need to raise it.

The access.log shows successful PUTs from source clients. A healthy mountpoint shows a PUT /stream HTTP/1.0 line followed by 200 OK. If your log only shows 401s and no 200s, the source client never authenticated and listeners will keep hearing silence.

Set <logsize> to something like 50000 and <logarchive> to true so the logs rotate automatically and you can dig back in time when a station owner emails you a month later about an old outage.

Icecast Mountpoint Setup Best Practices for 2026

After hundreds of deployments, the configuration below is what I run on every new Icecast server I spin up. It cuts the 401 ticket rate to near zero.

• Use a dedicated source-password per mountpoint by giving each <mount> its own <source-password> override. This stops one DJ from leaking credentials and knocking others offline.
• Keep admin-password and source-password completely different. The admin-password is for the web UI only.
• Rotate passwords every 90 days and document them in a team password vault, not in chat threads.
• Wrap icecast.xml in version control so every change is auditable and rollback is one command.
• Set <hostname> and <location> so listeners see real metadata on the status page.
• Limit <max-listeners> and <sources> to what the box can actually handle. A 1 vCPU server should rarely exceed 200 listeners on a 128 kbps stream.
• Enable <burst-size> if your listeners complain about buffering on mobile data.
• Keep Icecast up to date. The stalled-auth libcurl bug was patched in the official branch back in 2024; if you are running an older fork, upgrade.

Treat the configuration file as code: review it, version it, and test every change on a staging server before pushing to production.

Frequently Asked Questions

Conclusion

An Icecast mountpoint that returns 401 unauthorized is not a network problem; it is an authentication problem, and authentication problems always have a paper trail. Open icecast.xml, confirm the source-password matches what your source client sends, validate the XML with xmllint, and run a full Icecast service restart.

If you take one thing away from this guide, take this: reload is not enough, restart every time. That single habit fixes more broken Icecast installs than any other technique we have tested. Bookmark this page, share it with your broadcast team, and the next time the stream drops to 401, you will be back on air in under five minutes.