Dump permissions on container's mounted user dir #15010

New Issue

GiteaMirror · 2025-11-02T11:27:56-06:00

GiteaMirror commented

2025-11-02 11:27:56 -06:00

Originally created by @homelan-git on GitHub (Oct 9, 2025).

Description

Hi,

I've read some threads about the permissions before. I also read about man: gitea dump and Gitea Backup and Restore. Anyway, for me the problem still exist for my use case:

# all went fine
core@coreos-test:~$ podman exec -u git --workdir /tmp gitea bash -c '/usr/local/bin/gitea dump --skip-db --type tar --file "/tmp/gitea-dump-$(date +%F).tar" --verbose --config /data/gitea/conf/app
.ini'
....
# went wrong:
core@coreos-test:~$ podman exec -u git --workdir /backup gitea bash -c 'ls -la /backup && /usr/local/bin/gitea dump --skip-db --type tar --file "/backup/gitea-dump-$(date +%F).tar" --verbose --config /data/gitea/conf/app.ini'
total 0
drwxr-xr-x    2 root     root            44 Oct  9 19:00 .
dr-xr-xr-x    1 root     root            65 Oct  9 19:47 ..
-rw-r--r--    1 root     root             0 Oct  9 19:47 db-gitea-backup-2025-10-09.sql
2025/10/09 19:48:22 cmd/dump.go:101:fatal() [F] Unable to create dump file "/backup/gitea-dump-2025-10-09.tar": open /backup/gitea-dump-2025-10-09.tar: permission denied

As you can see, I'm using Fedora CoreOS (hence with SELinux), Gitea with MariaDb and have a Quadlet:

[Unit]
Description=Gitea: Git with a cup of tea - A painless self-hosted Git service.
Requires=gitea-db.service
After=gitea-db.service

[Container]
Image=docker.io/gitea/gitea:1.24
ContainerName=gitea
...

Volume=gitea-data:/data:Z
Volume=/etc/localtime:/etc/localtime:ro
Volume=%h/backup/gitea://backup:rw,Z

...

On host I have:

core@coreos-test:~$ ll
drwxr-xr-x. 3 core core  19 Oct  8 19:14 backup
core@coreos-test:~$ ll backup/
drwxr-xr-x. 2 core core 44 Oct  9 19:00 gitea
core@coreos-test:~$ ll backup/gitea/
-rw-r--r--. 1 core core 0 Oct  9 19:47 db-gitea-backup-2025-10-09.sql

Gitea as git user hasn't permissions to write (even root could). How is this use-case intended to be used? Maybe not really a problem with the Image, but not sure about. Any help is appreciated.

Gitea Version

1,24

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

From OCI Image on CentOS with rootless podman.

Database

MySQL/MariaDB

Originally created by @homelan-git on GitHub (Oct 9, 2025). ### Description Hi, I've read some threads about the permissions before. I also read about [man: gitea dump](https://docs.gitea.com/administration/command-line#dump) and [Gitea Backup and Restore](https://docs.gitea.com/administration/backup-and-restore). Anyway, for me the problem still exist for my use case: ```bash # all went fine core@coreos-test:~$ podman exec -u git --workdir /tmp gitea bash -c '/usr/local/bin/gitea dump --skip-db --type tar --file "/tmp/gitea-dump-$(date +%F).tar" --verbose --config /data/gitea/conf/app .ini' .... # went wrong: core@coreos-test:~$ podman exec -u git --workdir /backup gitea bash -c 'ls -la /backup && /usr/local/bin/gitea dump --skip-db --type tar --file "/backup/gitea-dump-$(date +%F).tar" --verbose --config /data/gitea/conf/app.ini' total 0 drwxr-xr-x 2 root root 44 Oct 9 19:00 . dr-xr-xr-x 1 root root 65 Oct 9 19:47 .. -rw-r--r-- 1 root root 0 Oct 9 19:47 db-gitea-backup-2025-10-09.sql 2025/10/09 19:48:22 cmd/dump.go:101:fatal() [F] Unable to create dump file "/backup/gitea-dump-2025-10-09.tar": open /backup/gitea-dump-2025-10-09.tar: permission denied ``` As you can see, I'm using Fedora CoreOS (hence with SELinux), Gitea with MariaDb and have a Quadlet: ```ini [Unit] Description=Gitea: Git with a cup of tea - A painless self-hosted Git service. Requires=gitea-db.service After=gitea-db.service [Container] Image=docker.io/gitea/gitea:1.24 ContainerName=gitea ... Volume=gitea-data:/data:Z Volume=/etc/localtime:/etc/localtime:ro Volume=%h/backup/gitea://backup:rw,Z ... ``` On host I have: ```bash core@coreos-test:~$ ll drwxr-xr-x. 3 core core 19 Oct 8 19:14 backup core@coreos-test:~$ ll backup/ drwxr-xr-x. 2 core core 44 Oct 9 19:00 gitea core@coreos-test:~$ ll backup/gitea/ -rw-r--r--. 1 core core 0 Oct 9 19:47 db-gitea-backup-2025-10-09.sql ``` Gitea as git user hasn't permissions to write (even root could). How is this use-case intended to be used? Maybe not really a problem with the Image, but not sure about. Any help is appreciated. ### Gitea Version 1,24 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? From OCI Image on CentOS with rootless podman. ### Database MySQL/MariaDB

