[PR #415] [CLOSED] Make default run UID/GID configurable, fix UID following GID on update #450

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/415
Author: @JBailes
Created: 5/31/2026
Status: ❌ Closed

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

📝 Commits (2)

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

📊 Changes

3 files changed (+24 additions, -3 deletions)

View changed files

📝 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 (falling back to
1000). Both new-client paths (endpoint_Pair-time session creation and the
pairing event handler) default-construct ClientSettings, so they inherit the
override. Persisted clients keep their saved values, so this only affects
new clients. Malformed/empty values fall back to 1000.
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.

Testing

The new env_default_run_id helper was compiled standalone with
-std=c++17 -Wall -Wextra and verified for the unset / valid / malformed cases.
I was not able to run a full Wolf build locally; relying on CI for the
integration build.

_{🔄 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/415 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 5/31/2026 **Status:** ❌ Closed **Base:** `stable` ← **Head:** `fix/configurable-default-run-uid-gid` --- ### 📝 Commits (2) - [`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 ### 📊 Changes **3 files changed** (+24 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `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` (falling back to `1000`). Both new-client paths (`endpoint_Pair`-time session creation and the pairing event handler) default-construct `ClientSettings`, so they inherit the override. Persisted clients keep their saved values, so this only affects *new* clients. Malformed/empty values fall back to `1000`. - **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. ## Testing The new `env_default_run_id` helper was compiled standalone with `-std=c++17 -Wall -Wextra` and verified for the unset / valid / malformed cases. I was not able to run a full Wolf build locally; relying on CI for the integration build. --- <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