ZimaOS 1.5.3 (account Plus): Remote ID not publishing URL (NXDOMAIN) - Device connection not ready

Insight & Feedback
1

Hello ZimaOS Support Team,

I am writing to report a persistent issue with my ZimaBoard 2 (ZimaOS v1.5.3). I have an active ZimaOS Plus license, but the remote access system is completely non-functional.

Current Situation:

  1. DNS Issue: Any attempt to access the remote link results in a DNS_PROBE_FINISHED_NXDOMAIN error.

  2. Dashboard: The “Remote Access” toggle is ON, but no public URL (zimaos.link) appears under the Remote ID.

  3. ZimaClient: On Windows, the client is stuck in a loop and eventually shows “Device connection not ready”.

  4. ZeroTier: The local engine shows “Connected” to the IceWhale-RemoteAccess network, but no data is being routed through the ZimaOS tunnel.

Troubleshooting already performed:

  • Reset Remote ID: I have already used the “Reset Network ID” function to generate a new ID, but the new one is also not being published.

  • System Reboot: I have restarted the ZimaBoard multiple times.

  • Account Sync: Performed Logout/Login from my ZimaSpace account on the dashboard.

  • Firewall: Windows Firewall is correctly configured to allow ZimaClient and ZeroTier.

  • Local Access: I can access the board perfectly via local IP (192.168.1.230).

It appears my device is not being registered correctly on your DNS/Proxy servers. Could you please manually verify or reset the mapping for my account?

Account Email: vitopatera@gmail.com New Remote ID: a6c908abf382ddfb

Best regards

2

I’ve had problems using remote ID too in 1.5.3, ocassionaly I needed to turn off remote access and re-enable it to get access. 1.5.4 alpha builds from github seem to be working much better for now.

3

To update ZimaOS from the terminal, follow these steps:

  • Enable Developer Mode: Go to Settings > General > Developer mode and enable SSH Access and Web-based terminal.

  • Open Terminal: Access the terminal via SSH or the web interface.

  • Switch to Root: Run sudo -i to switch to the root account.

  • Run Update Command:

    • To update to the latest version (stable or beta, based on your channel):

      curl -fsSL 'https://ota.zimaos.com/' | sh

    • To install a specific version (e.g., Alpha builds 1.5.4):

      curl -fsSL 'https://ota.zimaos.com/1.5.4-alpha3' | sh

just in case you would like to try and see if the latest alpha version works better, and you can repeat the steps to return to 1.5.3 using curl -fsSL ‘https://ota.zimaos.com/’ | sh if you find any problems.

I have not found any glaring problems with the latest alpha builds so I reckon the next stable version will be much better.

4

Hi James,

I followed your advice and successfully updated to 1.5.4-alpha3, but unfortunately, the issue persists.

Here is the current status:

  • Remote ID: After the update, I performed another “Reset Network ID”, but still no public URL appears under the ID.

  • DNS Error: I am still getting the NXDOMAIN error when trying to reach the ZimaOS link.

  • ZimaClient: On Windows, it still shows “Device connection not ready” and remains stuck in the “Connecting” loop.

  • Local Services: Everything works perfectly fine locally (including my UPS NUT server/WinNUT), confirming my local network and the ZimaBoard hardware are healthy.

Since I have already tried the alpha build, multiple ID resets, and account re-syncing, it seems my device is not being correctly registered/propagated on your side (DNS/Proxy backend).

Could you please check my account/ID on your backend to see why the public URL is not being generated?

Current Remote ID: 39de09cbc1337bef (updated today)

ZimaSpace Account Email: vitopatera@gmail.com

Thanks for your support

5

Sorry Vito, I’m just a community member like yourself. the Icewhale team will pick this up soon and be able to dive deeper into a solution.

I’m wondering if its your router/firewall blocking or ISP blocking the zerotier vpn used to connect remotely but again be best for Icewhale to help you out.

6

could use tailscale or netbird to remote into the zima nas… I use netbird on my router as a routing peer to access everything on my network including zima. could be handy to get you access until Icewhale resolve the problem. netbird and tailscale are in the app store. and netbird youtube channel is really easy to follow if you need help setting it up.

7

Hi Vito, thanks for the detailed update, that really helps.

Because you’re getting NXDOMAIN and ZimaOS never shows a public URL under Remote ID, it usually means the remote-access provisioning step isn’t completing. That can happen if the device can’t reach the backend properly (DNS / firewall / ISP filtering), or if the backend doesn’t publish the record.

If you can run the checks below and paste the outputs, we can narrow this down.

1) Basic DNS + internet sanity check

cat /etc/resolv.conf

nslookup google.com
nslookup cloudflare.com

ping -c 3 1.1.1.1
ping -c 3 google.com

If IP ping works but name ping fails > DNS issue.
If both fail > internet/routing issue.

2) Confirm time + NTP (important for authentication)

Bad time can break TLS/auth and stop registration.

date
timedatectl status

3) Confirm routing / gateway looks normal

ip addr
ip route

4) Look for any “remote access / tunnel / zerotier” services

systemctl list-units --type=service --all | grep -iE "zima|remote|tunnel|vpn|zero|client"

And check for failures in systemd:

systemctl --failed

5) Pull the most relevant logs (this is the big one)

This will surface handshake errors, blocked traffic, DNS issues, etc.

journalctl -b --no-pager | grep -iE "remote|network id|zerotier|tunnel|vpn|proxy|dns|nxdomain|connect|register|token|auth|ssl|tls" | tail -200

Also worth checking Docker-related logs since ZimaOS uses it heavily:

journalctl -u docker --no-pager | tail -150

6) Check if anything is blocking outbound traffic

Quick view of firewall status:

iptables -S

If ZimaOS has nftables:

nft list ruleset | head -200

