Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Windows VM launch fails silently when ~/Windows is setgid (chmod 0700 leaves 2700)
Reported by atoslins · filed Sep 17, 2026Closed upstream on 2026-09-18 by its own reporter atoslins, as a duplicate of #9630 (R-4817). GitHub close reason: not_planned.
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
System details
Intel Core i5-13420H, NVIDIA RTX 3050 (hybrid), Omarchy 4.0.4, coreutils 9.11
What's wrong?
omarchy windows vm launch fails silently (exit 1, no message, no container) whenever ~/Windows has the setgid bit. From the app launcher nothing happens at all after the polkit prompt, because the .desktop entry runs with Terminal=false.
Cause
prepare_caller_mounts in bin/omarchy-windows-vm hardens both sources and then requires the mode to be exactly 700:
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || { ... }
...
if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
...
return 1 # no message
fiGNU chmod with a numeric mode does not clear setuid/setgid on directories, so a 2700 directory stays 2700 and the check fails:
$ mkdir d && chmod 2700 d && chmod 0700 d && stat -c %a d
2700mounted_leaf_matches has the same exact-700 requirement.
Where the setgid bit comes from
The dockurr/windows image sets it itself. /run/samba.sh inside the container runs chmod 2777 "$dir" on /shared when the directory is empty ("Keep newly created content in the shared group through the setgid bit"). ~/Windows is empty on a fresh install, so the first boot leaves it setgid, and the next launch that has to recreate the bind anchors (i.e. after any reboot) hits this. It is not specific to my setup.
Steps to reproduce
- Install the VM (
omarchy windows vm install) with an empty~/Windows, or justchmod g+s ~/Windowson an existing install. - Reboot (so the bind mounts under
/var/lib/omarchy/windows/mountsare gone). - Launch "Windows" from the menu, authorize the polkit prompt.
Result: nothing happens. pkexec /usr/bin/omarchy-windows-vm __priv up exits 1 with empty output; the docker journal is empty because docker compose up is never reached.
Expected: the VM starts.
Workaround
chmod g-s ~/Windows, then launch again. Verified: VM boots and RDP connects.
Fix
#12323 replaces both chmod 0700 calls with chmod u=rwx,go=,a-s, adds an error message to the mode-mismatch branch that currently returns 1 silently, and adds regression tests. #12264 (folding #9414) carries the same chmod change bundled with an unrelated launcher change.
View raw text
### System details
Intel Core i5-13420H, NVIDIA RTX 3050 (hybrid), Omarchy 4.0.4, coreutils 9.11
### What's wrong?
`omarchy windows vm launch` fails silently (exit 1, no message, no container) whenever `~/Windows` has the setgid bit. From the app launcher nothing happens at all after the polkit prompt, because the `.desktop` entry runs with `Terminal=false`.
**Cause**
`prepare_caller_mounts` in `bin/omarchy-windows-vm` hardens both sources and then requires the mode 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
...
return 1 # no message
fi
```
GNU `chmod` with a numeric mode does not clear setuid/setgid on directories, so a `2700` directory stays `2700` and the check fails:
```
$ mkdir d && chmod 2700 d && chmod 0700 d && stat -c %a d
2700
```
`mounted_leaf_matches` has the same exact-`700` requirement.
**Where the setgid bit comes from**
The `dockurr/windows` image sets it itself. `/run/samba.sh` inside the container runs `chmod 2777 "$dir"` on `/shared` when the directory is empty ("Keep newly created content in the shared group through the setgid bit"). `~/Windows` is empty on a fresh install, so the first boot leaves it setgid, and the next launch that has to recreate the bind anchors (i.e. after any reboot) hits this. It is not specific to my setup.
**Steps to reproduce**
1. Install the VM (`omarchy windows vm install`) with an empty `~/Windows`, or just `chmod g+s ~/Windows` on an existing install.
2. Reboot (so the bind mounts under `/var/lib/omarchy/windows/mounts` are gone).
3. Launch "Windows" from the menu, authorize the polkit prompt.
Result: nothing happens. `pkexec /usr/bin/omarchy-windows-vm __priv up` exits 1 with empty output; the docker journal is empty because `docker compose up` is never reached.
Expected: the VM starts.
**Workaround**
`chmod g-s ~/Windows`, then launch again. Verified: VM boots and RDP connects.
**Fix**
#12323 replaces both `chmod 0700` calls with `chmod u=rwx,go=,a-s`, adds an error message to the mode-mismatch branch that currently returns 1 silently, and adds regression tests. #12264 (folding #9414) carries the same `chmod` change bundled with an unrelated launcher change.
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.