# Claim not working on Ubuntu 24 LTS + Docker. SSL connect error. **URL:** \ **Category:** Help\ **Tags:** cloud, node-claiming\ **Created:** [May 29, 2026, 1:51pm UTC](https://community.netdata.cloud/t/claim-not-working-on-ubuntu-24-lts-docker-ssl-connect-error/7981 "2026-05-29T13:51:11Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Jacek\_Ruzyczka](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/jacek_ruzyczka/32/4901_2.png) [@Jacek\_Ruzyczka](https://community.netdata.cloud/u/Jacek_Ruzyczka)\ **Post date:** [May 29, 2026, 1:51pm UTC](https://community.netdata.cloud/t/claim-not-working-on-ubuntu-24-lts-docker-ssl-connect-error/7981/1 "2026-05-29T13:51:11Z")
I had to reinstall Ubuntu (24.04.4 LTS aarch64) on my four cluster nodes. When trying to restart Netdata in a Docker (29.5.2) container /\* I used the example command from your website \*/, I came to the point where the Netdata dashboards of all four nodes worked. What did not work, though, was claiming them in the cloud dashboard. I used the corresponding token I read from: ```auto docker exec netdata cat /var/lib/netdata/netdata_random_session_id ``` Alas, on all four nodes, I got this error message: `Request failed with error: SSL connect error` `proxy: 'env',` `insecure: false,` `public key file: '/var/lib/netdata/cloud.d/public.pem',` `trusted key file: 'none'` Yes, I do have a firewall with HTTP/HTTPS proxy sitting between the nodes and the rest of my network, but is this the cause why the SSL connection breaks? Or does it have to do with the non-standard TCP ports (19995 thru 19998, one for each node) I have to use because of the firewall? Last time, the claim worked flawlessly! I also executed this command, but no use: ```auto sudo apt-get install --reinstall ca-certificates ``` ---
**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:** [June 2, 2026, 11:13am UTC](https://community.netdata.cloud/t/claim-not-working-on-ubuntu-24-lts-docker-ssl-connect-error/7981/2 "2026-06-02T11:13:28Z")
Yes, your proxy is almost certainly the cause. The `proxy: 'env'` in the error means Netdata is looking for proxy settings in environment variables but either they’re not set inside the container, or the proxy is intercepting the SSL connection and presenting its own certificate which Netdata rejects. The cleanest fix for Docker is to pass the proxy when starting the container using the `NETDATA_CLAIM_PROXY` environment variable: ```auto docker run -d \ --name netdata \ -e NETDATA_CLAIM_TOKEN=YOUR_TOKEN \ -e NETDATA_CLAIM_ROOMS=YOUR_ROOM_IDS \ -e NETDATA_CLAIM_PROXY=http://your-proxy-host:your-proxy-port \ ... (rest of your existing flags) netdata/netdata ``` Alternatively, claim manually from inside the container: ```auto docker exec netdata netdata-claim.sh \ -token=YOUR_TOKEN \ -rooms=YOUR_ROOM_IDS \ -url=https://app.netdata.cloud \ -proxy=http://your-proxy-host:your-proxy-port ``` First, verify the proxy can reach Netdata Cloud from inside the container: ```auto docker exec netdata curl -v --proxy http://your-proxy-host:port https://app.netdata.cloud ``` If that fails, the proxy is blocking or intercepting the connection. Make sure it allows outbound connections to `app.netdata.cloud:443` and `mqtt.netdata.cloud:443`. The non-standard ports (19995-19998) won’t affect claiming. ---
**Author:** ![Jacek\_Ruzyczka](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/jacek_ruzyczka/32/4901_2.png) [@Jacek\_Ruzyczka](https://community.netdata.cloud/u/Jacek_Ruzyczka)\ **Post date:** [June 9, 2026, 3:02pm UTC](https://community.netdata.cloud/t/claim-not-working-on-ubuntu-24-lts-docker-ssl-connect-error/7981/3 "2026-06-09T15:02:24Z")
The claim from inside the container seems _not_ to work: ```auto mixtile@blade3n4:~$ docker exec netdata netdata-claim.sh \ -token=8b2aeee5-5736-49f9-8f7b-ac712c995a1a \ -rooms=jacek-ruzyczka \ -url=https://app.netdata.cloud \ -proxy=http://10.20.0.1:3128 OCI runtime exec failed: exec failed: unable to start container process: exec: "netdata-claim.sh": executable file not found in $PATH ``` Neither does recreating the container work: ```auto mixtile@blade3n4:~$ docker run -d --name netdata -e NETDATA_CLAIM_TOKEN=8b2aeee5-5736-49f9-8f7b-ac712c995a1a -e NETDATA_CLAIM_ROOMS=clusterbox -e NETDATA_CLAIM_PROXY=http://10.20.0.1:3128 netdata/netdata 4bba5467933b308abbaeddeec55fa9d750920fa71cea18143944c8809b42a09c ``` This is all I get when using the browser to load the dashboard: ```auto Failed to fetch ``` ---
**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:** [June 9, 2026, 6:20pm UTC](https://community.netdata.cloud/t/claim-not-working-on-ubuntu-24-lts-docker-ssl-connect-error/7981/4 "2026-06-09T18:20:17Z")
For the **“Failed to fetch”** , your `docker run` command is missing port mapping. Add `-p 19995:19999` (or whichever port you’re using) so the dashboard is accessible from outside the container. **`netdata-claim.sh` not found** appears because this script is deprecated in current Docker images. Claiming is now handled by the daemon itself via environment variables or `claim.conf`. **SSL connect error** appears because your proxy at `10.20.0.1:3128` is almost certainly doing SSL interception, which Netdata rejects. The fix is to create a `claim.conf` file with `insecure = yes` to accept the proxy’s certificate: ```auto [global] url = https://app.netdata.cloud token = YOUR_TOKEN rooms = YOUR_ROOM_ID proxy = http://10.20.0.1:3128 insecure = yes ``` Mount it into the container: ```auto docker run -d --name=netdata \ --pid=host \ -p 19995:19999 \ -v /path/to/claim.conf:/etc/netdata/claim.conf:ro \ -v netdataconfig:/etc/netdata \ -v netdatalib:/var/lib/netdata \ -v netdatacache:/var/cache/netdata \ -v /:/host/root:ro,rslave \ -v /etc/passwd:/host/etc/passwd:ro \ -v /etc/group:/host/etc/group:ro \ -v /proc:/host/proc:ro \ -v /sys:/host/sys:ro \ -v /etc/os-release:/host/etc/os-release:ro \ --restart unless-stopped \ --cap-add SYS_PTRACE \ --cap-add SYS_ADMIN \ --security-opt apparmor=unconfined \ netdata/netdata ``` The non-standard dashboard ports don’t affect claiming, as that’s outbound on 443 only. ---
**Author:** ![Jacek\_Ruzyczka](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/jacek_ruzyczka/32/4901_2.png) [@Jacek\_Ruzyczka](https://community.netdata.cloud/u/Jacek_Ruzyczka)\ **Post date:** [June 10, 2026, 3:29pm UTC](https://community.netdata.cloud/t/claim-not-working-on-ubuntu-24-lts-docker-ssl-connect-error/7981/5 "2026-06-10T15:29:52Z")
And the room name, which is one of the arguments, is _not_ the same as the space name (= my own name)? BTW, I can’t add a `netdata.conf` because it’s a directory _inside_ the container: ```auto mixtile@blade3n4:~$ docker run -d --name=netdata --pid=host -p 19995:19999 -v /etc/netdata/claim.conf:/etc/netdata/claim.conf:ro -v netdataconfig:/etc/netdata -v netdatalib:/var/lib/netdata -v netdatacache:/var/cache/netdata -v /:/host/root:ro,rslave -v /etc/passwd:/host/etc/passwd:ro -v /etc/group:/host/etc/group:ro -v /proc:/host/proc:ro -v /sys:/host/sys:ro -v /etc/os-release:/host/etc/os-release:ro --restart unless-stopped --cap-add SYS_PTRACE --cap-add SYS_ADMIN --security-opt apparmor=unconfined netdata/netdata 91f3d596c72eac3e9edd53cd0b79342011b67a00c3a20c2c6343d84f73a5a582 docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/etc/netdata/claim.conf" to rootfs at "/etc/netdata/claim.conf": mount src=/etc/netdata/claim.conf, dst=/etc/netdata/claim.conf, dstFd=/proc/thread-self/fd/11, flags=MS_BIND|MS_REC: not a directory: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type ``` ---
**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:** [July 8, 2026, 11:06am UTC](https://community.netdata.cloud/t/claim-not-working-on-ubuntu-24-lts-docker-ssl-connect-error/7981/6 "2026-07-08T11:06:31Z")
On the room ID question: the `-rooms` argument takes the room’s UUID, not its display name. You can find it in the URL when you navigate to a room in Netdata Cloud. If you leave it out entirely, the node will land in the General room by default. On the mount error: the problem is that `/etc/netdata/claim.conf` doesn’t exist on the host yet, so Docker has nothing to bind. You need to create the file first: ```auto mkdir -p /etc/netdata cat > /etc/netdata/claim.conf << 'EOF' [global] url = https://app.netdata.cloud token = YOUR_TOKEN rooms = YOUR_ROOM_UUID proxy = http://10.20.0.1:3128 insecure = yes EOF ``` Once the file exists on the host, the mount in your `docker run` command will work correctly. One thing to be aware of: `insecure = yes` helps with the initial claiming step, but the ongoing connection to Cloud uses a separate library that doesn’t support SSL interception. If claiming succeeds but the node shows as offline, your proxy may be the blocker for the persistent connection as well. In that case the cleanest solution is to have your proxy whitelist `app.netdata.cloud` and `mqtt.netdata.cloud` on port 443 without intercepting the traffic. ---
**Author:** ![Jacek\_Ruzyczka](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/jacek_ruzyczka/32/4901_2.png) [@Jacek\_Ruzyczka](https://community.netdata.cloud/u/Jacek_Ruzyczka)\ **Post date:** [July 8, 2026, 2:41pm UTC](https://community.netdata.cloud/t/claim-not-working-on-ubuntu-24-lts-docker-ssl-connect-error/7981/7 "2026-07-08T14:41:46Z")
When I navigate to my room `clusterbox`, I’ve got this URL in the browser and can’t figure out which of the strings are the UUID: ```auto https://app.netdata.cloud/spaces/jacek-ruzyczka-space/rooms/all-nodes/onboarding#metrics_correlation=false&after=-900&before=0&modal=&modalTab=&_o=rZLBasMwDIbfxecK7NiJ7b7AGIz10LJrkWJ5zWjjkqTdoPTd57SBDcagHbvJEr_0_bJOok2BH8MqPSQ44lbMxY7bw3oR47Zped0f6PJ2aBSjrYCiMmB8IcGzN1CURtbSKq2CFDPRc3fkroch1UvGrt5MPb-VxnnLAYdDD_yxxzZwgERvYn4S01AxH7oDz8RTc5zi80zUZXDBUgFlYTNApQlIVR6kqQKijDUWHhRra2NgKEsiMEoVQNo4UC4zMkYvs4PUUsIuNO0rbNKOYd1nGoaeh2HMXYG1dqS8iqC8V2C08YBWZr9VhT6QdgWVo6kmMGG32HMLlFJWXtGn_App6odb7ob-S_F82fpUrApSLtYlaI8IhlmCoypb1SpaE2105LP0JnfwE0mMTLfqx-_pXxp-v0T_dhh3zv59f39rdP-6z58 ``` BTW, the proxy configuration was slightly more complicated than expected: I had to add some `ssl_bump` rules, too. Unfortunately, the file error still persists when applying the command you sent me, probably because `claim.conf` is still a directory in the docker image: ```auto Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/etc/netdata/claim.conf" to rootfs at "/etc/netdata/claim.conf": mount src=/etc/netdata/claim.conf, dst=/etc/netdata/claim.conf, dstFd=/proc/thread-self/fd/14, flags=MS_BIND|MS_REC: not a directory: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type. ``` ---
**Author:** ![estrella\_s](https://avatars.discourse-cdn.com/v4/letter/e/e19b73/32.png) [@estrella\_s](https://community.netdata.cloud/u/estrella_s)\ **Post date:** [August 4, 2026, 9:03am UTC](https://community.netdata.cloud/t/claim-not-working-on-ubuntu-24-lts-docker-ssl-connect-error/7981/8 "2026-08-04T09:03:19Z")
The env variable approach from the first reply is probably your best shot here — the netdata-claim.sh path is a dead end since it’s deprecated. Did you try passing NETDATA\_CLAIM\_PROXY when you spun up the container, or did you only attempt it with docker exec? The proxy certs are definitely the culprit (SSL interception), but you gotta feed it at container start time, not after.