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

omarchy-windows-vm launch fails on every run after the first: chmod 0700 leaves setgid on ~/Windows

Reported by jonspinks · filed Sep 25, 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 on every run after the first: chmod 0700 leaves setgid on ~/Windowsrevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

Omarchy 4.0.4-1, ThinkStation P3 Ultra SFF G2, Intel Core Ultra 7 265K, linux 7.2.5-3-omarchy. Windows VM installed with omarchy-windows-vm install.

What happened

After the Windows VM has run once, every later omarchy-windows-vm launch fails. The only output is:

❌ Failed to start Windows VM!
   Try checking: omarchy-windows-vm status

pkexec omarchy-windows-vm __priv up_wait exits 1 with no message, and Docker is never started.

Cause

prepare_caller_mounts (bin/omarchy-windows-vm, around line 583) normalises the two source folders and then requires them to be exactly 700:

chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"
...
if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then

The container's startup sets the shared folder (~/Windows, mounted as /shared) to 2777, which includes setgid. On a directory, GNU chmod with a 4-digit numeric mode leaves an existing setgid bit alone, so chmod 0700 produces 2700. The check then fails, and that path returns 1 without printing anything.

The folder's mode, watched once a second across a launch:

11:47:50 start mode=700
11:50:18 pkexec … omarchy-windows-vm __priv up_wait
11:50:19 mode 700 -> 2777      (container running)

The chmod behaviour on its own:

$ mkdir d && chmod 2777 d && chmod 0700 d && stat -c %a d
2700
$ chmod 00700 d && stat -c %a d
700

A bash -x trace of the failing __priv up_wait ends with:

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

Steps to reproduce

  1. omarchy-windows-vm install, then omarchy-windows-vm launch; the first launch works.
  2. Close the RDP window (the VM stops), or run omarchy-windows-vm stop.
  3. stat -c %a ~/Windows shows 2700.
  4. omarchy-windows-vm launch fails as above.

chmod g-s ~/Windows makes the next launch work, and the one after it fails again.

Suggested fix

Use chmod 00700, which clears setuid and setgid on directories with GNU coreutils, in prepare_caller_mounts and in the matching call in prepare_user_mount_sources (around line 1018). It would also help to print a message when the mode check fails, such as "VM data folder must be mode 700, found $shared_mode", so that it doesn't fail silently.

View raw text
### System details

Omarchy 4.0.4-1, ThinkStation P3 Ultra SFF G2, Intel Core Ultra 7 265K, linux 7.2.5-3-omarchy. Windows VM installed with `omarchy-windows-vm install`.

### What happened

After the Windows VM has run once, every later `omarchy-windows-vm launch` fails. The only output is:

```
❌ Failed to start Windows VM!
   Try checking: omarchy-windows-vm status
```

`pkexec omarchy-windows-vm __priv up_wait` exits 1 with no message, and Docker is never started.

### Cause

`prepare_caller_mounts` (bin/omarchy-windows-vm, around line 583) normalises the two source folders and then requires them to be exactly `700`:

```bash
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"
...
if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
```

The container's startup sets the shared folder (`~/Windows`, mounted as `/shared`) to `2777`, which includes setgid. On a directory, GNU `chmod` with a 4-digit numeric mode leaves an existing setgid bit alone, so `chmod 0700` produces `2700`. The check then fails, and that path returns 1 without printing anything.

The folder's mode, watched once a second across a launch:

```
11:47:50 start mode=700
11:50:18 pkexec … omarchy-windows-vm __priv up_wait
11:50:19 mode 700 -> 2777      (container running)
```

The chmod behaviour on its own:

```
$ mkdir d && chmod 2777 d && chmod 0700 d && stat -c %a d
2700
$ chmod 00700 d && stat -c %a d
700
```

A `bash -x` trace of the failing `__priv up_wait` ends with:

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

### Steps to reproduce

1. `omarchy-windows-vm install`, then `omarchy-windows-vm launch`; the first launch works.
2. Close the RDP window (the VM stops), or run `omarchy-windows-vm stop`.
3. `stat -c %a ~/Windows` shows `2700`.
4. `omarchy-windows-vm launch` fails as above.

`chmod g-s ~/Windows` makes the next launch work, and the one after it fails again.

### Suggested fix

Use `chmod 00700`, which clears setuid and setgid on directories with GNU coreutils, in `prepare_caller_mounts` and in the matching call in `prepare_user_mount_sources` (around line 1018). It would also help to print a message when the mode check fails, such as `"VM data folder must be mode 700, found $shared_mode"`, so that it doesn't fail silently.

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.