$ docker exec CONTAINER ls -lR /etc
    $ ssh myrouter '/container/shell cmd="ls -lR /etc" 0'

That is to say, they each pass a multi-argument command to `/bin/sh` inside the container, if it exists, which then parses the command and executes it within the container’s confines.

Prior releases lacked the `cmd` parameter, limiting you to an interactive `/container/shell` call.

Even under RouterOS 7.20, the following will fail:

    > /container
    > add remote-image=docker.io/library/alpine
    > start 0
    > shell cmd="ls -lR /etc"

This container is configured with `/bin/sh` as its entrypoint. Couple that with the container creator’s assumption that you are running it under “`docker run -it`” or similar, and you have a recipe for trouble. RouterOS will dutifully run the shell on getting the `start` command, but the subsequent `shell` call will fail because there is no interactive terminal attached: lacking any source of input, the shell immediately exits, leaving no running container for the `shell` command to attach to. One must resort to [ugly hacks](#run) to work around this type of problem.

Mind, that `shell` command _will_ work for a container that has a background process configured as its default entrypoint, since it remains running, avoiding the need for the ugly hack.


## <a id="export"></a>`export`/`save`

There is no way to produce a tarball of a running container’s filesystem or to save its state back to an [OCI] image tarball.

The [documented advice][imgtb] for getting such a tarball is to do this on the PC side via `docker` commands, then upload the tarball from the PC to the RouterOS device.