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

omarchy-windows-vm launch silently fails when ~/Windows has setgid bit

Reported by leisor · filed Sep 24, 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 silently fails when ~/Windows has setgid bitrevision 1 · captured 2026-09-28 21:23 UTC via poll

Summary

Launching the Windows VM from the Super+Space menu fails with a generic
"Failed to start Windows VM" notification and no log output whenever the
caller's ~/Windows directory has any bit set outside of 0700 — most
commonly, the setgid bit (mode 2700).

The install completes because prepare_user_mount_sources runs as the user
and clears the setgid bit; the failure only surfaces on launch / up,
where the script does the chmod as root via pkexec. Linux preserves the
setgid bit on directories when a non-owner changes the mode via a numeric
chmod, so root's chmod 0700 succeeds but leaves the mode at 2700. The
subsequent [[ $shared_mode != 700 ]] check then fails silently (return 1,
no stderr), and the launcher surfaces that as the cryptic notification.

Reproduction

  1. omarchy-windows-vm install (succeeds, VM boots).
  2. As the user: chmod 2750 ~/Windows (or any mode with the setgid bit set

on the group exec bit — 2700, 2750, 2755, etc.).
3. omarchy-windows-vm launch from the Super+Space menu.
4. Observe: a "Failed to start Windows VM" desktop notification; the
privileged action exits with code 1 and no error message on stderr.
5. omarchy-windows-vm status still reports RUNNING, because the container
was never told to do anything — the script bailed before dc up -d.

bash -x on the __priv up path makes the silent failure obvious:

+ chmod 0700 -- /proc/$BASHPID/fd/11 /proc/$BASHPID/fd/12
+ storage_mode=700
+ shared_mode=2700
+ [[ 2700 != 700 ]]
+ return 1

Expected

Either a clear error message pointing at the bad permissions (the script
already does this for almost every other validation failure — see
assert_compose_trusted, mounted_leaf_matches, prepare_mount_anchor),
or the chmod step should itself succeed even when run as root over a
user-owned directory with a stray setgid bit.

Suggested fix

In prepare_caller_mounts (around line 583), strip the setgid bit before
the numeric chmod, or fall back to a mode string that does not preserve it:

chmod g-s -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" &&
  chmod u=rwx,go= -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || { ... }

A more general improvement: every || return 1 in prepare_caller_mounts,
assert_compose_trusted, mounted_leaf_matches, and bind_mount_leaf
should log a diagnostic before returning. Right now the script has detailed
error messages for the "happy" paths and silent returns for several of the
"actually wrong" paths, which makes diagnosis hard for end users.

Environment

  • Omarchy 4.0.4-1
  • btrfs root filesystem (/home is subvolid 257)
  • User not in the docker group (default Omarchy posture, uses pkexec)
  • ~/dev/kvm, ~/dev/net/tun present and accessible
  • Reproduced on Omarchy 4.0.4-1 with dockurr/windows image
View raw text
## Summary

Launching the Windows VM from the Super+Space menu fails with a generic
"Failed to start Windows VM" notification and no log output whenever the
caller's `~/Windows` directory has any bit set outside of `0700` — most
commonly, the setgid bit (mode `2700`).

The install completes because `prepare_user_mount_sources` runs as the user
and clears the setgid bit; the failure only surfaces on `launch` / `up`,
where the script does the chmod as root via `pkexec`. Linux preserves the
setgid bit on directories when a non-owner changes the mode via a numeric
chmod, so root's `chmod 0700` succeeds but leaves the mode at `2700`. The
subsequent `[[ $shared_mode != 700 ]]` check then fails silently (return 1,
no stderr), and the launcher surfaces that as the cryptic notification.

## Reproduction

1. `omarchy-windows-vm install` (succeeds, VM boots).
2. As the user: `chmod 2750 ~/Windows` (or any mode with the setgid bit set
   on the group exec bit — `2700`, `2750`, `2755`, etc.).
3. `omarchy-windows-vm launch` from the Super+Space menu.
4. Observe: a "Failed to start Windows VM" desktop notification; the
   privileged action exits with code 1 and **no error message** on stderr.
5. `omarchy-windows-vm status` still reports RUNNING, because the container
   was never told to do anything — the script bailed before `dc up -d`.

`bash -x` on the `__priv up` path makes the silent failure obvious:

```
+ chmod 0700 -- /proc/$BASHPID/fd/11 /proc/$BASHPID/fd/12
+ storage_mode=700
+ shared_mode=2700
+ [[ 2700 != 700 ]]
+ return 1
```

## Expected

Either a clear error message pointing at the bad permissions (the script
already does this for almost every other validation failure — see
`assert_compose_trusted`, `mounted_leaf_matches`, `prepare_mount_anchor`),
or the chmod step should itself succeed even when run as root over a
user-owned directory with a stray setgid bit.

## Suggested fix

In `prepare_caller_mounts` (around line 583), strip the setgid bit before
the numeric chmod, or fall back to a mode string that does not preserve it:

```bash
chmod g-s -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" &&
  chmod u=rwx,go= -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || { ... }
```

A more general improvement: every `|| return 1` in `prepare_caller_mounts`,
`assert_compose_trusted`, `mounted_leaf_matches`, and `bind_mount_leaf`
should log a diagnostic before returning. Right now the script has detailed
error messages for the "happy" paths and silent returns for several of the
"actually wrong" paths, which makes diagnosis hard for end users.

## Environment

- Omarchy 4.0.4-1
- btrfs root filesystem (`/home` is subvolid 257)
- User not in the `docker` group (default Omarchy posture, uses `pkexec`)
- ~`/dev/kvm`, ~`/dev/net/tun` present and accessible
- Reproduced on Omarchy 4.0.4-1 with `dockurr/windows` image

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.