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

omarchy windows vm launch fails silently when ~/Windows has the setgid bit (mode 2700/2777)

Reported by ozkanaltunboga · filed Oct 3, 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 when ~/Windows has the setgid bit (mode 2700/2777)revision 1 · captured 2026-10-03 13:19 UTC via poll

Summary

omarchy windows vm launch fails with only "Failed to start Windows VM!" (no reason) after the VM has been run once, because ~/Windows is left with the setgid bit set (mode 2700/2777) and omarchy-windows-vm requires the shared dir to be exactly mode 700.

Steps to reproduce

  1. omarchy windows vm launch (VM starts, container omarchy-windows runs).
  2. While running, the dockurr/windows container changes the host shared dir: stat -c %a ~/Windows -> 2777.
  3. Stop the VM.
  4. omarchy windows vm launch again -> Failed to start Windows VM! with no explanation.

Cause

In prepare_caller_mounts (omarchy-windows-vm, ~line 583) the script runs chmod 0700 on the storage and shared dirs, then checks [[ $storage_mode != 700 || $shared_mode != 700 ]]. A 4-digit-less numeric chmod does not clear the setgid bit on a directory, so stat -Lc %a still reports 2700 and the check returns 1. Running the privileged step by hand shows it:

sudo env PKEXEC_UID=1000 bash -x /usr/bin/omarchy-windows-vm __priv up_wait
...
++ stat -Lc %a /proc/.../fd/12
+ shared_mode=2700
+ [[ 2700 != 700 ]]
+ return 1

pkexec swallows this, so the user only sees the generic failure message.

Suggested fix

  • Use chmod 0700 -> chmod u=rwx,go=,g-s (or chmod 00700, which clears special bits on directories on Linux), so the setgid bit is dropped.
  • Optionally print the reason (e.g. "shared dir has unexpected mode 2700") instead of failing silently.

Workaround

A user service that runs chmod g-s ~/Windows whenever the mode changes (inotify on ~/Windows).

System

  • Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy
  • Intel Core i7-1355U, 16 GB RAM, btrfs root
  • dockurr/windows image (Windows 11), existing VM data in ~/.windows
View raw text
### Summary

`omarchy windows vm launch` fails with only "Failed to start Windows VM!" (no reason) after the VM has been run once, because `~/Windows` is left with the setgid bit set (mode `2700`/`2777`) and `omarchy-windows-vm` requires the shared dir to be exactly mode `700`.

### Steps to reproduce

1. `omarchy windows vm launch` (VM starts, container `omarchy-windows` runs).
2. While running, the dockurr/windows container changes the host shared dir: `stat -c %a ~/Windows` -> `2777`.
3. Stop the VM.
4. `omarchy windows vm launch` again -> `Failed to start Windows VM!` with no explanation.

### Cause

In `prepare_caller_mounts` (`omarchy-windows-vm`, ~line 583) the script runs `chmod 0700` on the storage and shared dirs, then checks `[[ $storage_mode != 700 || $shared_mode != 700 ]]`. A 4-digit-less numeric `chmod` does not clear the setgid bit on a directory, so `stat -Lc %a` still reports `2700` and the check returns 1. Running the privileged step by hand shows it:

```
sudo env PKEXEC_UID=1000 bash -x /usr/bin/omarchy-windows-vm __priv up_wait
...
++ stat -Lc %a /proc/.../fd/12
+ shared_mode=2700
+ [[ 2700 != 700 ]]
+ return 1
```

`pkexec` swallows this, so the user only sees the generic failure message.

### Suggested fix

- Use `chmod 0700` -> `chmod u=rwx,go=,g-s` (or `chmod 00700`, which clears special bits on directories on Linux), so the setgid bit is dropped.
- Optionally print the reason (e.g. "shared dir has unexpected mode 2700") instead of failing silently.

### Workaround

A user service that runs `chmod g-s ~/Windows` whenever the mode changes (inotify on `~/Windows`).

### System

- Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy
- Intel Core i7-1355U, 16 GB RAM, btrfs root
- dockurr/windows image (Windows 11), existing VM data in `~/.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.