GiteaMirror added the issue/not-a-bug label 2025-11-02 11:27:56 -06:00

GiteaMirror commented

2025-11-02 11:27:57 -06:00

@wxiaoguang commented on GitHub (Oct 10, 2025):

Actually it is not really Gitea's problem. It is related how the mapped volume permission works in a container.

You need to figure out how to make your /backup writeable by the Gitea (and its run user)

@wxiaoguang commented on GitHub (Oct 10, 2025): Actually it is not really Gitea's problem. It is related how the mapped volume permission works in a container. You need to figure out how to make your `/backup` writeable by the Gitea (and its run user)

GiteaMirror commented

2025-11-02 11:27:57 -06:00

@homelan-git commented on GitHub (Oct 10, 2025):

Thank you for your answer. I'm still working on it to find an approbate solution. The simplest solution is to set the folder permission to 777 on host:

$ chmod 777 ~/backup/gitea/
$ podman exec -u git ....
$ ll ~/backup/
drwxrwxrwx. 2 core core 115 Oct 10 18:25 gitea
$ ll ~/backup/gitea/
-rw-r--r--. 1 core   core   132317 Oct 10 18:25 db-gitea-backup-2025-10-10.sql
-rw-------. 1 525287 525287 207872 Oct 10 18:25 gitea-dump-2025-10-10.tar

But a world-read/writable directory isn't secure. Imo, the problem is related to the Container, since Container's /tmp has also mode 777 - hence this works as described on the resources mentioned above. The db-gitea-backup-2025-10-10.sqlshown is from MariaDB dump.

Nevertheless, the dump above has UID/GID from /ect/sub{u,g}id.

I tried mapping of my core's UID=1000 as:

[Container]
Image=docker.io/gitea/gitea:1.24
ContainerName=gitea
...
Volume=%h/backup/gitea:/backup:z

Pod=gitea.pod
...

where gitea.pod

[Pod]
PodName=gitea
...

UIDMap=1000:1000:1
GIDMap=1000:1000:1

I would expect, that user/group of Gitea's dump would show core:core, but it don't (same uid/guid as above). But this all would not solve the permission problem for gitea dump inside the container. Wouldn't? Since I start the gitea dump command podman exec -u git --workdir /backup gitea bash -c '/usr/local/bin/gitea dump --type tar --file "/backup/gitea-dump-$(date +%F).tar" --verbose --config /data/gitea/conf/app.ini' from console as Container's user git I'm even unable to change the owner of '/backup'.

@homelan-git commented on GitHub (Oct 10, 2025): Thank you for your answer. I'm still working on it to find an approbate solution. The simplest solution is to set the folder permission to 777 on host: ```bash $ chmod 777 ~/backup/gitea/ $ podman exec -u git .... $ ll ~/backup/ drwxrwxrwx. 2 core core 115 Oct 10 18:25 gitea $ ll ~/backup/gitea/ -rw-r--r--. 1 core core 132317 Oct 10 18:25 db-gitea-backup-2025-10-10.sql -rw-------. 1 525287 525287 207872 Oct 10 18:25 gitea-dump-2025-10-10.tar ``` But a world-read/writable directory isn't secure. Imo, the problem is related to the Container, since Container's `/tmp` has also mode 777 - hence this works as described on the resources mentioned above. The `db-gitea-backup-2025-10-10.sql`shown is from MariaDB dump. Nevertheless, the dump above has UID/GID from /ect/sub{u,g}id. I tried mapping of my core's UID=1000 as: ```ini [Container] Image=docker.io/gitea/gitea:1.24 ContainerName=gitea ... Volume=%h/backup/gitea:/backup:z Pod=gitea.pod ... ``` where `gitea.pod` ``` [Pod] PodName=gitea ... UIDMap=1000:1000:1 GIDMap=1000:1000:1 ``` I would expect, that user/group of Gitea's dump would show core:core, but it don't (same uid/guid as above). But this all would not solve the permission problem for `gitea dump` inside the container. Wouldn't? Since I start the gitea dump command `podman exec -u git --workdir /backup gitea bash -c '/usr/local/bin/gitea dump --type tar --file "/backup/gitea-dump-$(date +%F).tar" --verbose --config /data/gitea/conf/app.ini'` from console as Container's user git I'm even unable to change the owner of '/backup'.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#15010