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

omarchy windows vm: fails to launch after first run — setgid/shared dir rejected (chmod 0700 doesn't clear setgid)

Reported by iainlennox · filed Sep 9, 2026Closed upstream on 2026-09-09 by its own reporter iainlennox, as a duplicate of #10983 (R-4984). 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: fails to launch after first run — setgid/shared dir rejected (chmod 0700 doesn't clear setgid)revision 1 · captured 2026-10-04 12:10 UTC via poll

Summary

omarchy windows vm installs Windows successfully on the first run, but every subsequent `launch` fails immediately with Failed to start Windows VM! — before QEMU ever starts. From a terminal the command fails silently (exit 1); from a GUI/tray launch it shows the critical notification.

What happens

  1. First install / first launch works. The virtual disk is created at ~/.windows/data.img (via the bind anchor also visible at /var/lib/omarchy/windows/mounts/users/1000/storage).
  2. Stop/close the VM.
  3. The next omarchy windows vm launch aborts before VMs start. No error on stdout; exit 1.

Root cause

assert_mounts_safe → prepare_caller_mounts in /usr/bin/omarchy-windows-vm requires the legacy shared source (~/Windows) and the /shared mount anchor (/var/lib/omarchy/windows/mounts/users/1000/shared) to be exactly mode 0700 and owned by root:root:

assert_boundary_dir .../shared 0      # expects owner 0, no group/world-write
...
chmod 0700 -- /proc/<fd>/...
[[ $mode != 700 ]] && return 1

The dockurr/windows container creates the shared folder as 2777 (setgid + world-writable), owned by uid 1000, on every run. After the first run:

  • ~/Windows → iainlennox:iainlennox 2777
  • /var/lib/omarchy/windows/mounts/users/1000/shared → iainlennox:iainlennox 2777

The script then runs chmod 0700 on these paths, but that does not clear the setgid bit, so the mode remains 2700, and the exact-equality validation fails. Combined with the /shared anchor being owned by uid 1000, assert_mounts_safe returns 1 and up_wait exits 1. Net result: the VM installs once and can never launch again without manual intervention.

chmod quirk (observed)

In this environment a numeric chmod 0700 leaves the setgid bit set (mode stays 2700), while chmod g-s clears it:

chmod 2700 /tmp/t && chmod 700 /tmp/t      # mode stays 2700
chmod g-s /tmp/t                            # mode becomes 700

Steps to reproduce

  1. omarchy windows vm install (or first launch) — Windows installs and boots once.
  2. Stop/close the VM.
  3. omarchy windows vm launch → Failed to start Windows VM! (exit 1).

Workaround

Must be re-applied after every dockur run, because the container re-setgids the shared dirs each time:

chmod g-s ~/Windows
pkexec chown root:root /var/lib/omarchy/windows/mounts/users/1000/shared
omarchy windows vm launch

Expected behaviour

launch should recognise the existing installed disk and start it, tolerating dockur's 2777 shared-folder mode (or normalise it with g-s). The shared folder is intentionally world-writable/setgid for the container, so the validation should not require an exact module of 0700.

System

  • Omarchy 4.0.2-1
  • Arch Linux, kernel 7.1.9-arch1-2
  • 13th Gen Intel Core i5-1335U, 15 GiB RAM, Intel Iris Xe, btrfs
  • Docker 29.7.2, Docker Compose 5.5.0, dockurr/windows:latest
View raw text
## Summary

`omarchy windows vm` installs Windows successfully on the first run, but **every subsequent `launch` fails immediately** with `Failed to start Windows VM!` — before QEMU ever starts. From a terminal the command fails silently (exit 1); from a GUI/tray launch it shows the critical notification.

## What happens

1. First `install` / first `launch` works. The virtual disk is created at `~/.windows/data.img` (via the bind anchor also visible at `/var/lib/omarchy/windows/mounts/users/1000/storage`).
2. Stop/close the VM.
3. The next `omarchy windows vm launch` aborts before VMs start. No error on stdout; `exit 1`.

## Root cause

`assert_mounts_safe` → `prepare_caller_mounts` in `/usr/bin/omarchy-windows-vm` requires the legacy shared source (`~/Windows`) and the `/shared` mount anchor (`/var/lib/omarchy/windows/mounts/users/1000/shared`) to be **exactly** mode `0700` and owned by `root:root`:

```
assert_boundary_dir .../shared 0      # expects owner 0, no group/world-write
...
chmod 0700 -- /proc/<fd>/...
[[ $mode != 700 ]] && return 1
```

The `dockurr/windows` container creates the shared folder as `2777` (setgid + world-writable), owned by uid 1000, **on every run**. After the first run:

- `~/Windows` → `iainlennox:iainlennox 2777`
- `/var/lib/omarchy/windows/mounts/users/1000/shared` → `iainlennox:iainlennox 2777`

The script then runs `chmod 0700` on these paths, but that does **not** clear the setgid bit, so the mode remains `2700`, and the exact-equality validation fails. Combined with the `/shared` anchor being owned by uid 1000, `assert_mounts_safe` returns 1 and `up_wait` exits 1. Net result: the VM installs once and can never launch again without manual intervention.

### chmod quirk (observed)

In this environment a numeric `chmod 0700` leaves the setgid bit set (mode stays `2700`), while `chmod g-s` clears it:

```
chmod 2700 /tmp/t && chmod 700 /tmp/t      # mode stays 2700
chmod g-s /tmp/t                            # mode becomes 700
```

## Steps to reproduce

1. `omarchy windows vm install` (or first `launch`) — Windows installs and boots once.
2. Stop/close the VM.
3. `omarchy windows vm launch` → `Failed to start Windows VM!` (exit 1).

### Workaround

Must be re-applied **after every** dockur run, because the container re-setgids the shared dirs each time:

```
chmod g-s ~/Windows
pkexec chown root:root /var/lib/omarchy/windows/mounts/users/1000/shared
omarchy windows vm launch
```

## Expected behaviour

`launch` should recognise the existing installed disk and start it, tolerating dockur's `2777` shared-folder mode (or normalise it with `g-s`). The shared folder is intentionally world-writable/setgid for the container, so the validation should not require an exact module of `0700`.

## System

- Omarchy `4.0.2-1`
- Arch Linux, kernel `7.1.9-arch1-2`
- 13th Gen Intel Core i5-1335U, 15 GiB RAM, Intel Iris Xe, btrfs
- Docker `29.7.2`, Docker Compose `5.5.0`, `dockurr/windows:latest`

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.