Housekeeping is how you learn what your software actually is. A few weeks ago Christian Hofstede-Kuhn, writing on his blog, tidied up his Fedora laptop, removed some things he thought he no longer needed, and discovered that WinBoat — the neat Electron application that runs Windows programs as if they were ordinary Linux windows — could no longer find its Windows.
The interesting part, as he puts it, is that WinBoat never was the Windows machine. It is a frontend for dockurr/windows, a container image that runs Windows inside QEMU with KVM acceleration. The virtual machine itself is a disk image plus a few state files sitting in a directory. His cleanup had removed the container and the image. It had not touched the directory. And so the recovery was comically short: one podman run command with the original storage directory mounted at /storage, and the existing Windows 11 installation booted straight to the lock screen. No reinstall, no WinBoat, no root.
What is actually inside the box
What is not inside the image, he notes, is Windows. There is a Debian 13 userland, QEMU, a web VNC viewer, networking helpers and a large stack of shell scripts under /run that do the real work. On his running container the QEMU command line shows accel=kvm, -cpu host, four cores, 14 GiB of memory, a raw data.img attached through virtio-scsi, and the pflash pair windows.rom and windows.vars for UEFI boot. A VERSION variable selects what gets installed, and the menu ranges from Windows 95 and 98 through 10 and 11, the LTSC and Enterprise variants, Windows Server 2003 to 2025, Tiny11 and even ReactOS, with Windows 11 Pro as the default and ARM64 in a separate image. Mind the spelling: the GitHub organisation is dockur, while the Docker Hub account is dockurr.
The licensing section is worth quoting in spirit: the project does not distribute Windows, the keys in its code are Microsoft’s generic installation keys, and you need your own valid license. A running container, the documentation says, is not an activated Windows. The project will happily hand you the car; the petrol is between you and Redmond.
The single most important artefact in the surviving directory turned out to be an empty file called windows.boot. The install script checks for it and, if present, skips the download and Setup entirely and just boots the disk. Delete the directory and you lose Windows; delete the container and the image and you have lost nothing a re-download cannot fix. Also surviving: WinBoat’s compose file, which conveniently recorded the exact image tag and settings — ghcr.io/dockur/windows:6.05, VERSION=11, 14G of RAM, four cores, a 64G disk — and his Windows password in plain text, which is worth knowing before you back that folder up somewhere.
One command, each flag earning its keep
He pulled the same tag WinBoat had used — podman pull ghcr.io/dockur/windows:6.05 — and got an image ID identical to the one in WinBoat’s install log, a nice confirmation of identical bits. Version 6.06 and latest already exist, but he stayed on 6.05 on principle: getting it working again and upgrading it are two separate changes. The run command itself is a small essay in minimal permissions: --device /dev/kvm because without it the image does not fall back to emulation but simply exits with code 88 (software emulation exists via KVM=N, and is about ten times slower; Fedora conveniently leaves /dev/kvm world-accessible, so a rootless container can open it); ports bound to 127.0.0.1 so the web viewer on 8006 and RDP on 3389 stay off the network; :Z to relabel the storage for SELinux instead of WinBoat’s privileged: true, which switches labelling off entirely; no NET_ADMIN and no /dev/net/tun, which the README example includes but which are only needed for NAT, macvtap and iptables setups that never run in rootless mode; --stop-timeout 120 so a Windows mid-update gets more than podman’s default ten seconds before SIGKILL; and no USERNAME or PASSWORD, because those feed the unattended installer and an installed disk already has its accounts.
Twenty seconds later the log reported a guest at 192.168.4.12 in User (passt) mode, booting through the Windows Boot Manager under QEMU v11.1.0, with an invitation to view the screen at http://127.0.0.1:8006/. It also warned that using BTRFS for /storage might cause issues with Windows Setup — a warning for fresh installs, he notes, since his image had been installed on the same Btrfs filesystem and booted fine.
The option that silently did nothing
The best find in the post concerns a setting that never worked. His earlier WinBoat configuration had specified NETWORK=nat with NET_RAW, and he had assumed that changed something. Reading the scripts, he found the container detects rootless mode from its UID mapping, tries to build a bridge for NAT, fails rootless, and — when ROOTLESS is set — returns without printing the error at all. The caller then sets NETWORK=”user” and only shows a fallback warning if the container is not rootless; in rootless mode the silence is deliberate. His whole migration to NAT, in other words, had no effect whatsoever: Windows was on passt before and remains on passt now.
Passt hands the guest a copy of the host’s address — fastfetch inside Windows shows the same 192.168.4.12 the laptop holds on its Wi-Fi interface — so outbound traffic works and the published ports reach RDP and the web viewer, but the VM has no separately reachable LAN address. Exposing any other Windows service takes two forwarding layers: a USER_PORTS entry so passt forwards into the guest, plus a matching podman -p from the host. Getting the VM its own DHCP lease from the router means a macvlan setup with DHCP=Y, effectively rootful networking, and a poor fit for Wi-Fi anyway, because an access point only accepts frames from the MAC address that associated with it.
Verification, mouse-free: curl returns 200 from http://127.0.0.1:8006/, and FreeRDP’s /auth-only mode runs the NLA authentication handshake and exits without a window, proving his account still logs in rather than merely that something listens. He then made the setup permanent with a quadlet.
There is a small lesson here about where the value of things actually lives. The product with the name, the icon and the UI was scaffolding; the possession was a directory whose most important member is an empty file. His Windows survived the deletion of its container, its image and its entire management application, because none of those was the Windows. The Windows was windows.boot — a file containing nothing at all, which turns out to be the part you cannot afford to lose.