Hi 👋,
I’m running May on Unraid, and I’ve run into a structural compatibility issue which is very common for non‑LSIO images. Unraid’s built‑in Docker integrations (notably Tailscale) assume containers run as nobody:users (UID 99, GID 100), or at least allow the runtime user to be configured.
May currently runs as a fixed, non‑configurable UID (typically 1000), which causes persistent permission conflicts.
This primarily affects:
- Unraid’s built‑in Tailscale Docker integration
- Mounted appdata paths (
/app/data)
- Any Unraid feature that expects
nobody:users
Even when the container works initially, Unraid may re‑create or re‑own mounted directories on restart, causing state loss (for example .tailscale_state), broken networking, or unstable behaviour.
Impact observed
On Unraid, with the current image:
.tailscale_state ownership is repeatedly reset on container restart- Tailscale authentication cannot persist
tailscale serve configuration disappears- Networking appears to “half‑work” (ping sometimes works, HTTPS drops on requests)
- Manual permission fixes (
chown) are reverted automatically
This does not occur with containers that support PUID/PGID (e.g. LSIO images or Duplicati running as nobody:users).
Requested enhancement
✅ Add support for configurable runtime UID/GID
Support standard environment variables:
and remap the internal runtime user accordingly at container start. This is the de‑facto standard on Unraid and would immediately:
- Allow compatibility with Unraid’s Docker integrations (including Tailscale)
- Prevent permission churn on
/app/data
- Avoid the need for sidecar or host‑level VPN workarounds
Suggested implementation
Instead of a fixed USER may, use a revised Docker entrypoint that:
- Reads PUID / PGID
- Updates the runtime user/group if provided
- Drops privileges before starting the app (e.g. via
gosu or su-exec)
Why?
Unraid has a large self‑hosting user base, and many rely on:
- Built‑in VPN tooling (Tailscale)
- Predictable file ownership
- Consistent behaviour across container restarts and updates
Adding PUID/PGID support would significantly improve May’s usability on Unraid without affecting other platforms.
If you're open to this I'm happy to submit a PR.
Thanks for the great project :)
Hi 👋,
I’m running May on Unraid, and I’ve run into a structural compatibility issue which is very common for non‑LSIO images. Unraid’s built‑in Docker integrations (notably Tailscale) assume containers run as
nobody:users(UID99, GID100), or at least allow the runtime user to be configured.May currently runs as a fixed, non‑configurable UID (typically
1000), which causes persistent permission conflicts.This primarily affects:
/app/data)nobody:usersEven when the container works initially, Unraid may re‑create or re‑own mounted directories on restart, causing state loss (for example
.tailscale_state), broken networking, or unstable behaviour.Impact observed
On Unraid, with the current image:
.tailscale_stateownership is repeatedly reset on container restarttailscale serveconfiguration disappearschown) are reverted automaticallyThis does not occur with containers that support PUID/PGID (e.g. LSIO images or Duplicati running as
nobody:users).Requested enhancement
✅ Add support for configurable runtime UID/GID
Support standard environment variables:
and remap the internal runtime user accordingly at container start. This is the de‑facto standard on Unraid and would immediately:
/app/dataSuggested implementation
Instead of a fixed USER may, use a revised Docker entrypoint that:
gosuorsu-exec)Why?
Unraid has a large self‑hosting user base, and many rely on:
Adding PUID/PGID support would significantly improve May’s usability on Unraid without affecting other platforms.
If you're open to this I'm happy to submit a PR.
Thanks for the great project :)