How do you enter a running Docker container's namespaces with nsenter from the engine host?

### The premise There is no such thing as "inside the container" at the kernel level. A container is a set of ordinary Linux processes that have been given their own namespaces (mount, network, PID, UTS, IPC, and optionally user and cgroup) and placed in a cgroup. `nsenter` is a plain userspace tool that calls `setns()` to attach the calling process to another process's namespaces. Because it runs from the **host**, it does not care what the container's image contains — which is precisely why it is the standard answer for an image with no shell. ### Finding the target The engine records the host-visible PID of the container's PID 1: ``` $ docker inspect -f '{{.State.Pid}}' billing-cron 24817 ``` Two things to know about this value. It is a PID **in the host's PID namespace**, so it is the number you see in the host's `ps`, not the `1` the process sees itself as. And it is `0` when the container is not running — if `inspect` prints `0`, there are no namespaces left to enter and you are in a post-mortem, not a live debug. ### The command and its flags ``` sudo nsenter -t 24817 -n -p -- ps -ef ``` `-t` (`--target`) names the process whose namespaces you want. The rest select which namespaces to join, one flag each: `-m` mount, `-n` net, `-p` PID, `-u` UTS (hostname), `-i` IPC, `-U` user, `-C` cgroup, and `-a` for all of them. Anything after `--` is the command to run; with no command, `nsenter` runs your `$SHELL`. `nsenter` needs privilege — practically, root on the engine host, because `setns()` into another process's namespaces requires `CAP_SYS_ADMIN` in the owning user namespace. Anyone who can do this on the host is already root-equivalent on every container on it; that is a fact worth stating in an interview, because it is why this route is an operator's tool and not a developer's. ### The `-m` trap, which is the whole point The mount namespace is what makes the container's filesystem *be the image*. So: * **Without `-m`**, your new process keeps the **host's** mount namespace. Your PATH resolves to host binaries, so `ps`, `ss`, `strace`, `lsof`, `tcpdump` and `cat` all exist and run — while `-n` and `-p` mean they are looking at the container's network stack and process tree. On a `FROM scratch` billing-cron container this is the only way to get `strace` anywhere near the process. * **With `-m`**, you enter the container's mount namespace too, your PATH now resolves inside the image, and you are back to "no such file or directory" for every tool. Candidates who have only ever copy-pasted `nsenter -t $PID -m -u -i -n -p` from a blog hit this and conclude nsenter is broken. The container's files are still reachable without `-m`, through the magic symlink `/proc/24817/root`, which resolves paths as if that process's root were the root: ``` ls -l /proc/24817/root/etc/ cat /proc/24817/environ | tr '\0' '\n' cat /proc/24817/cgroup ``` That gives you the container's config files, environment, cgroup path and open file descriptors (`/proc/24817/fd`) with host tools. ### Practical notes With `-p`, `nsenter` **forks**: a process cannot change its own PID namespace, only its children can be created in the new one, so the shell you get is a child. That is why the entered shell shows itself with a small PID and why `nsenter -p` without a command still behaves sanely. Entering only `-n` is a common narrower choice when you want the container's network view with host tooling and do not care about its process tree. On **Docker Desktop** there is no host PID to target: `dockerd` runs inside a Linux VM, so `State.Pid` is a PID in that VM's namespace and `nsenter` must run in the VM — usually via a privileged container started with `--pid=host`, which puts you in the VM's PID namespace first. Docker Desktop also ships a `docker debug` command that packages this whole trick as a supported subcommand; it is a paid-subscription feature, so do not assume it is present. ### When not to reach for it If you only have the Docker API and not root on the engine host — the normal case for a developer against a shared or remote engine — `nsenter` is not available to you at all, and the toolbox-container route is the answer instead. Saying that out loud is what separates a memorised command from understanding the access model.