Repository navigation
windows vm launch fails when ~/Windows is empty (dockur sets shared mode 2777) #10114
Description
Summary
omarchy windows vm launch intermittently aborts with ❌ Failed to start Windows VM! for a freshly tracked VM whose ~/Windows shared folder is still empty.
Environment
- Omarchy 4.0.2-1
- Arch Linux, kernel 7.1.9-arch1-2
- Filesystem: btrfs
Root cause
dockur's container runs /run/samba.sh at every start. Because the /shared source (~/Windows) is empty, it runs chmod 2777 /shared plus the Samba config directory mask = 02777, leaving ~/Windows at mode 2777 (setgid, group/other-write).
The VM launcher's preflight (mounted_leaf_matches in bin/omarchy-windows-vm) demanded the exact private mode 0700 for both mount sources. With ~/Windows at 2777, mounts_ready returns false, so launch falls back to pkexec. In a headless/agent context pkexec cannot prompt for a password, so the launch fails.
An additional wrinkle: on btrfs, chmod 0700 does not clear the setgid bit left by the 2777 chmod (the folder stays 2700), so the mode can never be reduced to a strict 700 while the container keeps re-applying it.
Reproduction
- Start a Windows VM once (dockur creates
~/Windowsempty and pins it as/shared). - Stop the VM (or just relaunch).
omarchy windows vm launchwhile~/Windowsis mode2777→ fails with❌ Failed to start Windows VM!.
Checking: stat -c %a ~/Windows → 2777.
Expected
The launcher tolerates the container-applied 2777/setgid shared mode (still caller-owned, owner-rwx) instead of requiring exact 0700, so the VM starts reliably.
Proposed fix
Relax the two mount-mode checks to accept any caller-owned, owner-rwx mode ((mode & 0700) == 0700, i.e. 0700, 2700, or 2777) while keeping the FD-pinned identity and ownership checks strict.
PR: #10113
Activity
windows-vm: actually clear setgid on the shared/storage source before…
windows-vm: actually clear setgid on the shared/storage source before…
dalton-wood-dev commentedon Sep 14, 2026
The private-permission normalization in
prepare_caller_mountsneeds to explicitly clear directory special bits before requiring an exact mode of700.GNU
chmod 0700preserves directory setgid, so a directory with setgid can remain2700after that call and fail the subsequent exact-mode check. This behavior is not specific to btrfs or a failed authorization prompt.Suggested correction: use
chmod 00700on the already validated, FD-pinned source directories, and check the other directory-normalization calls for the same behavior. This retains the existing strict privacy, ownership, and mount-identity checks instead of relaxing them to accept group/world-writable directories.A local workaround is to explicitly clear setgid and keep a marker file in the shared folder so Dockur does not run its empty-share permission initialization on subsequent starts.
bjarneo commentedon Sep 20, 2026
Automated duplication check: this issue looks similar to #9334, which covers the same Windows VM setgid permission check. I keep that one open and close this one to keep the discussion in one place.
If you feel this is the wrong decision, please open the issue again with a note on the difference.
omarchybot commentedon Oct 4, 2026
Update: #12323 has merged into
quattro. The setgid permission rejection is now fixed in both source-directory hardening paths, with an explicit mode diagnostic. This does not claim that runtime share privacy or every desktop failure notification is fixed.Scope checked by GPT-6 in Codex and Codex Medium against the discussion and landed change; review independence is not guaranteed. No tests were rerun for this cleanup.
Omabot on behalf of DHH