After System Update: Port 443 bind permission denied


I updated my Ubuntu 22.04 server and then Mattermost was not working anymore.

Error: err:listen tcp :443: bind: permission denied: listen tcp :443: bind: permission denied

Then I used the command " sudo setcap CAP_NET_BIND_SERVICE=+eip /path/to/mattermost" to allow Mattermost to use low ports and it was working again.

But I want to understand why it was working before without this command. I am pretty sure Mattermost used port 443 before, so why it was not working anymore after the ubuntu system update?


After a system update, encountering a “Port 443 bind permission denied” cox customer support billing error may indicate a change in permissions or configuration. Check your firewall settings, ensure proper user privileges, and verify that no other processes are using port 443. Additionally, review recent updates or changes to pinpoint potential conflicts.

I guess you don’t know anything about Mattermost and you just want to create backlinks?

@MattServ what POSIX user owns the Mattermost directory, binary, process, etc. and what groups is it part of? It does seem pretty odd that an unprivileged user was able to grab a privileged port in any OS from the last 20 years! I’m guessing you may have had it in a group that allowed sudo and then a Linux security policy that affected that changed?

1 Like

I am using the user “mattermost” and the group “mattermost”. And it worked just fine since month.

But normally the way to go is to run mattermost on 8065 and then I use nginx to access mattermost with 80 and 443, right? But then it is strange, that Mattermost now wants to use the port 443 instead of just 8065.

Is there any problem now that I allowed Mattermost the use of port 443 with “setcap CAP_NET_BIND_SERVICE=+eip”?

AFAIK Mattermost still starts on 8065 because it won’t come with a certificate “out of the box”. Is it possible you adjusted that at some point?

There is no reason you cannot have a cert / key pair on the Mattermost instance and listen on 443, but if you’re using nginx to handle TLS I’d probably keep internal comms on 80 or 8065 just to avoid potential weirdness.

1 Like

I see that I changed the port in the system console to 443. I assume that I did this deliberately at the time and then started Mattermost as root. This did not cause any errors. And now when I tried to start Mattermost as the normal user, the error occurred.

The System Console even contains the exact command that I had found elsewhere. That’s great then. Then I probably don’t have any real disadvantages if I give Mattermost permission to use ports below 1023, do I?

That is correct, you can run Mattermost with privileges to grab ports <1024 I would definitely NOT run it as root, though… keep it running as an otherwise-unprivileged mattermost user. Solving any file permissions, SELinux issues, etc. is 100% doable.