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

omarchy-windows-vm launch fails silently: dockur/windows re-applies setgid on ~/Windows, tripping the 700-only mounts check

Reported by ajgorrell · filed Sep 4, 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

omarchy-windows-vm launch fails silently: dockur/windows re-applies setgid on ~/Windows, tripping the 700-only mounts checkrevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

omarchy-windows-vm launch intermittently fails with "Failed to start Windows VM!"
and no further detail, before Docker is ever touched.

Root cause

omarchy-windows-vm launch requires the two folders it bind-mounts into the VM
(~/.windows and ~/Windows) to be exactly mode 700. The dockur/windows
container's internal Samba service (which exposes ~/Windows to the Windows guest
as a network share) re-applies a setgid bit to that directory (drwx--S---, mode
2700) as part of its own share setup, every time the container starts. On the next
launch attempt, Omarchy's mounts-safety check sees 2700 instead of 700 and aborts
before reaching Docker — with no error surfaced beyond the generic
"Failed to start Windows VM!" from the launcher.

This is recurring, not a one-off — it happens after essentially every session where
the container has been up (and Samba has touched the share).

Steps to reproduce

  1. Set up the Windows VM (omarchy-windows-vm / dockur/windows).
  2. Launch and use it at least once: omarchy-windows-vm launch --keep-alive.
  3. Let the container stop (or stop it).
  4. Launch again — it silently fails with "Failed to start Windows VM!".
  5. stat ~/Windows shows drwx--S--- (2700) instead of drwx------ (700).
  6. sudo chmod g-s ~/Windows and relaunch — works again, until the container runs

and the bit comes back.

Expected

Either the mounts check tolerates/clears the setgid bit itself (since it's coming
from the VM's own Samba service, not the user), or the failure surfaces a specific,
actionable error instead of a generic "Failed to start Windows VM!".

System details

Omarchy 4.0.2-1, Hyprland 0.56.2, Arch Linux. Diagnostic log gathered via
omarchy-debug --no-sudo --print and available on request.

View raw text
## What happened
`omarchy-windows-vm launch` intermittently fails with "Failed to start Windows VM!"
and no further detail, before Docker is ever touched.

## Root cause
`omarchy-windows-vm launch` requires the two folders it bind-mounts into the VM
(`~/.windows` and `~/Windows`) to be *exactly* mode 700. The dockur/windows
container's internal Samba service (which exposes `~/Windows` to the Windows guest
as a network share) re-applies a setgid bit to that directory (`drwx--S---`, mode
2700) as part of its own share setup, every time the container starts. On the next
launch attempt, Omarchy's mounts-safety check sees 2700 instead of 700 and aborts
before reaching Docker — with no error surfaced beyond the generic
"Failed to start Windows VM!" from the launcher.

This is recurring, not a one-off — it happens after essentially every session where
the container has been up (and Samba has touched the share).

## Steps to reproduce
1. Set up the Windows VM (`omarchy-windows-vm` / dockur/windows).
2. Launch and use it at least once: `omarchy-windows-vm launch --keep-alive`.
3. Let the container stop (or stop it).
4. Launch again — it silently fails with "Failed to start Windows VM!".
5. `stat ~/Windows` shows `drwx--S---` (2700) instead of `drwx------` (700).
6. `sudo chmod g-s ~/Windows` and relaunch — works again, until the container runs
   and the bit comes back.

## Expected
Either the mounts check tolerates/clears the setgid bit itself (since it's coming
from the VM's own Samba service, not the user), or the failure surfaces a specific,
actionable error instead of a generic "Failed to start Windows VM!".

## System details
Omarchy 4.0.2-1, Hyprland 0.56.2, Arch Linux. Diagnostic log gathered via
`omarchy-debug --no-sudo --print` and available on request.

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.