The upload-to-s3 container in the gitea-dump CronJob runs as UID 1000 (non-root), and mc tries to write its config to $HOME/.mc. Because HOME is unset (or /) in the container, it falls back to /.mc — which is not writable by a non-root user, causing:
mc: <ERROR> Unable to save new mc config. mkdir /.mc: permission denied.
Fix
Add MC_CONFIG_DIR: /tmp/.mc to the upload-to-s3 container env. /tmp is always writable in a container context. This is the minimal targeted fix — no logic changes.
Alternatively HOME: /tmp would work too, but MC_CONFIG_DIR is more explicit about intent.
## Problem
The `upload-to-s3` container in the gitea-dump CronJob runs as UID 1000 (non-root), and `mc` tries to write its config to `$HOME/.mc`. Because `HOME` is unset (or `/`) in the container, it falls back to `/.mc` — which is not writable by a non-root user, causing:
```
mc: <ERROR> Unable to save new mc config. mkdir /.mc: permission denied.
```
## Fix
Add `MC_CONFIG_DIR: /tmp/.mc` to the `upload-to-s3` container env. `/tmp` is always writable in a container context. This is the minimal targeted fix — no logic changes.
Alternatively `HOME: /tmp` would work too, but `MC_CONFIG_DIR` is more explicit about intent.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
greg
Problem
The
upload-to-s3container in the gitea-dump CronJob runs as UID 1000 (non-root), andmctries to write its config to$HOME/.mc. BecauseHOMEis unset (or/) in the container, it falls back to/.mc— which is not writable by a non-root user, causing:Fix
Add
MC_CONFIG_DIR: /tmp/.mcto theupload-to-s3container env./tmpis always writable in a container context. This is the minimal targeted fix — no logic changes.Alternatively
HOME: /tmpwould work too, butMC_CONFIG_DIRis more explicit about intent.