Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
omarchy-windows-vm: silent launch failure every other run — numeric chmod doesn't clear setgid, breaking the mount-safety check
Reported by HannibalHudson · filed Sep 5, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #9334 (R-1173). GitHub close reason: completed.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
What happened
After the first successful launch of the Windows VM (omarchy windows vm launch / the "Windows" menu entry), every subsequent launch fails silently: the notification just says "Failed to start Windows VM", with no further diagnostic in the terminal, omarchy windows vm status, or logs.
Root cause
assert_mounts_safe() in omarchy-windows-vm unconditionally calls prepare_caller_mounts() on every privileged bring-up (around the if ((EUID == 0)); then prepare_caller_mounts || return 1; fi block, with the comment "Mounts disappear at reboot..."). That function re-pins ~/Windows and ~/.windows, runs chmod 0700 -- "/proc/$BASHPID/fd/$fd" ... on them, then verifies the resulting mode is exactly 700, failing (return 1) otherwise.
The Windows guest exposes a file share on /shared, which is bind-mounted 1:1 from ~/Windows on the host. When the guest's share service touches that directory, it sets the directory's setgid bit (observed going from 700 to 2700/2777) — and because it's a bind mount, this is visible on the host source directory too.
On this system, chmod 0700 <dir> (absolute numeric mode) does not clear an already-set setgid bit on a directory — reproducible even on a brand-new, unrelated test directory (see below). Only the symbolic form (chmod g-s <dir>) clears it. So the script's own repair step "succeeds" (chmod exits 0) but leaves setgid in place, the immediate stat-based verification then fails, and prepare_caller_mounts/assert_mounts_safe/up_wait all return 1 — with no `echo ... >&2` on this particular branch, unlike the sibling checks in the same function (which do print a reason). The result is a fully silent, hard-to-diagnose failure on every launch after the first.
Reproduction
mkdir /tmp/t && chmod 2700 /tmp/t
chmod 0700 /tmp/t; stat -c %a /tmp/t # stays 2700 — bug
chmod g-s /tmp/t; stat -c %a /tmp/t # becomes 700 — works
rm -rf /tmp/tEnd-to-end:
1. omarchy windows vm install then launch once — works, RDP connects.
2. Stop the VM (close RDP, or omarchy windows vm stop).
3. stat -c %a ~/Windows — now shows 2700 or 2777 instead of 700.
4. Launch again — fails immediately with only "Failed to start Windows VM", no container is even created (confirmed via docker ps -a / docker logs, and via bash -x tracing straight into prepare_caller_mounts's storage_mode/shared_mode check).
Suggested fix
- Clear the special bits explicitly and unconditionally, e.g.
chmod u-s,g-s -- "$path"(orchmod 0700 -- "$path"followed by an explicitchmod g-s,u-s -- "$path") instead of relying solely on the numeric form to also strip setgid/setuid. - Add a diagnostic message when the post-chmod mode check fails (matching the style of the neighboring checks in
assert_mounts_safe), e.g.echo "omarchy-windows-vm: refusing shared/storage source with unexpected mode $shared_mode" >&2, so this doesn't fail invisibly.
Environment
- Omarchy 4.0.2-1
- Kernel 7.1.9-arch1-2
- coreutils (chmod) 9.11
$HOMEon btrfs (rw,noatime,compress=zstd:3,ssd,space_cache=v2)- docker 29.7.2, docker-compose 5.5.0
- Image:
dockurr/windows
View raw text
## What happened After the first successful launch of the Windows VM (`omarchy windows vm launch` / the "Windows" menu entry), every subsequent launch fails silently: the notification just says "Failed to start Windows VM", with no further diagnostic in the terminal, `omarchy windows vm status`, or logs. ## Root cause `assert_mounts_safe()` in `omarchy-windows-vm` unconditionally calls `prepare_caller_mounts()` on every privileged bring-up (around the `if ((EUID == 0)); then prepare_caller_mounts || return 1; fi` block, with the comment "Mounts disappear at reboot..."). That function re-pins `~/Windows` and `~/.windows`, runs `chmod 0700 -- "/proc/$BASHPID/fd/$fd" ...` on them, then verifies the resulting mode is exactly `700`, failing (`return 1`) otherwise. The Windows guest exposes a file share on `/shared`, which is bind-mounted 1:1 from `~/Windows` on the host. When the guest's share service touches that directory, it sets the directory's **setgid** bit (observed going from `700` to `2700`/`2777`) — and because it's a bind mount, this is visible on the host source directory too. On this system, `chmod 0700 <dir>` (absolute **numeric** mode) does **not** clear an already-set setgid bit on a directory — reproducible even on a brand-new, unrelated test directory (see below). Only the **symbolic** form (`chmod g-s <dir>`) clears it. So the script's own repair step "succeeds" (chmod exits 0) but leaves setgid in place, the immediate `stat`-based verification then fails, and `prepare_caller_mounts`/`assert_mounts_safe`/`up_wait` all return 1 — with **no `echo ... >&2` on this particular branch**, unlike the sibling checks in the same function (which do print a reason). The result is a fully silent, hard-to-diagnose failure on every launch after the first. ## Reproduction ```bash mkdir /tmp/t && chmod 2700 /tmp/t chmod 0700 /tmp/t; stat -c %a /tmp/t # stays 2700 — bug chmod g-s /tmp/t; stat -c %a /tmp/t # becomes 700 — works rm -rf /tmp/t ``` End-to-end: 1. `omarchy windows vm install` then launch once — works, RDP connects. 2. Stop the VM (close RDP, or `omarchy windows vm stop`). 3. `stat -c %a ~/Windows` — now shows `2700` or `2777` instead of `700`. 4. Launch again — fails immediately with only "Failed to start Windows VM", no container is even created (confirmed via `docker ps -a` / `docker logs`, and via `bash -x` tracing straight into `prepare_caller_mounts`'s `storage_mode`/`shared_mode` check). ## Suggested fix - Clear the special bits explicitly and unconditionally, e.g. `chmod u-s,g-s -- "$path"` (or `chmod 0700 -- "$path"` followed by an explicit `chmod g-s,u-s -- "$path"`) instead of relying solely on the numeric form to also strip setgid/setuid. - Add a diagnostic message when the post-chmod mode check fails (matching the style of the neighboring checks in `assert_mounts_safe`), e.g. `echo "omarchy-windows-vm: refusing shared/storage source with unexpected mode $shared_mode" >&2`, so this doesn't fail invisibly. ## Environment - Omarchy 4.0.2-1 - Kernel 7.1.9-arch1-2 - coreutils (chmod) 9.11 - `$HOME` on btrfs (`rw,noatime,compress=zstd:3,ssd,space_cache=v2`) - docker 29.7.2, docker-compose 5.5.0 - Image: `dockurr/windows`
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.