# Native install on host with rootless docker doesn't resolve cgroup names

**URL:** <https://community.netdata.cloud/t/native-install-on-host-with-rootless-docker-doesnt-resolve-cgroup-names/7893>\
**Category:** Help\
**Created:** [January 20, 2026, 10:47am UTC](https://community.netdata.cloud/t/native-install-on-host-with-rootless-docker-doesnt-resolve-cgroup-names/7893 "2026-01-20T10:47:05Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![FalkE](https://avatars.discourse-cdn.com/v4/letter/f/bbce88/32.png) [@FalkE](https://community.netdata.cloud/u/FalkE)\
**Post date:** [January 20, 2026, 10:47am UTC](https://community.netdata.cloud/t/native-install-on-host-with-rootless-docker-doesnt-resolve-cgroup-names/7893/1 "2026-01-20T10:47:06Z")

</div>

**Suggested template:**

## Problem/Question

I’m running netdata as a native service on a Ubuntu system. Netdata itself is running fine and is showing all the relevant metrics.

On the same host, I’m running multiple containers in docker-rootless. Netdata does see the cgroups created, but is not able to retrieve the name of the given cgroup. As a result, the cgroups are shown with their ID only.

The output below shows the structure:

```auto
root@host:~# id docker
uid=1001(docker) gid=988(docker) groups=988(docker)

root@host:~# id netdata
uid=105(netdata) gid=107(netdata) groups=107(netdata),4(adm),13(proxy),988(docker)

root@host:~# tree -d /sys/fs/cgroup
/sys/fs/cgroup
├── dev-hugepages.mount
├── dev-mqueue.mount
├── init.scope
├── proc-sys-fs-binfmt_misc.mount
├── sys-fs-fuse-connections.mount
├── sys-kernel-config.mount
├── sys-kernel-debug.mount
├── sys-kernel-tracing.mount
├── system.slice
│ ├── boot.mount
│ ├── containerd.service
│ ├── cron.service
│ ├── dbus.service
│ ├── docker.service
│ ├── docker.socket
│ ├── fail2ban.service
│ ├── haproxy.service
│ ├── lxd-installer.socket
│ ├── ModemManager.service
│ ├── multipathd.service
│ ├── netdata.service
│ ├── networkd-dispatcher.service
│ ├── polkit.service
│ ├── prometheus-node-exporter.service
│ ├── qemu-guest-agent.service
│ ├── rsyslog.service
│ ├── snapd.socket
│ ├── ssh.service
│ ├── ssh.socket
│ ├── systemd-journald.service
│ ├── systemd-logind.service
│ ├── systemd-networkd.service
│ ├── systemd-resolved.service
│ ├── systemd-timesyncd.service
│ ├── systemd-udevd.service
│ │ └── udev
│ ├── system-getty.slice
│ │ └── getty@tty1.service
│ ├── system-modprobe.slice
│ ├── system-systemd\x2dfsck.slice
│ ├── system-systemd\x2djournald.slice
│ │ └── systemd-journald@netdata.service
│ ├── system-systemd\x2djournald\x2dvarlink.slice
│ ├── tailscaled.service
│ ├── udisks2.service
│ ├── unattended-upgrades.service
│ └── upower.service
└── user.slice
    ├── user-1000.slice
    │ ├── session-93.scope
    │ └── user@1000.service
    │ ├── app.slice
    │ │ ├── dbus.socket
    │ │ └── gpg-agent-ssh.socket
    │ └── init.scope
    └── user-1001.slice
        └── user@1001.service
            ├── app.slice
            │ ├── dbus.socket
            │ ├── docker.service
            │ └── gpg-agent-ssh.socket
            ├── init.scope
            ├── session.slice
            │ └── dbus.service
            └── user.slice
                ├── docker-4a7929960ce5ea9edb19ddffa785242cc0f7c9ad5c681976b7e4e8edf12de71c.scope
                ├── docker-5d0c1b3942801899b30b4f697575e47cc998c4571782e2199fa2a9f7201048da.scope
                ├── docker-65d80aed510bae2e4bcfcac8c46e74a067b380caa593328e13421a19bbdf119b.scope
                ├── docker-6fd9ff6ae26c3513af664ae40624a260e0ee11758c0c0fcac6c103beaf116806.scope
                ├── docker-c78b493bf038d30ee6affb56452d19e67411e9d846a24d933028726773510d7c.scope
                ├── docker-d6e0b302d71be92435a21d5a8f829a7c13a2060be248e04c99f8b159bf30c13c.scope
                └── docker-f3cb9da0ce37a41cb813031ed42cd509f0b1f1b0cf1e8dfc63b5160d02c41d3b.scope

```

## Relevant docs you followed/actions you took to solve the issue

## Environment/Browser/Agent’s version etc

- Ubuntu 24.04.3 LTS
- netdata v2.8.0-243-nightly

## What I expected to happen

resolved cgroup names

---

<div class="post-metadata">

**Author:** ![kanelatechnical](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/kanelatechnical/32/4699_2.png) [@kanelatechnical](https://community.netdata.cloud/u/kanelatechnical)\
**Post date:** [January 20, 2026, 11:58am UTC](https://community.netdata.cloud/t/native-install-on-host-with-rootless-docker-doesnt-resolve-cgroup-names/7893/2 "2026-01-20T11:58:50Z")

</div>

The rootless Docker cgroup naming issue occurs because Netdata’s `cgroup-name.sh` script cannot access the Docker socket to query container names.

I’ll verify the documentation and code to provide the most accurate solution for the rootless Docker cgroup naming issue.

The Easiest Fix:

Configure the `DOCKER_HOST` environment variable for Netdata to point to the rootless Docker socket.

**Edit `/etc/netdata/netdata.conf`:**

```ini
[environment variables]
    DOCKER_HOST = unix:///run/user/1001/docker.sock

```

**Then restart Netdata:**

```bash
sudo systemctl restart netdata

```

The `cgroup-name.sh` script ([CODE public cgroup-name.sh.in](https://github.com/netdata/netdata/blob/master/src/collectors/cgroups.plugin/cgroup-name.sh.in)) queries Docker to get container names. By default, it looks for the standard Docker socket at `/var/run/docker.sock`, which doesn’t exist for rootless Docker. Setting `DOCKER_HOST` tells the script where to find the rootless socket.

After restarting Netdata, your containers should appear with their proper names instead of just cgroup IDs in the dashboard.

---

<div class="post-metadata">

**Author:** ![FalkE](https://avatars.discourse-cdn.com/v4/letter/f/bbce88/32.png) [@FalkE](https://community.netdata.cloud/u/FalkE)\
**Post date:** [January 20, 2026, 1:56pm UTC](https://community.netdata.cloud/t/native-install-on-host-with-rootless-docker-doesnt-resolve-cgroup-names/7893/3 "2026-01-20T13:56:15Z")

</div>

Hi @kanelatechnical ,

thank’s for the quick response!

I’ve tested your solution but couldn’t get it to work just yet. I’ve seen a lot of errors in `systemctl status netdata.service` like this:

```auto
Jan 20 13:10:01 host spawn-plugins[2083975]: SPAWN SERVER: child with pid 2085643 (request 34) exited with exit code 2: /usr/libexec/netdata/plugins.d/cgroup-name.sh /user.slice/user-1001.slice/user@1001.service/user.slice/docker-6fd9ff6ae26c3513af664ae40624a260e0ee11758c0c0fcac6c103beaf116806.scope user.slice/user-1001.slice/user_1001.service/user.slice/docker-6fd9ff6ae26c3513af664ae40624a260e0ee11758c0c0fcac6c103beaf116806.scope

```

It looks like the environment variable in the `netdata.conf` is not properly configured.

To get it working, I needed to:

1. fix the permissions on `/run/user/` and `/run/user//docker.sock`

2. setting `DOCKER_HOST` using a systemd-dropin:

The last challange now is, to get the permissions fixed permanently…. Do you have any idea on that?

---

<div class="post-metadata">

**Author:** ![kanelatechnical](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/kanelatechnical/32/4699_2.png) [@kanelatechnical](https://community.netdata.cloud/u/kanelatechnical)\
**Post date:** [January 20, 2026, 2:29pm UTC](https://community.netdata.cloud/t/native-install-on-host-with-rootless-docker-doesnt-resolve-cgroup-names/7893/4 "2026-01-20T14:29:20Z")

</div>

Hey @FalkE,

Your systemd dropin approach is correct:

```auto
# /etc/systemd/system/netdata.service.d/docker-socket.conf
[Service]
Environment="DOCKER_HOST=unix:///run/user/1001/docker.sock"

```

This is the proper way to configure environment variables for Netdata services. The errors you saw were because the cgroup-name.sh script couldn’t access the Docker socket at the default path /var/run/docker.sock.

**For persistent permissions on /run/user/1001/docker.sock, use systemd-tmpfiles:**

```auto
# Create /etc/tmpfiles.d/docker-netdata.conf
cat > /etc/tmpfiles.d/docker-netdata.conf << 'EOF'
d /run/user/1001 0750 root docker -
EOF

# Apply immediately
sudo systemd-tmpfiles --create

```

This ensures proper ownership and permissions persist across reboots.

After applying the tmpfiles configuration and rebooting, your containers should appear with their proper names instead of just cgroup IDs.

Let me know if you need any further assistance.
