Having done so, we have a new limitation to contend with: RouterOS logging isn’t as powerful as the Docker “`logs`” command, which by default works as if you asked it, “Tell me what this particular container logged since the last time I asked.” RouterOS logging, on the other hand, mixes everything together in real time, requiring you to dig through the history manually.

(The same is true of `podman logs`, except that it ties into systemd’s unified “journal” subsystem, a controversial design choice that ended up paying off handsomely when Podman came along and wanted to pull up per-container logs to match the way Docker behaved.)


# <a id="root"></a>Everything Is Rootful

This shows up in a number of guises, but the overall effect is that all containers run as a nerfed `root` user, same as Docker did from the start. This remains the Docker default, but starting with the 20.10 release, it finally got a [rootless mode][drl] to compete with [Podman’s rootless-by-default][prl] nature. I bring up this history to show that RouterOS is not unconditionally “wrong” to operate as it does, merely limited. If your container was designed to run rootless, you will have to revert it to the old Docker way.
This shows up in a number of guises, but the overall effect is that all containers run as a nerfed `root` user, same as Docker did from the start. This remains the Docker default, but starting with the 20.10 release, it finally got a [rootless mode][drl] to compete with [Podman’s rootless-by-default][prl] nature. I bring up this history to show that RouterOS is not unconditionally “wrong” to operate as it does, merely limited.

The is design choice may be made reasonably safe through the grace of user namespaces — “userns” in kernel-speak — which cause the in-container `root` user to be meaningfully different from the Linux `root` user that RouterOS itself runs as. RouterOS has a `/user` model, but they are not proper Linux users as understood by the kernel, with permissions enforced by Linux user IDs. This means that when you start a container as RouterOS user `fred`, you do not see a `fred` user inside the container, and that files created by that nerfed `root` user show up as owned by `root` when using bind-mounted directories on file systems like `ext4` which preserve file ownership.

That yields one possible solution for this:

     /disk/format-drive file-system=exfat …

It is because of this same limitation that there is no RouterOS equivalent to the `create --user*` or `--group-add` flags.

If your container was designed to have non-root users inside with meaningful distinctions from root, it may require massaging to work on RouterOS. There are no UID maps to convert in-container user IDs to RouterOS user IDs, etc. This is one of the key reasons why it matters that [containers are not VMs][cvm]; persisting in this misunderstanding is liable to lead you to grief under `container.npk`. Let go of your preconceptions and use the RouterOS container runner the way it was meant to be applied: running well-focused single services.(^This philosophy is not specific to RouterOS; this is not special pleading on its behalf, in service of justifying its limitations. [Microservices][msc] are good idea atop _all_ container runtimes.)

[cvm]: /wiki?name=Containers%20Are%20Not%20VMs
[drl]: https://docs.docker.com/engine/security/rootless/
[msc]: https://www.bmc.com/blogs/containers-vs-microservices/
[prl]: https://developers.redhat.com/blog/2020/09/25/rootless-containers-with-podman-the-basics



# <a id="cpu"></a>CPU Limitations

This limitation comes in two subclasses: