[PR #416] [MERGED] Make default run UID/GID configurable, fix UID following GID on update #448

New issue

Closed

opened 2026-10-15 13:00:39 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 13:00:39 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/wolf/pull/416
Author: @JBailes
Created: 5/31/2026
Status: ✅ Merged
Merged: 5/31/2026
Merged by: @JBailes

Base: stable ← Head: fix/configurable-default-run-uid-gid

📝 Commits (3)

9f06a5c Make default run UID/GID configurable and fix UID-follows-GID on update
113adfe Use existing utils::get_env for run UID/GID defaults
7a11d7a docs: list WOLF_DEFAULT_RUN_UID/GID in config page and Dockerfile

📊 Changes

5 files changed (+34 additions, -3 deletions)

View changed files

📝 docker/wolf.Dockerfile (+2 -0)
📝 docs/modules/user/pages/configuration.adoc (+8 -0)
📝 docs/modules/user/pages/quickstart.adoc (+14 -0)
📝 src/moonlight-server/api/endpoints.cpp (+1 -1)
📝 src/moonlight-server/state/serialised_config.hpp (+9 -2)

📄 Description

Problem

Apps run as 1000:1000 by default, which bakes in a UID/GID convention that
isn't universal. On Unraid the nobody user is 99:100, so the defaults
never matched the host and every newly paired client had to be corrected by
hand.

That manual correction was also broken. In endpoint_UpdateClientSettings,
the run_uid field was assigned from new_settings.run_gid:

.run_uid = new_settings.run_gid.value_or(current_settings.run_uid),
.run_gid = new_settings.run_gid.value_or(current_settings.run_gid),

So whatever GID you submitted was copied into the UID too — you could only ever
end up with 99:99 or 100:100, never 99:100. Submitting only a new UID
(no GID) silently dropped the change, because the value_or fell through to the
current value. On Unraid this left Steam and other apps running with a UID
outside the expected 1000–60000 range and with file ownership that didn't line
up with the host, which broke streaming.

Changes

Configurable defaults via env vars. ClientSettings::run_uid / run_gid
now read WOLF_DEFAULT_RUN_UID / WOLF_DEFAULT_RUN_GID via the existing
utils::get_env (falling back to 1000). Both new-client paths default-construct
ClientSettings, so they inherit the override. Persisted clients keep their
saved values, so this only affects new clients.
Fix the UID-follows-GID bug. endpoint_UpdateClientSettings now reads
new_settings.run_uid for the run_uid field, so UID and GID can be set
independently.
Docs. Document the two new environment variables in the quickstart.

Why env vars

This is what lets the Unraid plugin (and any other turnkey deployment) ship the
right defaults: the plugin controls Wolf's container environment, so it can set
WOLF_DEFAULT_RUN_UID=99 / WOLF_DEFAULT_RUN_GID=100 and every new client is
correct out of the box, with no per-client editing.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/wolf/pull/416 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 5/31/2026 **Status:** ✅ Merged **Merged:** 5/31/2026 **Merged by:** [@JBailes](https://github.com/JBailes) **Base:** `stable` ← **Head:** `fix/configurable-default-run-uid-gid` --- ### 📝 Commits (3) - [`9f06a5c`](https://github.com/games-on-whales/wolf/commit/9f06a5c4c1ca545131ef1080ffce485592e5aa25) Make default run UID/GID configurable and fix UID-follows-GID on update - [`113adfe`](https://github.com/games-on-whales/wolf/commit/113adfee817e469b9288128c8a7399f792a526a1) Use existing utils::get_env for run UID/GID defaults - [`7a11d7a`](https://github.com/games-on-whales/wolf/commit/7a11d7a1e9c4327c89a2cb58acec1ec17d16def8) docs: list WOLF_DEFAULT_RUN_UID/GID in config page and Dockerfile ### 📊 Changes **5 files changed** (+34 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `docker/wolf.Dockerfile` (+2 -0) 📝 `docs/modules/user/pages/configuration.adoc` (+8 -0) 📝 `docs/modules/user/pages/quickstart.adoc` (+14 -0) 📝 `src/moonlight-server/api/endpoints.cpp` (+1 -1) 📝 `src/moonlight-server/state/serialised_config.hpp` (+9 -2) </details> ### 📄 Description ## Problem Apps run as `1000:1000` by default, which bakes in a UID/GID convention that isn't universal. On **Unraid** the `nobody` user is `99:100`, so the defaults never matched the host and every newly paired client had to be corrected by hand. That manual correction was also broken. In `endpoint_UpdateClientSettings`, the `run_uid` field was assigned from `new_settings.run_gid`: ```cpp .run_uid = new_settings.run_gid.value_or(current_settings.run_uid), .run_gid = new_settings.run_gid.value_or(current_settings.run_gid), ``` So whatever GID you submitted was copied into the UID too — you could only ever end up with `99:99` or `100:100`, never `99:100`. Submitting only a new UID (no GID) silently dropped the change, because the `value_or` fell through to the current value. On Unraid this left Steam and other apps running with a UID outside the expected `1000–60000` range and with file ownership that didn't line up with the host, which broke streaming. ## Changes - **Configurable defaults via env vars.** `ClientSettings::run_uid` / `run_gid` now read `WOLF_DEFAULT_RUN_UID` / `WOLF_DEFAULT_RUN_GID` via the existing `utils::get_env` (falling back to `1000`). Both new-client paths default-construct `ClientSettings`, so they inherit the override. Persisted clients keep their saved values, so this only affects *new* clients. - **Fix the UID-follows-GID bug.** `endpoint_UpdateClientSettings` now reads `new_settings.run_uid` for the `run_uid` field, so UID and GID can be set independently. - **Docs.** Document the two new environment variables in the quickstart. ## Why env vars This is what lets the Unraid plugin (and any other turnkey deployment) ship the right defaults: the plugin controls Wolf's container environment, so it can set `WOLF_DEFAULT_RUN_UID=99` / `WOLF_DEFAULT_RUN_GID=100` and every new client is correct out of the box, with no per-client editing. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 13:00:39 +00:00