## Summary

The Windows VM starts once, then **permanently** fails to start again with a bare
`❌ Failed to start Windows VM!` and no diagnostic — as long as the shared folder
`~/Windows` is left empty.

The container sets the setgid bit on the shared folder by design. The mount
preflight in `omarchy-windows-vm` then tries to normalise the mode back to `0700`,
but that `chmod` is a silent no-op, because **GNU `chmod` does not clear
setuid/setgid on a _directory_ when given a 4-digit octal mode**. The mode check
immediately after therefore fails forever.

The VM never reaches Docker — `docker.service` is not even contacted.

## The cycle

1. `omarchy-windows-vm launch` pins `~/Windows` at mode `700` and starts the container.
2. `dockur/windows` sets up the Samba share and, when the share directory is empty,
   deliberately sets setgid on it — [`src/samba.sh`](https://github.com/dockur/windows/blob/master/src/samba.sh#L156-L161):

   ```bash
   # Keep newly created content in the shared group through the setgid bit.
   if ! chmod 2777 "$dir"; then
   ```

   Through the bind mount this lands on the user's `~/Windows`, which becomes `2777`.
3. Next `launch`: `prepare_caller_mounts()` runs `chmod 0700`, which brings it to
   `2700` — the setgid bit is **retained** — and then rejects it for not being `700`.
4. Every subsequent launch fails identically. There is no way past it using the tool.

Only an *empty* `~/Windows` is affected: `samba.sh` guards the `chmod 2777` with
`[[ "$empty" == "Y" ]]`. Putting a file in the share masks the bug, which is
probably why it isn't universally reported.

## Root cause in omarchy

`bin/omarchy-windows-vm`, `prepare_caller_mounts()` (line numbers from `quattro` @ HEAD,
which is byte-identical to the 4.0.2-1 package):

```bash
# L580-586
# Privacy is an explicit preflight step for both already-pinned sources, not
# a side effect halfway through the two-mount transaction. Old umask-022
# installs are hardened together before either Docker-facing anchor changes.
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || { ... }

# L588-594
storage_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$storage_fd" 2>/dev/null) || storage_mode=""
shared_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$shared_fd" 2>/dev/null) || shared_mode=""
if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
  exec {storage_fd}<&-
  exec {shared_fd}<&-
  return 1
fi
```

`chmod -v` shows the no-op verbatim: `mode of '…' retained as 2700 (rwx--S---)`.
`stat -Lc '%a'` then returns `2700`, the `!= 700` comparison fails, and
`prepare_caller_mounts` returns 1. The normalisation can never achieve what its
comment describes.

This is directory-specific — `chmod 0700` on a *regular file* clears setgid correctly.
Per the coreutils manual: "Additional restrictions may cause the set-user-ID and
set-group-ID bits of MODE or REF_FILE to be ignored."

The same 4-digit pattern is at L1018 (`prepare_user_mount_sources`) and L1061.
`mounted_leaf_matches()` at L518 carries the same exact-match assumption
(`$mode == 700`).

## Reproduction

The `chmod` behaviour on its own, no Omarchy needed:

```bash
d=$(mktemp -d); mkdir "$d/shared"; chmod 2777 "$d/shared"
chmod 0700 -- "$d/shared"; stat -Lc '%a' "$d/shared"   # 2700  <-- exits 0, setgid survives
chmod 00700 -- "$d/shared"; stat -Lc '%a' "$d/shared"  # 700   <-- cleared
```

End to end (verified on this machine, both directions):

```bash
stat -Lc '%a' ~/Windows        # 2700 after a previous VM run
omarchy-windows-vm launch      # ❌ Failed to start Windows VM!
chmod g-s ~/Windows            # now 700
omarchy-windows-vm launch      # starts normally
chmod g+s ~/Windows            # back to 2700 after the preflight chmod
omarchy-windows-vm launch      # ❌ Failed to start Windows VM!
```

## Expected vs actual

**Expected:** the preflight normalises the mount sources to `0700` as its comment
states — or fails with a message naming the offending directory and its mode.

**Actual:** `chmod` silently succeeds without changing anything, the check fails,
and `prepare_caller_mounts` returns through a bare `return 1` with no `echo`. The
user sees only:

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

…and `omarchy-windows-vm status` then reports "container not found", which points
at Docker — the wrong place entirely. Because the `.desktop` launcher is
`Terminal=false`, launching from the app menu shows only a critical notification
with no text at all.

What actually identified this was the journal: `pkexec` shows `__priv up_wait`
running as root, while `docker.service` was never started — so the failure is
upstream of any Docker interaction.

## Suggested fix

A 5-digit octal mode does clear the bits:

```diff
-  chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
+  chmod 00700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
```

and likewise at L1018 / L1061. Note `chmod u=rwx,go=` does **not** work either —
only a 5-digit octal or an explicit `g-s` / `a-s` operator does.

Worth considering as well: since the container will re-apply `2777` on every run
with an empty share, tolerating setgid on the *shared* mount (rather than
re-clearing it each launch) may be closer to the intent — the bit is there so
files created in the share inherit the group.

Separately, the `return 1` at L593 would be far easier to diagnose with a message:

```bash
echo "omarchy-windows-vm: VM source directories must be mode 700 (storage=$storage_mode shared=$shared_mode)" >&2
```

## System details

| | |
|---|---|
| Omarchy | 4.0.2-1 (also present on `quattro` @ HEAD — file is byte-identical) |
| Kernel | 7.1.9-arch1-2 |
| CPU | 13th Gen Intel Core i9-13900H |
| GPU | Intel Raptor Lake-P Iris Xe + NVIDIA RTX 4070 Max-Q |
| Docker | 29.7.2 |
| coreutils | 9.11 |
| `$HOME` filesystem | btrfs |