Gorse runAsNonRoot Container Failure

SkillMonitoring & ops

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.

Available today. Use it from your connected AI after setup.

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 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:

# 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.yaml
  • deployment-server.yaml
  • deployment-worker.yaml
  • init-db-job.yaml (if using init job)

Verification

After updating the security context:

  1. Delete existing crashing pods: kubectl delete pods -l app.kubernetes.io/name=gorse -n gorse
  2. Wait for new pods to start
  3. Check logs: kubectl logs -l app=gorse-master -n gorse
  4. 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()

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