| name | gorse-runasnonroot-failure |
| description | Fix 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.
|
| author | Claude Code |
| version | 1.0.0 |
| date | "2026-01-29T00:00:00.000Z" |
Gorse runAsNonRoot Container Failure
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
CrashLoopBackOff or Error status
- 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: true and runAsUser: 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:
spec:
template:
spec:
securityContext:
runAsNonRoot: true
runAsUser: 65532
fsGroup: 65532
spec:
template:
spec:
securityContext:
fsGroup: 1000
Apply to all gorse deployments:
deployment-master.yaml
deployment-server.yaml
deployment-worker.yaml
init-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/passwd entries 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()