mirror of
https://github.com/games-on-whales/unraid-plugin.git
synced 2026-10-15 13:02:00 +00:00
Labels
No labels
enhancement
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
games-on-whales/unraid-plugin#77
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/games-on-whales/unraid-plugin/pull/71
Author: @JBailes
Created: 8/16/2026
Status: ✅ Merged
Merged: 8/16/2026
Merged by: @JBailes
Base:
main← Head:fix/issue-66-app-state-access📝 Commits (1)
b83d8c9Judge app state by write access, not ownership (#66)📊 Changes
6 files changed (+361 additions, -27 deletions)
View changed files
➕
.github/workflows/tests.yml(+68 -0)📝
scripts/app-state.sh(+127 -13)📝
scripts/deploy.sh(+27 -5)📝
scripts/diagnose.sh(+51 -7)📝
scripts/utils.sh(+3 -0)📝
tests/app-state.sh(+85 -2)📄 Description
The latest report on #66 has the tell in it: the stamp reads 99:100 — so the migration ran and finished clean — and the tree is still full of root-owned paths. The repair is not failing, it is being undone.
Everything named in that report is created by root, on every app launch:
profile-data//, /udev/*
Wolf, create_directories() in state/sessions.hpp and runners/docker.cpp
$HOME/.steam, $HOME/homebrew/services
the gow steam image's cont-init.d/system-services.sh, which runs as root
before dropping to PUID
$HOME/homebrew/plugins
Decky's PluginLoader, deliberately
So a host-side chown can never hold, and #70 was right to reach for inheritable ACLs. Two gaps remained.
The ACL only reached depth 2. prepare_app_state_roots seeds -maxdepth 2 (state root, profile, app HOME), so directories that predate the seeding — .steam and homebrew, at depth 3 — carry no ACL, and neither do their children. Those are genuinely unwritable by the run uid. That is the live breakage.
And ownership was the wrong signal. first_foreign_path and diagnose.sh compared uid/gid, so root-owned-but-writable paths were reported as breakage forever and re-triggered a full chown -R over a Steam library on every deploy. The doctor told the user to run Install, and Install could not satisfy the check.
Also, from auditing the rest of the ownership surface:
2>/dev/null || truebeside an unguarded chmod, so the failure that actually breaks Wolf Den was the one being hidden. Both now warn and let the deploy continue.Tests: the suite's load-bearing assertions were skipping on any host without root and setfacl, which is most of them — three fixes shipped for this issue without those assertions ever executing. It now reproduces the reported tree, asserts red before green, and checks that a root-created directory is writable by inheritance alone. CI runs it as root with real ACLs and fails the build if it skips, because a green check that proves nothing is worse than a red one.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.