## What happened

After stopping and relaunching the Windows VM, `omarchy-windows-vm launch`
fails with no useful information:

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

`omarchy-windows-vm status` then reports "Windows VM container not found."
No further diagnostic output is produced anywhere (stdout, stderr, or the
journal) — pkexec authorization succeeds every time, so it isn't an
authorization problem.

## Root cause

Two compounding issues in `/usr/share/omarchy/bin/omarchy-windows-vm`:

1. **The `dockurr/windows` container sets the setgid bit on `/shared`** as
   part of its own Samba-share setup on every start. Since `/shared` is bind
   -mounted straight through to the user's real `~/Windows` directory, that
   bit lands on the host directory and persists after the container stops.

2. **`prepare_caller_mounts`'s mode-verification step has no diagnostic
   output.** It `chmod 0700`s the pinned source directories and then requires
   an *exact* string match against `"700"`:

   ```bash
   chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
     exec {storage_fd}<&-
     exec {shared_fd}<&-
     return 1
   }
   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
   ```

   With the leftover setgid bit, `stat -Lc '%a'` reports `2700`, which fails
   this check — and unlike almost every other failure branch in this script,
   this one has no `echo` before `return 1`, so the failure is completely
   silent all the way up through `launch_windows`.

   Separately (and worth checking on its own): a plain `chmod 0700 ~/Windows`
   run directly on the path did not reliably clear the setgid bit in testing
   here, while `chmod g-s ~/Windows` did — worth double-checking whether the
   `chmod` call above against the `/proc/$BASHPID/fd/N` form actually clears
   setgid reliably on directories.

## Steps to reproduce

1. `omarchy-windows-vm install` and let Windows finish installing.
2. `omarchy-windows-vm launch`, confirm it connects, then close RDP (or run
   `omarchy-windows-vm stop`) so the container stops.
3. `stat -c '%a' ~/Windows` — now shows `2700` instead of `700`.
4. `omarchy-windows-vm launch` again — fails silently as above.

## Expected

Either the script should strip the setgid bit itself before the check (since
that's exactly what the `chmod 0700` step is meant to guarantee), or at
minimum the failure should print a specific, actionable message instead of
silently returning 1.

## Workaround

`chmod g-s ~/Windows` before each `launch` restores it.

## System info

- `omarchy version`: 4.0.2-1

---
Filed by Claude Sonnet 5 via Claude Code.