Gorse runAsNonRoot Container Failure
SkillMonitoring & opsFix Gorse recommendation engine pods crashing with "user: unknown userid 65532" error. Use when: (1) Gorse master/server/worker pods show CrashLoopBackOff or Error status, (2) Logs show "failed to get user directory" with unknown userid, (3) Running gorse containers with runAsNonRoot security context and custom UID. The gorse images call os.UserHomeDir() at startup which requires the UID to exist in /etc/passwd.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Gorse runAsNonRoot Container Failure skill
What this skill tells your AI
The instructions your AI receives, as published by divinevideo/divine-mobile in .agents/skills/gorse-runasnonroot-failure/SKILL.md and read by ahel’s review.
Problem
Gorse recommendation engine containers (master, server, worker) crash immediately on
startup when running with Kubernetes runAsNonRoot: true and a custom UID like 65532.
Context / Trigger Conditions
- Gorse pods show
CrashLoopBackOfforErrorstatus - Pod logs show:
{"level":"fatal","ts":...,"caller":"model/built_in.go:95","msg":"failed to get user directory","error":"user: unknown userid 65532"} - Deployment has
securityContext.runAsNonRoot: trueandrunAsUser: 65532 - Using official gorse images (
zhenghaoz/gorse-master,zhenghaoz/gorse-server,zhenghaoz/gorse-worker)
Root Cause
The gorse codebase calls Go's os.UserHomeDir() during initialization in model/built_in.go.
This function requires the running UID to have an entry in /etc/passwd. When running as
a non-root user that doesn't exist in the container's passwd file, the lookup fails.
Solution
Remove the runAsNonRoot and runAsUser constraints from the pod security context:
# Before (broken)
spec:
template:
spec:
securityContext:
runAsNonRoot: true
runAsUser: 65532
fsGroup: 65532
# After (working)
spec:
template:
spec:
securityContext:
fsGroup: 1000
Apply to all gorse deployments:
deployment-master.yamldeployment-server.yamldeployment-worker.yamlinit-db-job.yaml(if using init job)
Verification
After updating the security context:
- Delete existing crashing pods:
kubectl delete pods -l app.kubernetes.io/name=gorse -n gorse - Wait for new pods to start
- Check logs:
kubectl logs -l app=gorse-master -n gorse - Verify master shows connection to data store and cache store
Notes
- This is a limitation of the official gorse images, not a Kubernetes issue
- The gorse project may fix this in future versions by not requiring home directory
- If security policy requires non-root, you would need to build custom gorse images
with proper
/etc/passwdentries for the desired UID - Redis Stack images used for gorse cache have the same issue with UID 65532
Related Issues
- Gorse GitHub: The images don't document this requirement
- Similar issues affect other Go applications that use
os.UserHomeDir()
Signals
- GitHub stars
- 265
- Forks
- 55
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
gorse-runasnonroot-failure- Source
- github.com/divinevideo/divine-mobile