Gitea push fails with "unable to create temporary object directory" — repo objects/ dirs are mode 750 but Gitea user can only read #21

New Issue

2026-05-26T17:31:23+03:00

oleks commented

2026-05-26 17:31:23 +03:00

Discovery (2026-05-26): during the armer DiskPressure incident (oleks/armer#2) we discovered that git push to git.oleks.space repos under oleks/* fails with:

remote: error: remote unpack failed: unable to create temporary object directory
remote rejected ... (unpacker error)

We initially attributed this to armer DiskPressure starving Gitea of temp space. After k3s was stopped on armer (freeing CPU and I/O), the push still failed identically. Root cause turned out to be filesystem permissions, not disk.

Setup on armer:

Gitea runs as User=git Group=serviseer (uid 992, gid 1000)
git user's groups: serviseer, gitea-data
Repo objects dirs (e.g. /var/lib/gitea/repositories/oleks/armer.git/objects) are owned serviseer:serviseer with mode 750

Why it fails:

Mode 750 = owner rwx, group r-x, others none
git user is in group serviseer so it gets the group permissions = r-x — no write
git-receive-pack tries to create objects/incoming-NNNNN temp dir during push → EACCES → "unable to create temporary object directory"
Reproducible: sudo -u git -g serviseer touch /var/lib/gitea/repositories/oleks/armer.git/objects/X → Permission denied
Same operation as serviseer user succeeds

Workaround applied 2026-05-26: sudo chmod -R g+w /var/lib/gitea/repositories/oleks/ on armer → perms now 770. Pushes work again. This is non-declarative and likely to drift back if NixOS rebuilds armer's gitea module.

Open questions:

Why did this break? Repos created earlier had presumably-working perms. Either a recent chmod corrupted them, or pushes have been silently broken for a long time (only API/MCP writes were exercised).
What's the right declarative fix?
- Ensure the gitea NixOS module sets repo dir mode 770 (group write) on creation
- Change ownership so git:git owns objects dirs (group becomes git)
- Drop the serviseer group entirely
Should the gitea fork at oleks/gitea grow defensive code that warns on startup when RepoRootPath group perms can't be written by the running uid?

Cross-references:

oleks/armer#2 (incident)
oleks/armer#5 (decouple gitea from armer disk)

**Discovery (2026-05-26):** during the armer DiskPressure incident (oleks/armer#2) we discovered that `git push` to git.oleks.space repos under `oleks/*` fails with: remote: error: remote unpack failed: unable to create temporary object directory remote rejected ... (unpacker error) We initially attributed this to armer DiskPressure starving Gitea of temp space. After k3s was stopped on armer (freeing CPU and I/O), the push still failed identically. Root cause turned out to be filesystem permissions, not disk. **Setup on armer:** - Gitea runs as `User=git Group=serviseer` (uid 992, gid 1000) - `git` user's groups: `serviseer`, `gitea-data` - Repo objects dirs (e.g. `/var/lib/gitea/repositories/oleks/armer.git/objects`) are owned `serviseer:serviseer` with mode **750** **Why it fails:** - Mode 750 = owner `rwx`, group `r-x`, others none - `git` user is in group `serviseer` so it gets the **group** permissions = `r-x` — no write - `git-receive-pack` tries to create `objects/incoming-NNNNN` temp dir during push → `EACCES` → "unable to create temporary object directory" - Reproducible: `sudo -u git -g serviseer touch /var/lib/gitea/repositories/oleks/armer.git/objects/X` → Permission denied - Same operation as `serviseer` user succeeds **Workaround applied 2026-05-26:** `sudo chmod -R g+w /var/lib/gitea/repositories/oleks/` on armer → perms now `770`. Pushes work again. This is non-declarative and likely to drift back if NixOS rebuilds armer's gitea module. **Open questions:** - Why did this break? Repos created earlier had presumably-working perms. Either a recent chmod corrupted them, or pushes have been silently broken for a long time (only API/MCP writes were exercised). - What's the right declarative fix? - Ensure the gitea NixOS module sets repo dir mode `770` (group write) on creation - Change ownership so `git:git` owns objects dirs (group becomes `git`) - Drop the `serviseer` group entirely - Should the gitea fork at oleks/gitea grow defensive code that warns on startup when `RepoRootPath` group perms can't be written by the running uid? **Cross-references:** - oleks/armer#2 (incident) - oleks/armer#5 (decouple gitea from armer disk)

oleks commented

2026-05-26 19:22:00 +03:00

Closed 2026-05-26 — root cause and fix in armer#9 / armer#10.

Not an upstream Gitea bug. Root cause was the NixOS services.gitea module setting UMask=0027 on the systemd unit, making all runtime-created dirs 0750. With User=git Group=serviseer, group r-x blocked the gitea process from writing its own data dirs.

Durable fix landed in oleks/armer#10: UMask = lib.mkForce "0007" override. Verified live (Umask: 0007 on the running process).

No changes needed in this repo (the gitea fork).

**Closed 2026-05-26 — root cause and fix in armer#9 / armer#10.** Not an upstream Gitea bug. Root cause was the NixOS `services.gitea` module setting `UMask=0027` on the systemd unit, making all runtime-created dirs `0750`. With `User=git Group=serviseer`, group `r-x` blocked the gitea process from writing its own data dirs. Durable fix landed in oleks/armer#10: `UMask = lib.mkForce "0007"` override. Verified live (`Umask: 0007` on the running process). No changes needed in this repo (the gitea fork).

oleks closed this issue

2026-05-26 19:22:06 +03:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: oleks/gitea#21