How do you run CUBE OS in Docker on Synology NAS?

eWeLink CUBE
1

Hello dear friends,

Can someone tell me how to run CUBE-OS as a Docker container on a Synology NAS ?

I already searched the internet but can’t find any info on this, only a installation of CUBE-OS on Synology Virtual Machine but that is not what I want.

Mabe someone has a Docker Compose or a Portainer Stack example on how to achieve this ?

Please let me know.

2

Hi! Thanks for asking about this, Docker deployment on NAS is something we’ve been working on. We’ll be publishing a Docker installation guide for NAS this week. Stay tuned!

3

You can check this post at first

4

Hi! We recently confirmed that some Synology NAS models may not support running CUBE OS in Docker due to a Linux kernel version limitation.

Could you first check your NAS’s kernel version? You can find it by running this command in your NAS terminal (SSH or Synology’s built-in terminal):

uname -r

CUBE OS Docker requires the kernel version to be 4.15 or above. If your kernel is below that, Docker deployment unfortunately won’t work on your current NAS model.

5

Bug report: dynamic-security MQTT “Not authorized” on fresh Docker install (amd64)

Running CUBE OS 2.10.3 Docker image ( Package cube-os · GitHub ) on Ubuntu/Xubuntu, amd64, kernel 7.0.0, with --privileged and a macvlan network (container has its own LAN IP, ports 80/1883 reachable).

On a completely fresh install (empty data dir), the web UI loads but stays stuck on the red “Disconnected. Please check your Internet connection” banner, and the initial password setup / login does nothing.

Diagnosis from /data/.logs/aibridge-api/aibridge_api.log:

  • The regular MQTT client connects fine: “connect successfully” / “Connected to MQTT server” / subscribes and receives cube/supervisor/os/info.
  • But the [dynamic-security-mqtt] client repeatedly fails: [ERROR] [dynamic-security-mqtt] MQTT error: Connection refused: Not authorized.

/data/mosquitto/ contains only dynamic-security.json (generated, 1245 bytes), no separate mosquitto log. The error persists after docker restart, and also after a full wipe of the data dir + redeploy + restart — so it appears deterministic, not a first-boot race.

Network, DNS and core MQTT all work; only the dynamic-security admin client is rejected. Looks like a credential mismatch between the generated dynamic-security.json and the password the services use. Could you check the dynamic-security init on amd64 Docker?

6

Hello, thank you for your detailed bug report.

You mentioned that you are running CUBE OS in Docker using the --privileged flag and a macvlan network. Could you please confirm whether you have separately started a mosquitto (MQTT Broker) service outside the CUBE OS container?

Since the CUBE OS image already includes a built-in mosquitto, running an additional Mosquitto on the host or in another container might cause port 1883 to be occupied, which could interfere with the MQTT authentication logic inside CUBE OS.

We have verified CUBE OS on Ubuntu 24.04 (kernel 6.17.0-14-generic) using the host network mode, where the dynamic security configuration initialises and connects successfully. This suggests that the issue may be related to the macvlan network mode.

To further investigate, we will need the complete log files from the following directory:

/data/.logs/You can package the entire folder and share it with us (e.g., upload it to a cloud drive and send us the link). These logs will help us identify exactly where the dynamic security configuration initialisation fails.

We look forward to your reply and logs, and we will prioritise the analysis. Thank you for your cooperation!

7

Hello,

Thank you for your response. Please find our answers and additional findings below.

1. No external Mosquitto running on the host

We confirmed that port 1883 is not occupied by any process outside the CUBE OS container:

$ sudo ss -tlnp | grep 1883
(no output)

So there is no port conflict with an external broker.

2. Version 2.11.0 also affected – upgrade did not resolve the issue

We want to clarify that we have already tested both available Docker image versions:

The same error occurs on both versions with a completely fresh data directory. The upgrade did not resolve the problem.

3. Log analysis – root cause identified

We extracted the logs from /data/.logs/ and found the following recurring errors in the aibridge-api log:

[ERROR] [dynamic-security-mqtt] MQTT error: Connection refused: Not authorized
[ERROR] DROP TABLE groups COLUMN sn_list error: no such column: “sn_list”

The regular MQTT client connects successfully to mqtt://[127.0.0.1](http://127.0.0.1), but the dynamic-security-mqtt admin client is repeatedly rejected with “Not authorized”. This cycle repeats approximately every 2–3 seconds.

Additionally, the supervisor log shows a continuous Bluetooth enable/disable loop (~every 2 seconds), which may indicate a hardware access issue inside the container.

4. Network mode

We have tested both macvlan network mode (container IP: 192.168.3.10) and host network mode. The error is identical in both configurations, so the network mode is not a factor.

5. Log files attached

Please find the complete /data/.logs/ directory attached as cube_logs.tar.gz.

