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

omarchy-windows-vm: launch/migration fails when ~/Windows has setgid bit (chmod 0700 keeps it, check requires 700)

Reported by Bauti03czx · filed Sep 20, 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/migration fails when ~/Windows has setgid bit (chmod 0700 keeps it, check requires 700)revision 1 · captured 2026-09-28 21:23 UTC via poll

Summary

omarchy-windows-vm refuses to start (or migrate) an existing Windows VM whenever ~/Windows (the /shared folder) carries the setgid bit. The script hardens the two data directories with chmod 0700 and then requires the mode to be exactly 700, but GNU chmod preserves a directory's setuid/setgid bits when given a 4-digit numeric mode, so 2700 stays 2700 and the check fails.

This is easy to hit: the dockurr/windows image runs chmod 2777 /shared on every boot when the shared folder is empty (/run/samba.sh), so after the first successful boot every subsequent launch fails with "Failed to start Windows VM" and no useful error (the privileged step exits silently).

Environment

  • Omarchy 4.0.2-1 (bin/omarchy-windows-vm, same code on current master)
  • coreutils chmod (Arch), btrfs /home
  • Existing VM created on Omarchy 3.x with the old ~/.config/windows/docker-compose.yml

Steps to reproduce

  1. Have a working Windows VM. Leave ~/Windows empty (default).
  2. omarchy-windows-vm launch once → VM boots, dockur runs chmod 2777 on /shared → ~/Windows is now 2777.
  3. Close RDP (VM stops). omarchy-windows-vm launch again.

Result: ❌ Failed to start Windows VM!. Inside the privileged up_wait, prepare_caller_mounts does chmod 0700 on the pinned fd, mode becomes 2700, [[ $storage_mode != 700 || $shared_mode != 700 ]] fires and it returns 1. mounted_leaf_matches has the same $mode == 700 check.

For users upgrading from Omarchy 3 with a setgid ~/Windows, the very first migrate_legacy_compose fails the same way and the menu just says "Windows VM not configured", which looks like the VM data was lost.

Root cause

From info chmod: "For directories, chmod preserves set-user-ID and set-group-ID bits unless you explicitly specify otherwise ... To clear these bits for directories with a numeric mode requires an additional leading zero like 00755, or =755."

Affected lines (master):
- prepare_caller_mounts: chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" followed by a strict 700 comparison
- prepare_user_mount_sources: chmod 0700 -- "$storage" "$shared"
- write_credentials: chmod 0700 "$dir" (harmless, no strict check after it)

Quick demo:

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

Suggested fix

Use a mode that actually clears the special bits, e.g. chmod 00700 or chmod u=rwx,go=,s-s (=700 also works), at the three sites above. Alternatively compare against the mode with special bits masked out, but clearing them seems better given the intent of the hardening.

Optional: since dockur re-applies 2777 whenever /shared is empty, it may also be worth dropping a placeholder file into ~/Windows at install time so the mode stays stable across boots.

Workaround

chmod g-s ~/Windows
touch ~/Windows/.keep   # keeps dockur from re-adding setgid on next boot
omarchy-windows-vm launch
View raw text
## Summary

`omarchy-windows-vm` refuses to start (or migrate) an existing Windows VM whenever `~/Windows` (the `/shared` folder) carries the setgid bit. The script hardens the two data directories with `chmod 0700` and then requires the mode to be exactly `700`, but GNU chmod preserves a directory's setuid/setgid bits when given a 4-digit numeric mode, so `2700` stays `2700` and the check fails.

This is easy to hit: the `dockurr/windows` image runs `chmod 2777 /shared` on every boot when the shared folder is empty (`/run/samba.sh`), so after the first successful boot every subsequent `launch` fails with "Failed to start Windows VM" and no useful error (the privileged step exits silently).

## Environment

- Omarchy 4.0.2-1 (`bin/omarchy-windows-vm`, same code on current master)
- coreutils chmod (Arch), btrfs `/home`
- Existing VM created on Omarchy 3.x with the old `~/.config/windows/docker-compose.yml`

## Steps to reproduce

1. Have a working Windows VM. Leave `~/Windows` empty (default).
2. `omarchy-windows-vm launch` once → VM boots, dockur runs `chmod 2777` on `/shared` → `~/Windows` is now `2777`.
3. Close RDP (VM stops). `omarchy-windows-vm launch` again.

Result: `❌ Failed to start Windows VM!`. Inside the privileged `up_wait`, `prepare_caller_mounts` does `chmod 0700` on the pinned fd, mode becomes `2700`, `[[ $storage_mode != 700 || $shared_mode != 700 ]]` fires and it returns 1. `mounted_leaf_matches` has the same `$mode == 700` check.

For users upgrading from Omarchy 3 with a setgid `~/Windows`, the very first `migrate_legacy_compose` fails the same way and the menu just says "Windows VM not configured", which looks like the VM data was lost.

## Root cause

From `info chmod`: *"For directories, chmod preserves set-user-ID and set-group-ID bits unless you explicitly specify otherwise ... To clear these bits for directories with a numeric mode requires an additional leading zero like 00755, or =755."*

Affected lines (master):
- `prepare_caller_mounts`: `chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"` followed by a strict `700` comparison
- `prepare_user_mount_sources`: `chmod 0700 -- "$storage" "$shared"`
- `write_credentials`: `chmod 0700 "$dir"` (harmless, no strict check after it)

Quick demo:

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

## Suggested fix

Use a mode that actually clears the special bits, e.g. `chmod 00700` or `chmod u=rwx,go=,s-s` (`=700` also works), at the three sites above. Alternatively compare against the mode with special bits masked out, but clearing them seems better given the intent of the hardening.

Optional: since dockur re-applies `2777` whenever `/shared` is empty, it may also be worth dropping a placeholder file into `~/Windows` at install time so the mode stays stable across boots.

## Workaround

```
chmod g-s ~/Windows
touch ~/Windows/.keep   # keeps dockur from re-adding setgid on next boot
omarchy-windows-vm launch
```

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.