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-4875GitHub issuePublicReceived

windows vm launch fails when ~/Windows is empty (dockur sets shared mode 2777)

Reported by lushprey · filed Sep 4, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #9334 (R-1173). 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 when ~/Windows is empty (dockur sets shared mode 2777)revision 1 · captured 2026-10-04 12:10 UTC via poll

Summary

omarchy windows vm launch intermittently aborts with ❌ Failed to start Windows VM! for a freshly tracked VM whose ~/Windows shared folder is still empty.

Environment

  • Omarchy 4.0.2-1
  • Arch Linux, kernel 7.1.9-arch1-2
  • Filesystem: btrfs

Root cause

dockur's container runs /run/samba.sh at every start. Because the /shared source (~/Windows) is empty, it runs chmod 2777 /shared plus the Samba config directory mask = 02777, leaving ~/Windows at mode 2777 (setgid, group/other-write).

The VM launcher's preflight (mounted_leaf_matches in bin/omarchy-windows-vm) demanded the exact private mode 0700 for both mount sources. With ~/Windows at 2777, mounts_ready returns false, so launch falls back to pkexec. In a headless/agent context pkexec cannot prompt for a password, so the launch fails.

An additional wrinkle: on btrfs, chmod 0700 does not clear the setgid bit left by the 2777 chmod (the folder stays 2700), so the mode can never be reduced to a strict 700 while the container keeps re-applying it.

Reproduction

  1. Start a Windows VM once (dockur creates ~/Windows empty and pins it as /shared).
  2. Stop the VM (or just relaunch).
  3. omarchy windows vm launch while ~/Windows is mode 2777 → fails with ❌ Failed to start Windows VM!.

Checking: stat -c %a ~/Windows → 2777.

Expected

The launcher tolerates the container-applied 2777/setgid shared mode (still caller-owned, owner-rwx) instead of requiring exact 0700, so the VM starts reliably.

Proposed fix

Relax the two mount-mode checks to accept any caller-owned, owner-rwx mode ((mode & 0700) == 0700, i.e. 0700, 2700, or 2777) while keeping the FD-pinned identity and ownership checks strict.

PR: https://github.com/omacom/omarchy/pull/10113

View raw text
## Summary

`omarchy windows vm launch` intermittently aborts with `❌ Failed to start Windows VM!` for a freshly tracked VM whose `~/Windows` shared folder is still empty.

## Environment

- Omarchy 4.0.2-1
- Arch Linux, kernel 7.1.9-arch1-2
- Filesystem: btrfs

## Root cause

dockur's container runs `/run/samba.sh` at **every** start. Because the `/shared` source (`~/Windows`) is empty, it runs `chmod 2777 /shared` plus the Samba config `directory mask = 02777`, leaving `~/Windows` at mode `2777` (setgid, group/other-write).

The VM launcher's preflight (`mounted_leaf_matches` in `bin/omarchy-windows-vm`) demanded the **exact** private mode `0700` for both mount sources. With `~/Windows` at `2777`, `mounts_ready` returns false, so `launch` falls back to `pkexec`. In a headless/agent context `pkexec` cannot prompt for a password, so the launch fails.

An additional wrinkle: on btrfs, `chmod 0700` does **not** clear the setgid bit left by the `2777` chmod (the folder stays `2700`), so the mode can never be reduced to a strict `700` while the container keeps re-applying it.

## Reproduction

1. Start a Windows VM once (dockur creates `~/Windows` empty and pins it as `/shared`).
2. Stop the VM (or just relaunch).
3. `omarchy windows vm launch` while `~/Windows` is mode `2777` → fails with `❌ Failed to start Windows VM!`.

Checking: `stat -c %a ~/Windows` → `2777`.

## Expected

The launcher tolerates the container-applied `2777`/setgid shared mode (still caller-owned, owner-rwx) instead of requiring exact `0700`, so the VM starts reliably.

## Proposed fix

Relax the two mount-mode checks to accept any **caller-owned, owner-rwx** mode (`(mode & 0700) == 0700`, i.e. `0700`, `2700`, or `2777`) while keeping the FD-pinned identity and ownership checks strict.

PR: https://github.com/omacom/omarchy/pull/10113

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.