Based on our analysis, the issue appears to be a credential mismatch between the generated dynamic-security.json and the credentials used by the dynamic-security-mqtt client during initialization, possibly combined with a database schema incompatibility (sn_list column missing). Both errors occur on a completely fresh install with an empty data directory.

CUBE OS Docker – logs and additional findings

We look forward to your findings.

Best regards,

Váczi Zoltán

Minnie <notifications@ewelinkforum.discoursemail.com> ezt írta (időpont: 2026. jún. 24., Sze, 13:39):

(attachments)

cube_logs.tar.gz (31 KB)

8

Hello, thank you for providing such detailed logs and troubleshooting steps!

We attempted to reproduce the error you described in our local environment. We did observe some errors when using the macvlan network, which will be fixed in a future release. However, the system runs normally under the host network mode.

Our test environment matches your description:

  • Kernel: Linux 7.0.0-14-generic #14~24.04.3-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 24 13:55:39 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

We used the following startup command:

bash

docker run -d \
  --name cubeos \
  --privileged \
  --net=host \
  -v /home/dockerData/data:/data \
  --device /dev/ttyUSB0:/dev/ttyUSB0 \
  -v /run/dbus/system_bus_socket:/host_dbus/system_bus_socket:ro \
  ghcr.io/ewelinkcube/cube-os:2.11.0

Please ensure that the mounted /data directory is completely empty. Alternatively, you can try not mounting an external data directory at all – in that case, the container will automatically create a /data directory internally.

We suggest that you try starting the container without mounting an external data directory as a first step. Additionally, please note that using macvlan may prevent the API from starting correctly, so for now, please use the host network mode.

If the issue still persists after these attempts, please package the new /data/.logs/ directory and send it to us.

We look forward to your feedback. Thank you for your cooperation!

9

Hi,

Thanks for the detailed reply and for confirming the macvlan issue — that matches exactly what I saw.

I tried the host network mode as you suggested (2.11.0, --net=host, --privileged, no external data mount so /data is created internally). The dynamic-security “Not authorized” error does disappear in host mode, so the API starts correctly there — confirmed.

However, host mode isn’t usable on my setup. My server is a single always-on machine running ~30 other containers (including an Nginx Proxy Manager on ports 80/443, plus many other services). Two problems:

  1. Port 80 is already taken by my reverse proxy, and CUBE OS has no option to change its internal web port, so it can’t coexist in host mode.
  2. More seriously: running CUBE OS as a privileged host-network container took over the host’s network stack (its internal DNS on 127.0.0.53 collided with the host’s systemd-resolved), which knocked out both my SSH and Portainer access. I had to physically reboot the machine to recover. This makes sense — CUBE OS is effectively a full OS (/sbin/init, avahi, its own DNS), so in --net=host + --privileged it hijacks the host networking. That’s fine on a dedicated test box, but not on a shared production host.

So for my use case, macvlan (its own IP, isolated from the host network) is really the only viable Docker deployment. I’ll wait for the macvlan fix you mentioned — please let me know when a release includes it, and I’m happy to test again.

Reproduced identically on both 2.10.3 and 2.11.0, amd64, kernel 7.0.0-27-generic.

Thanks again for looking into this!

Sincerely,

Váczi Zoltán

Minnie <notifications@ewelinkforum.discoursemail.com> ezt írta (időpont: 2026. jún. 26., P, 13:15):

10

Hi,

Thanks for the detailed reply and for confirming the macvlan issue — that matches exactly what I saw.

I tried the host network mode as you suggested (2.11.0, --net=host, --privileged, no external data mount so /data is created internally). The dynamic-security “Not authorized” error does disappear in host mode, so the API starts correctly there — confirmed.

However, host mode isn’t usable on my setup. My server is a single always-on machine running ~30 other containers (including an Nginx Proxy Manager on ports 80/443, plus many other services). Two problems:

  1. Port 80 is already taken by my reverse proxy, and CUBE OS has no option to change its internal web port, so it can’t coexist in host mode.
  2. More seriously: running CUBE OS as a privileged host-network container took over the host’s network stack (its internal DNS on 127.0.0.53 collided with the host’s systemd-resolved), which knocked out both my SSH and Portainer access. I had to physically reboot the machine to recover. This makes sense — CUBE OS is effectively a full OS (/sbin/init, avahi, its own DNS), so in --net=host + --privileged it hijacks the host networking. That’s fine on a dedicated test box, but not on a shared production host.

So for my use case, macvlan (its own IP, isolated from the host network) is really the only viable Docker deployment. I’ll wait for the macvlan fix you mentioned — please let me know when a release includes it, and I’m happy to test again.

Reproduced identically on both 2.10.3 and 2.11.0, amd64, kernel 7.0.0-27-generic.

Thanks again for looking into this!

Sincerely,

Váczi Zoltán