starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

`[SERVICES] INFO: Failed to start nscd` caused by custom UUID/GUID without perimissions to start services #3320

New issue

Open

opened 2026-02-28 03:25:38 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-28 03:25:38 -05:00

Owner

Originally created by @RavHilton on GitHub (May 7, 2024).

no response

🛡️ Security Policy

I agree to have read this project Security Policy

Description

In "Settings":
Enable NSCD (Name Service Cache Daemon) for caching all DNS requests: Enabled

In Logs:

[SETTINGS] INFO: Chrome executable is changed. Resetting Chrome...
[SERVICES] INFO: Starting nscd
[SERVICES] INFO: Failed to start nscd

If I shell into the Docker container, I can manually start nscd with no issues.

👟 Reproduction steps

Current Docker container, using Compose, it does this all the time when "Enable NSCD" is set - disabling it in Settings obviously results in the container starting without this error message.

👀 Expected behavior

NSCD would start when enabled

😓 Actual Behavior

[SETTINGS] INFO: Chrome executable is changed. Resetting Chrome...
[SERVICES] INFO: Starting nscd
[SERVICES] INFO: Failed to start nscd

🐻 Uptime-Kuma Version

1.23.13

💻 Operating System and Arch

Docker

🌐 Browser

Opera, Chrome, Edge, Firefox

🖥️ Deployment Environment

Host: Synology DS1823xs+
Environment: Container Manager
Management: Portainer CE 2.19.5

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    environment:
      PUID: 1026
      PGID: 100
      TZ: Australia/Brisbane
    volumes:
      - /volume1/docker/uptime-kuma:/app/data
    networks:
      default:
        ipv4_address: 10.24.20.71
#        ports:
#          - 3001:3001

networks:
  default:
    name: macvlan-br0
    external: true

📝 Relevant log output

[SETTINGS] INFO: Chrome executable is changed. Resetting Chrome...
[SERVICES] INFO: Starting nscd
[SERVICES] INFO: Failed to start nscd

Originally created by @RavHilton on GitHub (May 7, 2024). ### 📑 I have found these related issues/pull requests no response ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description In "Settings": Enable NSCD (Name Service Cache Daemon) for caching all DNS requests: Enabled In Logs: ```logs [SETTINGS] INFO: Chrome executable is changed. Resetting Chrome... [SERVICES] INFO: Starting nscd [SERVICES] INFO: Failed to start nscd ``` If I shell into the Docker container, I can manually start nscd with no issues. ### 👟 Reproduction steps Current Docker container, using Compose, it does this all the time when "Enable NSCD" is set - disabling it in Settings obviously results in the container starting without this error message. ### 👀 Expected behavior NSCD would start when enabled ### 😓 Actual Behavior ``` [SETTINGS] INFO: Chrome executable is changed. Resetting Chrome... [SERVICES] INFO: Starting nscd [SERVICES] INFO: Failed to start nscd ``` ### 🐻 Uptime-Kuma Version 1.23.13 ### 💻 Operating System and Arch Docker ### 🌐 Browser Opera, Chrome, Edge, Firefox ### 🖥️ Deployment Environment Host: Synology DS1823xs+ Environment: Container Manager Management: Portainer CE 2.19.5 ```yaml services: uptime-kuma: image: louislam/uptime-kuma:1 container_name: uptime-kuma restart: unless-stopped environment: PUID: 1026 PGID: 100 TZ: Australia/Brisbane volumes: - /volume1/docker/uptime-kuma:/app/data networks: default: ipv4_address: 10.24.20.71 # ports: # - 3001:3001 networks: default: name: macvlan-br0 external: true ``` ### 📝 Relevant log output ```shell [SETTINGS] INFO: Chrome executable is changed. Resetting Chrome... [SERVICES] INFO: Starting nscd [SERVICES] INFO: Failed to start nscd ```

deekerman added the

bug

A:deployment

labels

2026-02-28 03:25:38 -05:00

deekerman commented

2026-02-28 03:25:40 -05:00

Author

Owner

@chakflying commented on GitHub (May 7, 2024):

I'm guessing setting the user ID is causing it to not have the correct permissions to start the service.

@chakflying commented on GitHub (May 7, 2024): I'm guessing setting the user ID is causing it to not have the correct permissions to start the service.

deekerman commented

2026-02-28 03:25:42 -05:00

Author

Owner

@RavHilton commented on GitHub (May 7, 2024):

That is the UID/GID that Docker runs under, and 29 other containers run under without any issues. However when I comment these out Uptime Kuma can load nscd when it boots.

