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: shared-folder Samba service breaks the mount permission check on relaunch
Reported by MarkGoldring · filed Sep 5, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #9334 (R-1173). GitHub close reason: completed.
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
What happened
Selecting "Windows" from the app menu (or running omarchy-windows-vm launch) fails with a generic toast: "❌ Failed to start Windows VM!" / notification "Failed to start Windows VM". This happens reliably after the VM has been started successfully once.
Root cause
omarchy-windows-vm's prepare_caller_mounts() requires ~/.windows (storage) and ~/Windows (shared) to be exactly mode 0700 before it will bind-mount them and bring the container up (mounted_leaf_matches() hard-requires mode == 700).
The dockurr/windows container runs a Samba (smbd) service to expose the /shared folder (bind-mounted from ~/Windows) to the Windows guest. As soon as Samba starts serving that share, it actively rewrites the host directory's permissions — observed going 700 → 2700 → 2777 on a live system (setgid, and at one point world-rwx) — because it shares the same inode via the bind mount.
Once that happens, every subsequent launch attempt fails: prepare_caller_mounts() tries to chmod 700 the tainted directory again, but while a live smbd is still mediating that path this doesn't reliably stick (verified with direct chmod/os.chmod calls as root — occasionally reported success without the mode actually changing). Even after the container is fully stopped/removed, the leftover elevated mode is never cleaned up, so the check keeps failing until the user manually runs chmod 700 ~/Windows ~/.windows before the next launch.
In short: the VM's own file-sharing feature and the launcher's mount-safety check are mutually incompatible after the first run.
Steps to reproduce
omarchy-windows-vm installand complete first-time setup — first launch succeeds, Windows boots.- Stop the VM (
omarchy-windows-vm stop) or reboot the host. stat -c '%a' ~/Windows→ no longer700(e.g.2700).- Click "Windows" in the app menu again (or
omarchy-windows-vm launch) → fails with "Failed to start Windows VM!", no actionable detail shown to the user.
Expected
The launcher should either tolerate/restore the permission drift caused by its own container's Samba service, or surface a clear diagnostic instead of a generic failure toast.
Diagnostics
omarchy version: 4.0.2-1- CPU: AMD Ryzen 9 PRO 8945HS w/ Radeon 780M Graphics
- GPU: AMD HawkPoint1 (amdgpu)
- Kernel: 7.1.9-arch1-2
- Docker: 29.7.2
- Image:
dockurr/windows@sha256:0cff9eb0e7aee9953e55bc682852ca4fdca233145a58ae1ec94f0b0c01a2ed30 - Filesystem: btrfs (
/homesubvolume)
Diagnosed interactively via pkexec bash -x /usr/bin/omarchy-windows-vm __priv up_wait tracing, docker exec omarchy-windows ps aux (confirmed smbd serving /shared), and repeated chmod/stat/os.chmod checks on ~/Windows before/during/after the container's lifecycle.
Workaround
Locally patched ~/.local/share/applications/windows-vm.desktop's Exec line to chmod 700 "$HOME/Windows" "$HOME/.windows" (with a short retry loop) immediately before calling omarchy-windows-vm launch. This is lost on reinstall since install_windows() regenerates that file.
View raw text
## What happened Selecting "Windows" from the app menu (or running `omarchy-windows-vm launch`) fails with a generic toast: "❌ Failed to start Windows VM!" / notification "Failed to start Windows VM". This happens reliably after the VM has been started successfully once. ## Root cause `omarchy-windows-vm`'s `prepare_caller_mounts()` requires `~/.windows` (storage) and `~/Windows` (shared) to be exactly mode `0700` before it will bind-mount them and bring the container up (`mounted_leaf_matches()` hard-requires `mode == 700`). The `dockurr/windows` container runs a Samba (`smbd`) service to expose the `/shared` folder (bind-mounted from `~/Windows`) to the Windows guest. As soon as Samba starts serving that share, it actively rewrites the *host* directory's permissions — observed going `700 → 2700 → 2777` on a live system (setgid, and at one point world-rwx) — because it shares the same inode via the bind mount. Once that happens, every subsequent launch attempt fails: `prepare_caller_mounts()` tries to `chmod 700` the tainted directory again, but while a live `smbd` is still mediating that path this doesn't reliably stick (verified with direct `chmod`/`os.chmod` calls as root — occasionally reported success without the mode actually changing). Even after the container is fully stopped/removed, the leftover elevated mode is never cleaned up, so the check keeps failing until the user manually runs `chmod 700 ~/Windows ~/.windows` before the next launch. In short: the VM's own file-sharing feature and the launcher's mount-safety check are mutually incompatible after the first run. ## Steps to reproduce 1. `omarchy-windows-vm install` and complete first-time setup — first launch succeeds, Windows boots. 2. Stop the VM (`omarchy-windows-vm stop`) or reboot the host. 3. `stat -c '%a' ~/Windows` → no longer `700` (e.g. `2700`). 4. Click "Windows" in the app menu again (or `omarchy-windows-vm launch`) → fails with "Failed to start Windows VM!", no actionable detail shown to the user. ## Expected The launcher should either tolerate/restore the permission drift caused by its own container's Samba service, or surface a clear diagnostic instead of a generic failure toast. ## Diagnostics - `omarchy version`: 4.0.2-1 - CPU: AMD Ryzen 9 PRO 8945HS w/ Radeon 780M Graphics - GPU: AMD HawkPoint1 (amdgpu) - Kernel: 7.1.9-arch1-2 - Docker: 29.7.2 - Image: `dockurr/windows@sha256:0cff9eb0e7aee9953e55bc682852ca4fdca233145a58ae1ec94f0b0c01a2ed30` - Filesystem: btrfs (`/home` subvolume) Diagnosed interactively via `pkexec bash -x /usr/bin/omarchy-windows-vm __priv up_wait` tracing, `docker exec omarchy-windows ps aux` (confirmed `smbd` serving `/shared`), and repeated `chmod`/`stat`/`os.chmod` checks on `~/Windows` before/during/after the container's lifecycle. ## Workaround Locally patched `~/.local/share/applications/windows-vm.desktop`'s `Exec` line to `chmod 700 "$HOME/Windows" "$HOME/.windows"` (with a short retry loop) immediately before calling `omarchy-windows-vm launch`. This is lost on reinstall since `install_windows()` regenerates that file.
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.