Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80

[rahilarious]

Latest docker image is faulty it seems. To be specific sha256:2b298302ab50184cf99294ef3ae6a3c49c13081162e9a1d067a872e9c75b3e55
docker run -p 8080:80 -p 8443:443 linkstackorg/linkstack:latest

• ------------------------------------------------------------------ +
  | LINKSTACK v4.8.4 |
• ------------------------------------------------------------------ +
  | Updating Configuration: Apache Base (/etc/apache2/httpd.conf) |
  | Updating Configuration: Apache SSL (/etc/apache2/conf.d/ssl.conf) |
  | Updating Configuration: PHP (/etc/php83/40-custom.ini) |
  | Setting PHP Configuration: |
  | upload_max_filesize = 8M |
  | memory_limit = 256M |
  | date.timezone = UTC |
  | Updating Configuration: Complete |
  | ------------------------------------------------------------------ |
  | Running Apache |
• ------------------------------------------------------------------ +

(13)Permission denied: AH00072: make_sock: could not bind to address [::]:80
(13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs

whereas old image works
docker run -p 8080:80 -p 8443:443 linkstackorg/linkstack@sha256:3b50576886035436fdfef627d1cc3200cfd2ad23a098ab2554afc3b40e1c5d8f

[lastsamurai26]

docker run -p 8080:80 -p 8443:443 linkstackorg/linkstack:latest

i don't know why ? but i can't reproduce it

did you run this via sudo ?

[rahilarious]

i don't know why ? but i can't reproduce it

I was able to reproduce this on Fedora 43 (permissive selinux) and Gentoo (no selinux/apparmor) with Podman 5.7.0. Adding --privileged wasn't of help either.

did you run this via sudo ?

yes

EDIT:
Ok found the real problem.
See

linkstack-docker/Dockerfile

Line 59 in 0e6b851

USER apache:apache

&

linkstack-docker/configs/apache2/httpd.conf

Line 62 in 0e6b851

Listen 80

both are conflicting.
User apache can't run httpd daemon with privileged ports (<1024) which is 80 in this case.

So solution is to either remove USER apache:apache line or change default port to 8080 (>1024) in httpd.conf & 8443 in ssl.conf. I prefer former as we're only echo-ing stuff in docker-entrypoint.sh so it is fine, also that is the standard way for docker images.

Temporary workarounds:
Add --user root. So final command docker run -p 8080:80 -p 8443:443 --user root linkstackorg/linkstack:latest (I did this)
or
Build new image FROM linkstackorg/linkstack:latest & edit /etc/apache2/httpd.conf /etc/apache2/conf.d/ssl.conf to edit default port to 8080 & 8443.

[lastsamurai26]

That's strange, why can't I understand that?

[rahilarious]

That's strange, why can't I understand that?

I tried my best to be clear & pointed out possible solutions as well. Feel free to elaborate on what you don't understand.

[Thomasjbj]

I can confirm that I am experiencing the same issue.

Environment:

Synology DiskStation

Docker / Container Manager

LinkStack v4.8.4 (linkstackorg/linkstack:latest)

Apache fails to start with:
AH00072: make_sock: could not bind to address 0.0.0.0:80
followed by
no listening sockets available, shutting down / AH00015: Unable to open logs.

I currently don’t know how to apply the suggested fixes on a Synology DiskStation, but the problem is fully reproducible there as well.

[bigboss-trades]

I can confirm I have this problem too. I use linkstack 4.8.4 on a synology diskstation, through a docker container.

by adding
user: root
to my yaml file under the linkstack service, I was able to get it to work.

[Velgnim]

Hello,

Don't you have a docker-compose.yml?
I'm hesitant about having to use the root user...

[sn0w486]

Hello, i get the same issue on Synology NAS

[Daniii438]

Same issue here as well using synology, I am hesistant to run it as root, so changing the default port to 8080 seems reasonable

[sn0w486]

Same issue here as well using synology, I am hesistant to run it as root, so changing the default port to 8080 seems reasonable

Okay, where i_m able to change the port? do i need to ssh into the nas?

[Daniii438]

@rahilarious posted how to fix it, just need to build a custom image or hope it'll get fixed

[sn0w486]

@rahilarious posted how to fix it, just need to build a custom image or hope it'll get fixed

yes but i cant enter the container because it instantly sstops after those logs appear.

[JulianPrieber]

The issue:

When we set up our permissions, we give the least privileges we have to give. If we try to assign system-reserved ports below 1024 with insufficient permissions, we get errored out here.

Possible solution:

I need to look into other solutions to this problem. This should be widely documented.

The proper solution to this issue should be to use the NET_BIND_SERVICE capability.

docker run -p 80:80 -p 443:443 --cap-add=NET_BIND_SERVICE linkstackorg/linkstack:latest

I have not been able to test this solution. If someone would like to reply back if this works or not.

---

@lastsamurai26 I thought we had this sorted?

Could you please bring me up to speed with your last few changes? I don't see changes in the permission setup, so could this be the Alpine upgrade?

So what is happening appears to be a common issue, but I can't really tell you why exactly.

However, this does appear not to be entirely an us issue. This is unrelated to the directory mount issue we have discussed before.

@rahilarious did point this out correctly in #154 (comment).

However, we want to avoid using root permissions for this. The most secure option would be to change the ports internally to something above 1024, but I think we may want to keep that as a precaution for when we switch the production image to the v2 engine image on Caddy.

Here is some context

The Linux kernel reserves ports below 1024 for system use. In a bare-metal environment, we would expect to assign these ports only as root. So I can't tell you why this happens only now, but we run our server after the setup explicitly as the Apache user.
When we start the container with our script when deploying, we fail at this step.

This is by design. After creation, nothing from inside our application should be able to touch the system.

I cannot explain, however, why this works in some cases when it should be the same everywhere. My understanding was that we switch from root to Apache after setting up the files; that's why we ensure we have the correct permissions set for /htdocs at creation.

We could allow changing the internal port as well with variables, that might be the best compromise.

We can account for this restriction in the Docker Compose file.

services:
linkstack:
  build: .
  cap_add:
    - NET_BIND_SERVICE
  ports:
    - "80:80"
    - "443:443"

---