Hhmmm, does that mean I shouldn't set the PUID/PGID for Uptime Kuma even though it works fine for a heap of other containers, or is there something either a) needing changed in the official Uptime Kuma container, or b) I've missed in the docs/config?

@RavHilton commented on GitHub (May 7, 2024): That is the UID/GID that Docker runs under, and 29 other containers run under without any issues. However when I comment these out Uptime Kuma can load nscd when it boots. Hhmmm, does that mean I *shouldn't* set the PUID/PGID for Uptime Kuma even though it works fine for a heap of other containers, or is there something either a) needing changed in the official Uptime Kuma container, or b) I've missed in the docs/config?

deekerman commented

2026-02-28 03:25:42 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 8, 2024):

does that mean I shouldn't set the PUID/PGID for Uptime Kuma

Nscd is not configured to support changing the PUID/PGID to an unpriviliged user.

needing changed in [...] Uptime Kuma

This subsystem not properly using the environment variable is a bug. (PRs welcome)

Note

The image currently only fully supports root-level-users (see #4500 for further details).
Could be documented better as with most edge case configurations.

@CommanderStorm commented on GitHub (May 8, 2024): > does that mean I shouldn't set the PUID/PGID for Uptime Kuma Nscd is not configured to support changing the PUID/PGID to an unpriviliged user. > needing changed in [...] Uptime Kuma This subsystem not properly using the environment variable is a bug. (PRs welcome) > [!NOTE] > The image currently only fully supports `root`-level-users (see #4500 for further details). > Could be documented better as with most edge case configurations.

deekerman commented

2026-02-28 03:25:42 -05:00

Author

Owner

@DrZacharySmith commented on GitHub (Mar 8, 2025):

Im running in Unraid and have set to root and still get the same error? Is this critical to the performane of the container and it core function?

@DrZacharySmith commented on GitHub (Mar 8, 2025): Im running in Unraid and have set to root and still get the same error? Is this critical to the performane of the container and it core function?

deekerman commented

2026-02-28 03:25:42 -05:00

Author

Owner

@ph0b0s101 commented on GitHub (Mar 15, 2025):

Im running in Unraid and have set to root and still get the same error? Is this critical to the performane of the container and it core function?

I am second this. I am curious as well.

@ph0b0s101 commented on GitHub (Mar 15, 2025): > Im running in Unraid and have set to root and still get the same error? Is this critical to the performane of the container and it core function? I am second this. I am curious as well.

deekerman commented

2026-02-28 03:25:42 -05:00

Author

Owner

@pfaelzerchen commented on GitHub (Mar 28, 2025):

I am currently testing v2-beta as well, running on 2.0.0-beta-slim-rootless.1. This image should be able to run rootless, but nscd won't start here as well:

2025-03-28T20:30:44+01:00 [SERVICES] INFO: Starting nscd
2025-03-28T20:30:44+01:00 [SERVICES] INFO: Failed to start nscd

I am running on k3s 1.31.6 and been using the following securityContext:

          securityContext:
            runAsUser: 1000
            runAsGroup: 1000
            runAsNonRoot: true
            privileged: false
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
            seccompProfile:
              type: RuntimeDefault

1000 should be the expected user, assuming from what the docs tell me, right?

@pfaelzerchen commented on GitHub (Mar 28, 2025): I am currently testing v2-beta as well, running on `2.0.0-beta-slim-rootless.1`. This image should be able to run rootless, but nscd won't start here as well: ``` 2025-03-28T20:30:44+01:00 [SERVICES] INFO: Starting nscd 2025-03-28T20:30:44+01:00 [SERVICES] INFO: Failed to start nscd ``` I am running on k3s 1.31.6 and been using the following securityContext: ```yaml securityContext: runAsUser: 1000 runAsGroup: 1000 runAsNonRoot: true privileged: false allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALL seccompProfile: type: RuntimeDefault ``` 1000 should be the expected user, assuming from what the docs tell me, right?

deekerman commented

2026-02-28 03:25:42 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Mar 28, 2025):

Is this critical to the performane of the container and it core function?

Depends what you are trying to do.
It caches your dns requests as node by default does not do that:

If your dns server can handle getting poked for every heartbeat, you are fine.
if your monitor does not require this, you are fine

@CommanderStorm commented on GitHub (Mar 28, 2025): > Is this critical to the performane of the container and it core function? Depends what you are trying to do. It caches your dns requests as node by default does not do that: - If your dns server can handle getting poked for every heartbeat, you are fine. - if your monitor does not require this, you are fine