# Monitor Docker Stats in NovaScale with a Normal SSH User Canonical: https://galaxnet.dev/nova/articles/docker-stats-ssh-normal-user/ Language: en-US Set up a non-root SSH user so NovaScale can read Docker container stats over SSH without exposing the Docker daemon to the public network. NovaScale's Docker monitoring is intentionally simple from the network side: connect to your host over SSH, then run Docker CLI commands on that host. You do not need to expose the Docker daemon on a TCP port, and you do not need to publish a monitoring API to the internet. The one thing the SSH user must have is local Docker access. In practice, that means the user must be able to run commands such as: ```bash docker ps docker stats --no-stream ``` This article shows how to prepare a normal SSH user for that workflow, including the Synology DSM case inspired by Nataraj Basappa's article, [Configuring Docker on Synology NAS (DSM 7.x)](https://www.natarajmb.com/2022/01/docker-synology/). The same security model also matches Docker's own [Linux post-installation guidance](https://docs.docker.com/engine/install/linux-postinstall/): Docker socket access is powerful, so only grant it to users you trust. ## What NovaScale needs For Docker monitoring, NovaScale needs an SSH configuration that can reach the host and a remote user that can run Docker CLI commands without an interactive `sudo` prompt. The minimum checklist is: - SSH is enabled on the host. - The host is reachable from NovaScale, ideally through your tailnet. - The SSH user can log in with a password or, preferably, an SSH key. - The `docker` CLI is installed and available in the remote user's `PATH`. - `docker ps` and `docker stats --no-stream` work from a fresh SSH session. If you also use container lifecycle actions in NovaScale, such as start, stop, or restart, remember that those are not read-only operations. A user that can control Docker can often gain broad control over the host, so do not treat Docker group access as a narrow monitoring permission. ## Security note The common Linux pattern is to add the user to the `docker` group. That is convenient, but it is not a read-only permission. Docker documents this group as root-level access because the Docker daemon runs with high privilege and the Unix socket controls that daemon. My recommendation is: - Create a dedicated SSH user for NovaScale instead of reusing your daily admin account. - Use SSH key authentication when possible. - Keep the host reachable through Tailscale or another private network path. - Do not expose the Docker TCP API just to make mobile monitoring work. - Only grant Docker access to accounts you would trust with administrative control of the host. This still gives you a normal login user for NovaScale. It does not make Docker itself a read-only interface. ## Standard Linux setup On a normal Linux server where Docker Engine was installed from system packages, the Docker socket is usually owned by `root:docker`. First, create or choose the SSH user: ```bash sudo adduser novascale ``` Then make sure the `docker` group exists and add the user to it: ```bash sudo groupadd docker 2>/dev/null || true sudo usermod -aG docker novascale ``` Check the Docker socket: ```bash ls -l /var/run/docker.sock ``` The usual result should look like this: ```text srw-rw---- 1 root docker 0 Jul 2 10:00 /var/run/docker.sock ``` If the group is not `docker`, fix the socket group: ```bash sudo chgrp docker /var/run/docker.sock sudo chmod 660 /var/run/docker.sock ``` Open a new SSH session as the NovaScale user. Group membership is evaluated at login, so an old session may still fail: ```bash ssh novascale@your-host id docker ps docker stats --no-stream ``` If these commands work without `sudo`, the host is ready for NovaScale Docker monitoring. ## Synology DSM setup Synology is a little different because Docker or Container Manager is packaged by DSM, and the Docker socket may be owned by `root:root`. The referenced DSM 7.x article points out the important part: command-line Docker access for a non-root user depends on the ownership of `/var/run/docker.sock`. On DSM 7.2 and newer, the package is usually named **Container Manager**. On older DSM 7.x installs, it may still be named **Docker**. The principle is the same. First, do the one-time DSM setup: 1. Install **Container Manager** or **Docker** from Package Center. 2. Enable SSH in **Control Panel > Terminal & SNMP**. 3. Create a normal DSM user such as `novascale`. 4. Do not make this user a DSM administrator unless you need it for other reasons. Then SSH into the Synology as an administrator account and inspect the socket: ```bash ls -l /var/run/docker.sock ``` If you see `root root`, create a Docker group, move the socket to that group, and add the NovaScale user: ```bash sudo synogroup --add docker 2>/dev/null || true sudo chown root:docker /var/run/docker.sock sudo chmod 660 /var/run/docker.sock sudo synogroup --member docker novascale ``` If you already have a `docker` group with other users, review the group in DSM after running the command. On Synology, it is often safer to manage the final group membership from the DSM UI once the group exists. Now open a new SSH session as the normal user: ```bash ssh novascale@your-synology id docker ps docker stats --no-stream ``` If `docker stats` works, NovaScale can use the same SSH profile for Docker monitoring. One practical DSM detail: package restarts or DSM upgrades may recreate `/var/run/docker.sock` with the original group. If monitoring suddenly starts failing with a socket permission error, check the socket ownership again and reapply the `chown root:docker` step. If this happens after every reboot on your NAS, create a DSM scheduled task that runs the ownership fix after boot. ## Configure NovaScale After the host-side commands pass, configure NovaScale: 1. Add or edit the SSH host in NovaScale. 2. Use the normal user, for example `novascale`. 3. Prefer SSH key authentication. 4. Use the host's MagicDNS name, tailnet IP, or private LAN address. 5. Open the host's monitoring view and enable Docker monitoring. For a quick manual test from NovaScale's terminal, connect to the same host and run: ```bash docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.BlockIO}}\t{{.PIDs}}" ``` That command returns a compact snapshot that is easy to read on a phone. NovaScale's monitoring view can then turn the same kind of data into cards and refreshable host state. Docker documents the available `docker stats` columns and formatting fields in the official [`docker container stats` CLI reference](https://docs.docker.com/reference/cli/docker/container/stats/). ## Troubleshooting If you see `permission denied while trying to connect to the Docker daemon socket`, the SSH user still cannot access `/var/run/docker.sock`. Check `id`, `groups`, and `ls -l /var/run/docker.sock` from a fresh SSH login. If you see `docker: command not found`, Docker may not be installed, or the CLI may not be in the non-interactive SSH environment's `PATH`. Test with `which docker` and use the full path if your platform stores it outside the usual locations. If Synology works after setup but fails later, DSM probably recreated the socket during a package restart or system update. Re-check the socket group and reapply the group ownership change. If SSH works on the LAN but not from NovaScale, check the network path separately. For tailnet hosts, verify MagicDNS or the tailnet IP, and confirm the host is online in Tailscale. ## Final recommendation Use SSH for transport, keep Docker local to the host, and grant Docker access only to a dedicated account you trust. That gives NovaScale enough access to show container CPU, memory, network, block I/O, and process counts from your iPhone or iPad without turning the Docker daemon into a remotely exposed service.