Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-218GitHub issuePublicReceived

windows-vm launch fails repeatedly: container chmods ~/Windows to 2777, wrapper requires 700 and chmod 0700 never clears setgid

Reported by sarniva · filed Sep 21, 2026Closed upstream on 2026-10-04 by the bot omarchybot; the closing comment says it was fixed by PR #12323. GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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

windows-vm launch fails repeatedly: container chmods ~/Windows to 2777, wrapper requires 700 and chmod 0700 never clears setgidrevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

After a working Windows VM session, every subsequent omarchy-windows-vm launch prompts via polkit and then fails with:

Starting Windows VM (this may prompt for authorization)...
❌ Failed to start Windows VM!
   Try checking: omarchy-windows-vm status

status then reports container not found (expected after compose down removes it), and the next launch fails the same way.

Root cause (verified empirically)

  1. The wrapper requires ~/Windows (bind-mounted to /var/lib/omarchy/windows/mounts/users/<uid>/shared) to be exactly mode 700 (mounted_leaf_matches / mounts_ready in /usr/bin/omarchy-windows-vm).
  2. The dockurr/windows container itself chmods /shared on boot. Observed live: 700 (drwx------) -> 2777 (drwxrwsrwx) during docker compose up -d, no wrapper involved. After shutdown it was left at 2700 (drwx--S---).
  3. Once setgid is set, mounts_ready fails, so priv() falls back to pkexec __priv up_wait, which prompts and still fails: the privileged healer runs chmod 0700 on the pinned FDs, but chmod 0700 on a 2700 directory retains setgid (verified: mode retained as 2700; only chmod g-s cleared it to 700). So the failure is permanent until manual chmod g-s ~/Windows; chmod 700 ~/Windows.

Expected

  • launch should not need a polkit prompt on every run, and a single prompt (e.g. once after reboot to recreate mounts) should actually heal the state.
  • Either the wrapper should clear setgid when hardening (e.g. chmod g-s / chmod 0700 that truly yields 700), or it should tolerate the container's legitimate mode on the shared folder.

Steps to reproduce

  1. chmod g-s ~/Windows; chmod 700 ~/Windows (mounts_ready passes, exit 0).
  2. docker compose -f /var/lib/omarchy/windows/docker-compose.yml up -d
  3. stat -c '%a' ~/Windows -> 2777 (container chmodded it).
  4. Next omarchy-windows-vm launch -> polkit prompt -> __priv up_wait exits 1 with no output -> ❌ Failed to start Windows VM!.

System details (local config ruled out)

  • omarchy version: 4.0.4-1, omarchy dev status: dev-link inactive, pacman -Qkk omarchy: 0 altered files (stock binary).
  • Sudoless docker is ON via the official omarchy setup security sudoless docker toggle (user in docker group). Not the cause: the chmod happens via plain docker compose with no wrapper, and the stock (non-docker-group) pkexec-as-root path hits the same chmod 0700-retains-setgid failure.
  • /etc/docker/daemon.json is stock (owned by omarchy-settings 4.0.4-1); umask 022; no dev-link; no edits under /usr/share/omarchy/.
View raw text
## What happened
After a working Windows VM session, every subsequent `omarchy-windows-vm launch` prompts via polkit and then fails with:
```
Starting Windows VM (this may prompt for authorization)...
❌ Failed to start Windows VM!
   Try checking: omarchy-windows-vm status
```
`status` then reports container not found (expected after `compose down` removes it), and the next `launch` fails the same way.

## Root cause (verified empirically)
1. The wrapper requires `~/Windows` (bind-mounted to `/var/lib/omarchy/windows/mounts/users/<uid>/shared`) to be exactly mode `700` (`mounted_leaf_matches` / `mounts_ready` in `/usr/bin/omarchy-windows-vm`).
2. The `dockurr/windows` container itself chmods `/shared` on boot. Observed live: `700 (drwx------)` -> `2777 (drwxrwsrwx)` during `docker compose up -d`, no wrapper involved. After shutdown it was left at `2700 (drwx--S---)`.
3. Once setgid is set, `mounts_ready` fails, so `priv()` falls back to `pkexec __priv up_wait`, which prompts and still fails: the privileged healer runs `chmod 0700` on the pinned FDs, but `chmod 0700` on a `2700` directory retains setgid (verified: `mode retained as 2700`; only `chmod g-s` cleared it to `700`). So the failure is permanent until manual `chmod g-s ~/Windows; chmod 700 ~/Windows`.

## Expected
- `launch` should not need a polkit prompt on every run, and a single prompt (e.g. once after reboot to recreate mounts) should actually heal the state.
- Either the wrapper should clear setgid when hardening (e.g. `chmod g-s` / `chmod 0700` that truly yields `700`), or it should tolerate the container's legitimate mode on the shared folder.

## Steps to reproduce
1. `chmod g-s ~/Windows; chmod 700 ~/Windows` (mounts_ready passes, exit 0).
2. `docker compose -f /var/lib/omarchy/windows/docker-compose.yml up -d`
3. `stat -c '%a' ~/Windows` -> `2777` (container chmodded it).
4. Next `omarchy-windows-vm launch` -> polkit prompt -> `__priv up_wait` exits 1 with no output -> `❌ Failed to start Windows VM!`.

## System details (local config ruled out)
- `omarchy version`: 4.0.4-1, `omarchy dev status`: dev-link inactive, `pacman -Qkk omarchy`: 0 altered files (stock binary).
- Sudoless docker is ON via the official `omarchy setup security sudoless docker` toggle (user in `docker` group). Not the cause: the chmod happens via plain `docker compose` with no wrapper, and the stock (non-docker-group) pkexec-as-root path hits the same `chmod 0700`-retains-setgid failure.
- `/etc/docker/daemon.json` is stock (owned by `omarchy-settings 4.0.4-1`); umask 022; no dev-link; no edits under `/usr/share/omarchy/`.

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.