Run development containers with rootless Docker

[acrogenesis]

Omarchy currently keeps ordinary users away from the root-equivalent system Docker socket, which leaves development Docker behind repeated privilege prompts. This proposal runs development workloads in Docker's per-user rootless daemon while preserving the Docker CLI and API, Compose, Buildx, lazydocker, images, and the existing d='docker' alias. It is a direct-Docker alternative to #11032 for side-by-side review.

Fresh installs allocate nonoverlapping subordinate UID/GID ranges after checking every resolvable account and both subordinate-ID databases. Omarchy then prepares the account-owned daemon configuration, enables only that initialized user's service, and selects $XDG_RUNTIME_DIR/docker.sock through a marker-gated systemd environment generator. The daemon runs with a fixed packaged PATH, fixed configuration root, bounded JSON logs, private cgroups, seccomp, and verified RootlessKit/dockerd arguments.

Existing installs receive an automatic, batch-preflighted migration from the system daemon. Compatible containers retain their writable layer, exact application configuration, supported limits, localhost ports, restart policy, capability ceiling, and private named-volume contents and metadata. The migration fails closed before stopping anything when it cannot reproduce a workload safely, including privileged mode, added capabilities, host paths, devices, shared volumes, custom networking/runtime/confinement/logging, or unknown nondefault host settings.

The cutover is journaled and crash-replayable. Omarchy quiesces the complete batch before revoking connected rootful clients, seals source volumes, transfers committed images by identity, pins destination volumes with an inert never-started guard, forces copied filesystems to stable storage, and keeps a durable Docker event window that rejects even transient foreign mounts. Runtime verification and receipt publication bind the exact source and destination snapshots. Failures before the first destination start restore the source and remove only proven-owned artifacts; once a destination start may have occurred, both copies remain stopped for explicit inspection. Successful rootful copies remain stopped with restart disabled as recovery data.

Windows stays on a separate rootful Docker daemon because KVM, TUN, and NET_ADMIN require that boundary. /run/docker.sock becomes root:root mode 0600; the Windows command pins the socket and protected host paths, keeps Compose and credentials root-only, preserves lifecycle across reconciliation, and authenticates every terminal or graphical operation through sudo or pkexec.

Companion package PR: omacom/omarchy-pkgs#405

Validation

• full ./test/cli
• affected rootless migration/posture, configuration, provisioning, historical Docker-group, Windows security/Compose/mount, and bin-style suites
• full 237-file shell audit; every affected suite passes, with remaining failures reproduced as unrelated baseline or local-environment failures
• Python compilation, Bash syntax, whitespace checks, and clean merge-tree against current quattro
• isolated docker-rootless-extras build and generated-service inspection
• Omarchy Lab path deployment and focused suites, with no failed units or Hyprland errors
• real Lab checks for daemon/socket identity, compatible running and stopped migrations, retained-volume retry, event-history enforcement, batch rollback, post-start retention, Compose, Buildx, lazydocker, reboot persistence, later-account initialization, and authenticated rootful Windows activation
• repeated independent Codex review; final round reported no valid actionable findings

Screenshots

The first capture shows migrated containers, Docker images, private volumes, and the stock Docker network in lazydocker. The second shows the active rootless daemon and per-user store after reboot while the desktop user remains denied access to the rootful Windows socket.