One of the things you have to understand about Docker is that user and group databases are different inside the container relative to outside it. If you ever used NFS without something like idmapd or NIS+ alongside it, it’s the same problem: user 1234 might not even exist on both sides, much less be the same user.
This is one reason why Docker has volumes, which RouterOS’s container implementation calls “mounts.” Permission changes then persist along with the data, so they don’t have to be fixed after each container redeployment.
I need to take the USB-stick (on which both container “live”) out, fix the permissions and re-insert in the RB3011 and then they start fine.
If you’re using volumes, you should be able to do this on-device, even if the container doesn’t start. Try something like this:
/container
add …same parameters as normal… cmd=sh
start 1 ; not 0, that's broken at the moment
shell 1
chown myuser /path/to/broken/file
exit
stop 1
start 0
The old container should start now and attach the mounts that you fixed with the temporary container.
It’s too bad you have to keep the tarball around, or re-fetch from a remote-image to create the second container. The copy-from parameter should accept another local container by number, name, tag… Anything unique it can latch onto. Cloning one existing container to create another is a normal thing in the Docker world.
mounts=“”
That’s part of your problem. No mounts means all the data gets stored inside the container, so when the container is nuked, so is the data. Put it on external volumes, and it will persist beyond the lifetime of the container.
Having user data in the container is fine if it’s normally recreated, such as by an automated container build pipeline that stuffs fresh data in each time, but when you have a case like this where you need persistent configuration, use volumes/mounts.