Self-host: can we fix data-folder ownership on container start so leftover import CSVs don’t waste disk space?

[EmmS21]

This is related to this issue #6515 (and the bugfix that scopes Oban import-failure handling to ImportAnalytics only).

I made an MR such that a failed LocalImportAnalyticsCleaner no longer purges ClickHouse import stats.

It got me thinking, on self-hosted CE, we could have leftover CSVs that remain on disk when File.rm! returns permission denied, meaning there is a file permissions issue.

Retries wouldn't help if the permission state never changes. This is wasted space that accumulates for the user.

Proposal

I'd treat this as a small CE image / entrypoint change rather than something in the product UI.

When the container starts as root, the entrypoint would chown -R the data dir to the plausible user, then su-exec down and start the app as it does today.

If someone already runs the container as a non-root user (-u 1000, etc.), we'd skip the chown and keep the current behavior.

Alternatives I considered

• An upload-time probe (create and delete a temp file under the import dir) would catch a broken volume earlier, but it would also fail the import UX when storage is already unhealthy, and it wouldn't help if ownership changes after a successful upload.
• User email / UI for leftover files feels like the wrong layer. Looking at how this repo has handled similar work: import/export emails were built around the outcome of the import/export job itself (success/failure of loading or producing data), and janitor-style workers tend to stay in logs (Logger / Sentry via Oban) rather than product notifications. LocalImportAnalyticsCleaner is that second category; disk hygiene after the import already finished. Surfacing un-deletable CSVs the same way as a failed import would mix two different meanings for the user.

Any concerns or thoughts about this approach?

[EmmS21]

This is related to this MR:
#6547