NovaScale
NovaScale Menu
Overview Releases Articles Guides FAQ Feedback
Get NovaScale app

Monitor Docker Stats in NovaScale with a Normal SSH User

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:

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). The same security model also matches Docker’s own Linux post-installation guidance: 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:

sudo adduser novascale

Then make sure the docker group exists and add the user to it:

sudo groupadd docker 2>/dev/null || true
sudo usermod -aG docker novascale

Check the Docker socket:

ls -l /var/run/docker.sock

The usual result should look like this:

srw-rw---- 1 root docker 0 Jul  2 10:00 /var/run/docker.sock

If the group is not docker, fix the socket group:

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:

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:

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:

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:

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:

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.

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.