Windows VM: omarchy-windows-vm launch fails silently ("Failed to start Windows VM") when the shared-folder anchor has the setgid bit set #10149

Title: Windows VM: omarchy-windows-vm launch fails silently ("Failed to start Windows VM") when the shared-folder anchor has the setgid bit set

System details: Intel Core i7-8850H, Intel UHD Graphics 630, Omarchy 4.0.2-1

What's wrong?

After installing and running the Windows VM (omarchy-windows-vm install → omarchy-windows-vm launch), a later omarchy-windows-vm launch can start failing with only:

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

omarchy-windows-vm status shows the container is still RUNNING, and docker logs confirms Windows booted fine — so this isn't actually a VM start failure, it's the privileged up_wait helper aborting before it even touches Docker.

Root cause

prepare_caller_mounts() requires both mount-anchor directories to be exactly mode 700:

storage_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$storage_fd" ...)
shared_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$shared_fd" ...)
if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
  ...
  return 1
fi

The shared anchor (bind-mounted into the guest as /shared for the Samba share) ends up with mode 2700 (setgid bit set) after normal use from inside the Windows guest — this looks like legitimate behavior from the guest's SMB client/server touching the folder, not tampering. Once that happens, every subsequent up_wait/up call fails this strict == 700 comparison and aborts.

The bigger issue: none of the failure paths here print anything to stderr, so the wrapper's launch_windows() just prints the generic "Failed to start Windows VM!" with zero indication of why. Tracing it required running pkexec bash -x /usr/bin/omarchy-windows-vm __priv up_wait to find the actual [[ 2700 != 700 ]] comparison.

Steps to reproduce

1. omarchy-windows-vm install and let Windows finish setting up.
2. Use the VM for a while (browse the shared/Windows folder from inside the guest) so the setgid bit gets set on the host-side shared anchor.
3. Close RDP (VM auto-stops), then omarchy-windows-vm launch again.
4. Observe the opaque "Failed to start Windows VM!" message even though nothing is actually wrong with Docker/the container.

Workaround

chmod g-s /home/<user>/Windows   # or wherever the shared folder points
omarchy-windows-vm launch

(Path found via findmnt -T /var/lib/omarchy/windows/mounts/users/<uid>/shared.)

Suggested fix

Either:

• mask off the setgid/setuid/sticky bits before comparing (mode=$(( 8#$mode & 0777 )) or compare against a pattern that ignores the leading digit) instead of a strict == 700/== 700, since the guest's own Samba usage legitimately sets it, or
• have prepare_caller_mounts re-clear the bit itself (it already does chmod 0700 on both fds earlier in the function — but the later comparison still reads the fd's mode via stat, and that chmod apparently doesn't stick for the shared fd, worth double-checking why), and/or
• at minimum, echo the specific failing check to stderr so launch_windows can surface something more actionable than "Failed to start Windows VM!".