Homepage Error - Connecting to localhost:3000 ([::1]:3000) wget: can't connect to remote host: Connection refused

[SvartrShell]

Description

I have been running homepage for over a year, and today after a server reboot am getting an error where homepage is not available - docker logs homepage is empty - portainer shows the error Connecting to localhost:3000 ([::1]:3000) wget: can't connect to remote host: Connection refused

I am running this via docker compose - i will put my config below. its worth noting, if i use docker run, with same ports, same config and same UID and GID, the container runs - it very much appears to be an issue with something inside the container attaching to port 3000 when ran via compose

homepage version

latest

Installation method

Docker

Configuration

homepage:
    container_name: homepage
    image: ghcr.io/gethomepage/homepage:latest
    restart: always
    environment:
      PUID: 1000
      PGID: 1000
    ports:
      - '3300:3000'
    volumes:
      - '${BINDMOUNTDIR}/homepage:/app/config'
      - '${DOCKERSOCK}:${DOCKERSOCK}'

Docker run command (that works)
docker run -p 3300:3000 -v /mnt/docker/bindmounts/homepage:/app/config -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/gethomepage/homepage:latest

### Container Logs

Docker logs shows nothing - portainer has this error

Connecting to localhost:3000 ([::1]:3000) wget: can't connect to remote host: Connection refused

### Browser Logs

_No response_

### Troubleshooting

Attempted to deploy fresh instance via compose with no config and no UID/GID specified - same issue 

[shamoon]

The app is not suddenly broken so something must have changed. Did you change the ipv6 settings on your host?

[SvartrShell]

Nope, all networking is the same. It turned out to be permissions as omitting the uid and gid from the compose file solved it. Checked all system logs, no changes been made to it for months, and defo nothing to the compose file or file system at all, I have been using it daily since 2023 so I'm very aware of when its not available.... Weird that suddenly perms are broken

…

-------- Original Message --------

On 20/02/2025 14:55, shamoon wrote: The app is not suddenly broken so something must have changed. Did you change the ipv6 settings on your host? — Reply to this email directly, [view it on GitHub](#4805 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AZVTCEHCMA2BSU7SI4UFAPT2QXUFNAVCNFSM6AAAAABXQFNBYWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRWGQ2TMNQ). You are receiving this because you authored the thread.Message ID: ***@***.***>

[djtlg]

I can confirm. I am a new homepage user but advanced user. The container fails the start when PUID is configured.

Even when I remove the volumes the container still failing to start with the same error which leads me to think something wrong with the docker image

I realize after leaving the container in error state it became green eventually but the UI has an error "Application error: a client-side exception has occurred (see the browser console for more information)."

This is the logs of the container

Listening on port 3000

Error: ENOENT: no such file or directory, mkdir '/app/config'
    at mkdirSync (node:fs:1391:3)
    at checkAndCopyConfig (/app/.next/server/chunks/1227.js:42:50)
    at init (/app/.next/server/pages/index.js:5072:76)
    at createLogger (/app/.next/server/pages/index.js:5116:5)
    at /app/.next/server/pages/index.js:4073:81 {
  errno: -2,
  syscall: 'mkdir',
  code: 'ENOENT',
  path: '/app/config'
}

The user that is running the homepage is the owner of the folder I am trying to mount as well

[shamoon]

I have no idea

[djtlg]

I see. I guess currently this image cant run as non-root :(

[gbcreation]

I meet this problem too and found this issue regarding a change in Docker network internals.

Since Docker V26+, localhost seems to be resolved to ::1 by default.
Suggested fixes are:

• If the healthcheck only works on IPv4, it would probably be best to change the healthcheck URL to [...] use 127.0.0.1
• Alternatively, you can disable IPv6 in the container so that it never has a ::1 (or an /etc/hosts entry for ::1). To do that, use --sysctl=net.ipv6.conf.all.disable_ipv6=1 in the docker run command. Or, the equivalent sysctls option in a compose file.

I tested the second suggestion with:

docker run -p 3000:3000 -v /path/to/config:/app/config -v /var/run/docker.sock:/var/run/docker.sock -e PUID=1000 -e PGID=1000 --sysctl=net.ipv6.conf.all.disable_ipv6=1 ghcr.io/gethomepage/homepage:latest

But Portainer reports this: Connecting to localhost:3000 (127.0.0.1:3000) wget: can't connect to remote host (127.0.0.1): Connection refused

So using 127.0.0.1 does not help here.

Actually, even when deactivating the healthcheck with the --no-healthcheck option like this:

docker run -p 3000:3000 -v /path/to/config:/app/config -v /var/run/docker.sock:/var/run/docker.sock -e PUID=1000 -e PGID=1000 --no-healthcheck ghcr.io/gethomepage/homepage:latest

Homepage does not run.

[shamoon]

Hmm, I suspect there are more than one thing being discussed here.

With PUID/GUID set there seem to be permissions issues with creating the config directory (which homepage does when one doesnt exist or cant read it). That sounds like a permissions issue on the host.

As for the healthcheck with ipv6, I cant reproduce anything on my docker Mac:

If youre curious:

• There is a branch (and docker image) that allows disabling ipv6 for the proxy (i.e. api calls) by setting the appropriate ENV: feature-disable-ipv6
• There is a branch (and docker image) that changes the healthcheck to use ipv4: feature-ipv4healthcheck

Will be curious about peoples experiences in trying those out, if willing

[gbcreation]

Thank you very much for taking time to answer and for providing new Docker images for testing. Really appreciated 🙂

I tested images with the following tags with a non-root user:

• feature-ipv4healthcheck
• feature-disable-ipv6

None of them works when the user is non-root. So you're right, the problem is not related to IPv4/IPv6 addresses.

I continued my investigations, and I've noticed that there are a lot of disk accesses until I kill the container. Using the iotop -o, I saw that the following command seems to run infinitely:

1393528 be/4 root       16.23 K/s   17.18 K/s chown -R 1019:1020 /app

It's the command run at line 18 of docker-entrypoint.sh.

I came to understand that chown is very very slow on my system. And that's due to the usage of the Docker overlay2 driver over ZFS (fyi, ZFS supports overlay2 since version 2.2.0+, so there is no need to use specifically the Docker zfs driver even for zfs filesystem. It allows to avoid the zfs snapshot pollution created by Docker). Problem is: all file operations are synced in real-time by zfs, what is very slow when chowning all files of the Homepage app. However, with patience, once all files have been chowned, Homepage launches and run as a non-root user 🎉

A possible solution to make file operations faster with overlay2 on zfs is to disable the sync option for the /var/lib/docker/ dataset (with the risk of data loss in case of power outage):

zfs set sync=disabled /var/lib/docker

or to explicitly use the Docker zfs driver instead of overlay2 on zfs (and face the snapshot pollution again 🤷‍♂️ ).

Hope it can be helpful for people using overlay2 on zfs like me.
Anyway, all seems good on the Homepage app side 🙂

[github-actions[bot]]

This discussion has been automatically closed because it was marked as answered. See our contributing guidelines for more details.

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. See our contributing guidelines for more details.