Error: connect EACCES /var/run/docker.sock

[Jaxel]

Description

Since the recent update a few days ago, I have started getting this error. I was not getting the error on previous versions:

[2026-09-13T14:48:17.121Z] �[31merror�[39m: <service-helpers> Error getting services from Docker server '*******': Error: connect EACCES /var/run/docker.sock
  at ignore-listed frames {
    errno: -13,
    code: 'EACCES',
    syscall: 'connect',
    address: '/var/run/docker.sock'
  }
[2026-09-13T14:48:18.017Z] �[31merror�[39m: <dockerStatuses> Error: connect EACCES /var/run/docker.sock
    at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1638:16)
    at PipeConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17)

I have changed nothing except updated to v2.3.0. Downgrading to v2.2.0 has not fixed the issue though; it simply changes the text on services from "Error" to "Unknown".

I am on a Synology, running Docker (Container Manager).

services:
  homepage:
    container_name: homepage
    image: ghcr.io/gethomepage/homepage:latest
    restart: unless-stopped
    network_mode: bridge
    ports:
      - 3000:3000
    environment:
      - TZ=America/New_York
      - PUID=1028
      - PGID=100
      - HOMEPAGE_ALLOWED_HOSTS=*****,*****
    volumes:
      - ./config:/app/config
      - ./backgrounds:/app/public/backgrounds
      - ./icons:/app/public/icons
      - /var/run/docker.sock:/var/run/docker.sock

homepage version

2.3.0

Installation method

Docker

[dosubot[bot]]

Hi @Jaxel! I'm Dosu and I'm helping the homepage team.

Nothing in v2.3.0 or v2.2.0 changed how Homepage connects to /var/run/docker.sock — the Docker connection code and the docker-entrypoint.sh privilege-drop logic haven't been touched recently [1] [2]. What did change in v2.3.0 is the status/stats backend: the per-service /api/docker/status/[...service] and /api/docker/stats/[...service] endpoints were replaced with bulk /api/docker/statuses and /api/docker/stats endpoints that query the Docker API once for all containers . That's unrelated to socket permissions, but it does mean every dashboard load now talks to the socket, so an existing permission problem surfaces more visibly than before.

On Synology, the usual cause of EACCES here is the socket's owning group or mode changing after a Container Manager/DSM update, so the container's runtime user loses access even though your compose file is unchanged. Worth checking two things on the host: run ls -l /var/run/docker.sock and confirm it hasn't become root-only 0600 or switched groups, and confirm Container Manager still uses that path — some DSM versions relocate the socket (for example to /var/packages/ContainerManager/var/docker.sock), leaving a stale or inaccessible file behind. The fact that downgrading to v2.2.0 only changed the label from "Error" to "Unknown" also points away from a Homepage regression.

Could you share the output of ls -l /var/run/docker.sock from the Synology host, and let me know whether other socket-using containers like Portainer or Watchtower are failing too? That would tell us if this is host-wide or specific to Homepage.

Written by @dosu, approved by shamoon

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[dosubot[bot]]

That rules out network mode. The next thing I'd check is your docker.yaml in the config folder — does it exist with an entry pointing at /var/run/docker.sock, or are you relying on the default with no server configured? Homepage reads docker.yaml on every request and looks up a specific entry when a service or widget references a server name; if no server is specified anywhere, it falls back to connecting directly to /var/run/docker.sock with no other config [1]. A typo'd or oddly quoted socket: path there is one of the few ways a permission error would show up consistently for Homepage while Uptime Kuma, which never reads that file, works fine on the identical mount.

It's also worth recreating the container with a fresh config folder (just rename the current one temporarily). If EACCES still appears with the default skeleton config, that points at something environmental — mount propagation, or a per-image AppArmor/seccomp profile from DSM — rather than a bad docker.yaml entry.

Can you share your docker.yaml with anything sensitive redacted?

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Jaxel]

@dosu

syn-ds1520p:
    socket: /var/run/docker.sock

[dosubot[bot]]

Thanks — that config is valid and points at the same socket path you mounted, so docker.yaml isn't the problem. It does mean every discovery pass, service, and widget referencing syn-ds1520p opens a fresh dockerode connection to /var/run/docker.sock on each request [1] [2], and all of them hit the same EACCES.

That clears your compose file (root user, correct mount), your docker.yaml, and the network mode, which matches Uptime Kuma's. What's left is how the dockerode/docker-modem client Homepage uses opens that socket compared to whatever Uptime Kuma uses. Homepage bumped dockerode from v4 to v5 in June, which pulled in updated docker-modem internals [3], so its connection handling may behave differently under Container Manager even with correct socket and container permissions.

Since v2.2.0 didn't fix it, could you try a v2.1.x image — from before that dockerode bump — and see whether the error goes away?

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Jaxel]

@dosu

Downgraded to v2.0.0, still getting the same error. Everything marked as "unknown".

[shamoon]

Please include “@dosu” in your replies.

but certainly does seem the problem is not homepage