7) Check your DNS resolver is working properly

Sometimes local resolvers (Pi-hole, AdGuard, router DNS) cause weird NXDOMAIN behavior.

nslookup -type=A google.com 1.1.1.1
nslookup -type=A google.com 8.8.8.8

If these work but your normal nslookup fails > your LAN DNS is the problem.

8) Last check — can the box reach the outside world over HTTPS?

This proves it can reach cloud services at all.

curl -I https://1.1.1.1
curl -I https://google.com

How we’ll interpret this

  • If DNS/time/routing look fine and there are no tunnel/auth failures, then it strongly points to backend provisioning/DNS publish not happening for your Remote ID.
  • If you see timeouts / handshake failures / blocked UDP/VPN style traffic, then it’s more likely router/firewall/ISP filtering.

Post the outputs (even screenshots are fine) and I’ll help you pinpoint which side it’s failing on.

8

Hi James and Zimaspace community,

I’m reporting back after testing the ZimaOS 1.5.4-alpha3 update on my ZimaBoard. Unfortunately, despite the update, the “Remote ID” and “Remote Access” services still show the “Device connection not ready” error, and the official remote link doesn’t work.

Since I needed a reliable way to share my Immich albums with my family (without forcing them to install ZimaClient or Tailscale), I implemented a manual workaround that is working perfectly:

  1. Static Local IP: I confirmed my ZimaBoard is stable at 192.168.1.230.

  2. Port Forwarding: I manually opened port 2283 (TCP) on my router (TIM HUB+).

  3. Dynamic DNS: I configured DuckDNS directly on my router to handle my ISP’s dynamic IP changes.

  4. Immich Settings: I updated the “External Domain” in Immich settings to my DuckDNS address.

Result: My family can now access the photos via a simple browser link, bypassing the ZimaOS remote relay entirely.

An interesting note: while the remote access is buggy, my local network stability is perfect. My PC (Windows) is still successfully monitoring the UPS connected to the ZimaBoard via WinNUT, and the connection remains “Green” and stable.

I hope this helps others who are stuck with the “Connecting…” status. James, let me know if you need any specific logs to investigate why the native remote access is still failing on my setup!

A suggestion for the ZimaOS Team: For future releases, it would be great to see improvements in the reliability of the native Remote Access service. Relying on manual Port Forwarding and external Dynamic DNS services (like DuckDNS) shouldn’t be necessary for a device designed for ease of use.

Specifically, it would be very helpful if:

  1. The Remote ID handshake became more robust against different router configurations.

  2. There was a built-in “Easy Share” feature for apps like Immich that automatically handles the external URL generation without manual tweaks.

  3. The dashboard gave more clear feedback/logs when the “Device connection not ready” error occurs, so users know if it’s a local network issue or a server-side problem.

Best, Vito

9

No problem Vito, seems you have a preferable method now then, I had kindly asked Gelbuilding to help you out. glad you sorted things out.

10

Hi Gelbuilding, thanks for the detailed list! Here are the outputs from my ZimaBoard (ZimaOS 1.5.4-alpha3):

1) Basic DNS + Internet check nslookup google.com works fine:

Server: 192.168.1.230
Address: 192.168.1.230:53
Non-authoritative answer:
Name: google.com
Address: 216.58.204.238

ping -c 3 1.1.1.1 and google.com both successful.

2) Confirm time + NTP date command shows: Sun Jan 18 12:00:09 CET 2026. timedatectl status confirms NTP is active and time is synchronized.

3) Routing / Gateway ip route shows: default via 192.168.1.1 dev eth0 proto static. (Standard for my TIM HUB+ router).

4) Remote / Tunnel Services status systemctl --failed returns 0 failed units. ZeroTier appears active in the logs, but no Public URL is generated.

5) Relevant Logs (The big one) I found several 401 Unauthorized errors in journalctl: "status":401, "error":"code=401, message=invalid or expired jwt" This happens repeatedly when the system tries to communicate with the ZimaOS backend.

6) Firewall (iptables) iptables -S shows mostly default Docker rules (ACCEPT), no signs of outbound blocking on port 443 or UDP for ZeroTier.

7) DNS Resolver working? Yes, nslookup google.com 1.1.1.1 works perfectly. The local resolver (192.168.1.230) is also working fine as shown in point 1.

8) Reach outside world via HTTPS? curl -I https://google.com returns HTTP/2 200. The box can reach HTTPS services without issues.

Conclusion: Since DNS, Time, and HTTPS connectivity are all fine, it really looks like the backend provisioning/JWT authentication is the bottleneck here. My ISP (TIM Italy) doesn’t seem to be filtering this traffic.

11

Hi Vito, this is excellent info. Thank you for running all those checks.

You have basically proven it is NOT DNS, NOT time/NTP, NOT routing, and NOT firewall/ISP.

The smoking gun is in your logs:
401 Unauthorized
invalid or expired jwt

That means the ZimaOS box can reach the backend, but the backend is rejecting the auth token during the Remote ID registration handshake. If the handshake fails, the public URL never gets generated, which matches your symptoms exactly (no URL + NXDOMAIN + Device connection not ready).

If you can, please paste 20 to 40 lines around the 401 error so the IceWhale team can see the exact service and endpoint being hit:

journalctl -b --no-pager | grep -n "401" | tail -20

Then grab the surrounding lines from one of the matches (replace 1234 with the line number you see):

journalctl -b --no-pager | sed -n '1220,1260p'

Also please share the Remote ID service logs if it exists (sometimes it is named differently depending on build):

systemctl list-units --type=service --all | grep -iE "zima|remote|id|zero|tunnel|vpn"

At this point it really looks like a backend provisioning/auth issue, so I think IceWhale will need to check your account token provisioning and Remote ID registration flow server-side.