What does `dockerd-rootless-setuptool.sh install` set up, and what must already be on the host for it to succeed?

### What the tool is Rootless mode lets an unprivileged user run their own Docker Engine instead of sharing the system-wide one. The install path for it is a shell script, `dockerd-rootless-setuptool.sh`, which the engine repositories ship in the **docker-ce-rootless-extras** package. It is run by the target user (`dockerd-rootless-setuptool.sh install`), *not* under sudo — running it as root is the most common way people get it wrong, because the whole point is to configure a daemon that belongs to that user's session. ### What it checks before it does anything The script front-loads a prerequisite check and fails with a clear message rather than half-installing: - **newuidmap and newgidmap.** These setuid helpers are what allow an unprivileged process to map more than one ID inside a user namespace. On Debian and Ubuntu they come from the `uidmap` package; on RPM distributions they are in the shadow-utils family. Without them there is no way to give the daemon a usable range of IDs. - **Subordinate ID ranges.** The user needs entries in **/etc/subuid** and **/etc/subgid** — a line like `alice:100000:65536` granting that user a block of subordinate IDs. Most distributions create these automatically when the account is made, but accounts created by configuration management or by an installer frequently have none, and the script stops there. - **A user session with systemd.** The generated unit is a *user* unit, so the tool expects a running user instance of systemd and `$XDG_RUNTIME_DIR` to be set. This is why running it over `sudo su - user` often fails where a real login session works. ### What it produces On success you get three things. 1. A **systemd user unit** for the daemon, managed with `systemctl --user start docker` — note the `--user`, which is the whole difference from the system-wide service. 2. An **API endpoint owned by that user**: a socket under `$XDG_RUNTIME_DIR`, in practice `/run/user/<uid>/docker.sock`. Nothing about /var/run/docker.sock changes; the two engines coexist and see completely separate images and containers, which surprises people who expect `docker images` to show what the system daemon has. 3. Instructions for pointing the CLI at it — either `export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock` or a CLI context named `rootless` that the tool creates for you. ### The two steps people forget **Enable the user unit**: `systemctl --user enable --now docker`. Without `enable`, the daemon does not come back when the user's session restarts. **Enable lingering**: `sudo loginctl enable-linger "$USER"`. By default a user's systemd instance — and everything under it — is torn down when their last session ends. For an interactive developer that is invisible; for a service account running an invoice-rendering worker it means the containers die the moment the SSH session closes and never start at boot. Lingering is the switch that makes a per-user daemon behave like a real service. It is also the single most common "it worked yesterday" report from a first rootless deployment. ### Uninstalling and coexistence The same script takes `uninstall`, which removes the user unit and stops the per-user daemon. Coexistence with the system daemon is normal and supported — the rootless engine has its own data directory under the user's home, so images pulled in one are invisible to the other, and disk usage is counted twice if you pull the same image in both. When someone reports "my image disappeared", check `DOCKER_HOST` and which context is active before checking anything else: they are almost certainly talking to the other daemon. ### Why an interviewer asks this This is not a screening question — plenty of strong engineers have never installed rootless mode. It is asked to see whether you understand that Docker's install story has more than one shape, and whether you reason about *prerequisites and lifetime* rather than pasting commands. A good answer names the uidmap tooling and the subuid/subgid ranges as the things that must exist first, the user-scoped systemd unit and per-user socket as what you get, and lingering as the difference between a demo and something that survives a logout.