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

windows vm launch fails: chmod 0700 no longer clears setgid on ~/Windows (coreutils 9.11), which dockur resets to 2777

Reported by yeet-bits · filed Sep 11, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #9334 (R-1173). 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

windows vm launch fails: chmod 0700 no longer clears setgid on ~/Windows (coreutils 9.11), which dockur resets to 2777revision 1 · captured 2026-10-04 12:10 UTC via poll

What happened

omarchy windows vm launch fails with only:

Starting Windows VM (this may prompt for authorization)...
❌ Failed to start Windows VM!
   Try checking: omarchy-windows-vm status

The container never starts, and no reason is printed (the failure happens inside the pkexec-elevated helper, whose stderr is not surfaced).

Root cause

A chain of three things:

  1. dockur/windows sets the shared directory on the host to mode 2777 (setgid) whenever the VM runs. So after any successful VM session, ~/Windows (the /shared bind source) is left with the setgid bit set.
  1. GNU coreutils 9.11 (currently on Arch) changed numeric chmod semantics for directories. chmod 0700 no longer clears the set-group-ID bit; man chmod now says:
To clear these bits for directories with a numeric mode requires an additional leading zero like 00755, leading minus like -6000, or leading equals like =755.

Verified empirically on coreutils 9.11-2:

   $ mkdir d && chmod 2700 d && chmod 0700 d && stat -c %a d
   2700          # silently retained
   $ chmod =700 d && stat -c %a d
   700
  1. `omarchy-windows-vm` uses `chmod 0700` and then strictly verifies `mode == 700`. In prepare_caller_mounts() (omarchy-windows-vm line ~583 in omarchy 4.0.3-1):
   chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || ...
   ...
   [[ $storage_mode != 700 || $shared_mode != 700 ]] && return 1   # fails here

The chmod succeeds, but the setgid bit survives it, so the privacy verification aborts the launch.

Because of (1), this is a guaranteed recurring failure: every launch after a successful VM run fails until the user manually clears the bit.

Steps to reproduce

chmod 2777 ~/Windows        # or just run the Windows VM once — dockur does this for you
omarchy windows vm launch   # → ❌ Failed to start Windows VM!

Suggested fix

Use a form that explicitly clears the special bits. Affected sites in omarchy-windows-vm (4.0.3-1):

  • line ~583 in prepare_caller_mounts(): chmod 0700 -- ... → chmod 00700 -- ... (or chmod =700)
  • line ~1018 in the install path: same change
  • line ~1061 in write_credentials(): same change (latent, ~/.config/windows is unlikely to carry setgid)

Verified workaround for users hitting this: chmod g-s ~/Windows.

System details

  • Omarchy: 4.0.3-1
  • Kernel: 7.2.3-arch1-3
  • coreutils: 9.11-2
  • Docker: 29.7.2, dockur/windows image
  • Storage: btrfs, VM disk at ~/.windows (data.img, 64G)
View raw text
## What happened

`omarchy windows vm launch` fails with only:

```
Starting Windows VM (this may prompt for authorization)...
❌ Failed to start Windows VM!
   Try checking: omarchy-windows-vm status
```

The container never starts, and no reason is printed (the failure happens inside the pkexec-elevated helper, whose stderr is not surfaced).

## Root cause

A chain of three things:

1. **dockur/windows sets the shared directory on the host to mode 2777 (setgid) whenever the VM runs.** So after any *successful* VM session, `~/Windows` (the `/shared` bind source) is left with the setgid bit set.

2. **GNU coreutils 9.11 (currently on Arch) changed numeric chmod semantics for directories.** `chmod 0700` no longer clears the set-group-ID bit; `man chmod` now says:

   > To clear these bits for directories with a numeric mode requires an additional leading zero like 00755, leading minus like -6000, or leading equals like =755.

   Verified empirically on coreutils 9.11-2:

   ```
   $ mkdir d && chmod 2700 d && chmod 0700 d && stat -c %a d
   2700          # silently retained
   $ chmod =700 d && stat -c %a d
   700
   ```

3. **`omarchy-windows-vm` uses `chmod 0700` and then strictly verifies `mode == 700`.** In `prepare_caller_mounts()` (omarchy-windows-vm line ~583 in omarchy 4.0.3-1):

   ```bash
   chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || ...
   ...
   [[ $storage_mode != 700 || $shared_mode != 700 ]] && return 1   # fails here
   ```

   The chmod succeeds, but the setgid bit survives it, so the privacy verification aborts the launch.

Because of (1), this is a **guaranteed recurring failure**: every launch after a successful VM run fails until the user manually clears the bit.

## Steps to reproduce

```
chmod 2777 ~/Windows        # or just run the Windows VM once — dockur does this for you
omarchy windows vm launch   # → ❌ Failed to start Windows VM!
```

## Suggested fix

Use a form that explicitly clears the special bits. Affected sites in `omarchy-windows-vm` (4.0.3-1):

- line ~583 in `prepare_caller_mounts()`: `chmod 0700 -- ...` → `chmod 00700 -- ...` (or `chmod =700`)
- line ~1018 in the install path: same change
- line ~1061 in `write_credentials()`: same change (latent, `~/.config/windows` is unlikely to carry setgid)

Verified workaround for users hitting this: `chmod g-s ~/Windows`.

## System details

- Omarchy: 4.0.3-1
- Kernel: 7.2.3-arch1-3
- coreutils: 9.11-2
- Docker: 29.7.2, dockur/windows image
- Storage: btrfs, VM disk at ~/.windows (data.img, 64G)

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.