Files created by that nerfed `root` user will show up as owned by `root` when using bind-mounted directories on file systems like `ext4` which preserve file ownership. One possible solution for this is:

    /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. Its `/user` model has no connection to proper Linux users as understood by the kernel; while a RouterOS user does have an ID, it is not a UID recognized by the underlying Linux kernel, which it uses in enforcing permissions. One practical effect of this is that when you start a container as RouterOS user `fred`, you will not find a `fred` entry in the generated`/etc/passwd` file inside the container, and if you create one at container build time (e.g. with a `RUN useradd` command) it will not be the same `fred` as the RouterOS user on the outside.
If your container was designed to have non-root users inside with meaningful distinctions from root, it may require massaging to work on RouterOS, whose `/user` model has no connection to proper Linux users as understood by the kernel. While a RouterOS user does have an ID, it is not a UID recognized by the underlying Linux kernel, which it uses in enforcing permissions. One practical effect of this is that when you start a container as RouterOS user `fred`, you will not find a `fred` entry in the generated`/etc/passwd` file inside the container, and if you create one at container build time (e.g. with a `RUN useradd` command) it will not be the same `fred` as the RouterOS user on the outside.

This brings us to the oft-repeated observation that [containers are not VMs][cvm]. Persisting in misunderstanding the distinction 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, nor is it special pleading on its behalf, meant to justify 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