gitea
gitea copied to clipboard
Gitea rootless setup error: mkdir: can't create directory '/var/lib/gitea/git': Permission denied
Description
I'm following the instructions here: https://docs.gitea.io/en-us/install-with-docker-rootless/
After running docker compose up, I'm getting the error:
gitea | mkdir: can't create directory '/var/lib/gitea/git': Permission denied
gitea | /var/lib/gitea/git is not writable
gitea | docker setup failed
gitea exited with code 1
docker-compose.yml
version: "2"
services:
server:
container_name: gitea
image: gitea/gitea:1.18.0-rootless
environment:
- GITEA__database__DB_TYPE=postgres
- GITEA__database__HOST=db:5432
- GITEA__database__NAME=gitea
- GITEA__database__USER=gitea
- GITEA__database__PASSWD=gitea
restart: always
volumes:
- ./data:/var/lib/gitea
- ./config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "2222:2222"
depends_on:
- db
db:
container_name: gitea-db
image: postgres:14
restart: always
environment:
- POSTGRES_USER=gitea
- POSTGRES_PASSWORD=gitea
- POSTGRES_DB=gitea
volumes:
- ./postgres:/var/lib/postgresql/data
gitea directory:
debian@dev:~/gitea$ ls -al
total 24
drwxr-xr-x 5 debian debian 4096 Jan 3 16:51 .
drwxr-xr-x 12 debian debian 4096 Jan 3 16:31 ..
drwxr-xr-x 2 debian debian 4096 Jan 3 16:34 config
drwxr-xr-x 2 debian debian 4096 Jan 3 16:34 data
-rw-r--r-- 1 debian debian 792 Jan 3 16:35 docker-compose.yml
drwx------ 19 100998 debian 4096 Jan 3 16:42 postgres
Docker version 20.10.21, build baeda1f
- Installed via https://docs.docker.com/engine/security/rootless/
- dbus-user-session is already the newest version (1.12.24-0+deb11u1)
- fuse-overlayfs is already the newest version (1.4.0-1)
- slirp4netns is already the newest version (1.0.1-2)
curl -fsSL https://get.docker.com/rootless | sh
Docker Compose version v2.14.1
- Installed via
apt install docker-compose-plugin
Debian GNU/Linux 11 (bullseye)
Gitea Version
1.18.0-rootless
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
https://pastebin.com/NmyrhLYE
Screenshots
No response
Git Version
No response
Operating System
Debian 11 (docker host)
How are you running Gitea?
From docker: here: https://docs.gitea.io/en-us/install-with-docker-rootless/ (details in the description above)
Database
PostgreSQL
What is the output of id debian command? Gitea on Docker by default runs as UID 1000, and I suspect that the debian user is not UID 1000 on your system. If this is the case, you can either change ownership of files or change which user Gitea runs as (see this guide).
I have the same problem, with a slightly different config (sqlite DB):
version: "2"
services:
server:
image: gitea/gitea:1.18.0-rootless
container_name: gitea
restart: always
volumes:
- /home/thinegen/gitea/data:/var/lib/gitea
- /home/thinegen/gitea/config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "127.0.0.1:10002:3000"
- "127.0.0.1:2222:2222"
Debian 11 bullseye:
dbus-user-session/stable,stable-security,now 1.12.24-0+deb11u1 amd64 [installed]
fuse-overlayfs/stable,now 1.4.0-1 amd64 [installed]
slirp4netns/stable,now 1.0.1-2 amd64 [installed]
docker-ce-cli/bullseye,now 5:20.10.22~3-0~debian-bullseye amd64 [installed]
docker-ce-rootless-extras/bullseye,now 5:20.10.22~3-0~debian-bullseye amd64 [installed,automatic]
docker-ce/bullseye,now 5:20.10.22~3-0~debian-bullseye amd64 [installed]
docker-compose-plugin/bullseye,now 2.14.1~debian-bullseye amd64 [installed]
docker-scan-plugin/bullseye,now 0.23.0~debian-bullseye amd64 [installed,automatic]
uid=1000(thinegen) gid=1000(thinegen) groups=1000(thinegen),27(sudo),33(www-data)
total 20K
drwxr-xr-x 4 thinegen thinegen 4.0K Jan 7 17:28 .
drwxr-xr-x 7 thinegen thinegen 4.0K Jan 7 17:27 ..
drwxr-xr-x 2 thinegen thinegen 4.0K Jan 6 23:04 config
drwxr-xr-x 2 thinegen thinegen 4.0K Jan 6 23:53 data
-rw-r--r-- 1 thinegen thinegen 422 Jan 7 17:28 docker-compose.yml
config and data are empty.
@wfjake
What is the output of
id debiancommand? Gitea on Docker by default runs as UID 1000, and I suspect that thedebianuser is not UID 1000 on your system. If this is the case, you can either change ownership of files or change which user Gitea runs as (see this guide).
debian@dev:~$ id debian
uid=1000(debian) gid=1000(debian) groups=1000(debian),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),1001(git)
@jpdelmundo Did you managed to find a solution? Im having the same issue in virtualy the exact same environment as yours.
I looked into the source for a bit and i think that the problem is that gitea runs as 1000:1000 inside the container, while the permissions for the volume folders remain 0:0 inside. The line throwing the exception is here. You might get away with removing the USER line in the Dockerfile and setting I_AM_BEING_UNSAFE_RUNNING_AS_ROOT in the ini file (see here for further infos), but I don't know enough to say how good an idea this is.
I think that this is corresponding to HOME and this line here:
https://github.com/go-gitea/gitea/blob/326d29dce0cf2dcd5478f297d899f098aefaadaa/docker/rootless/usr/local/bin/docker-setup.sh#L4
Have you tried setting HOME to somewhere different?
Using /tmp/gitea as HOME works, and not using any volume apart from the read-only timedata works as well. Other paths don't work.
Apparently it's fine to just use the non-rootless container since the only difference is the uid/gid mapping. I have it running like that for a while now and it seems to work.
If you definitely want to run gitea with the rootless version, you might have to recompile it to find the right uid/gid. If you want to do that, change Dockerfile.rootless to exclude the USER line and add chown git:git to mkdir in docker/rootless/usr/local/bin/. You will still catch the errors described above, but there should be some directories on your host system. They will have a uid/gid like 100999:100999. If you chown your ./config and ./data to that, the rootless container should run.
You can prevent Gitea from trying to create the directory by making it yourself. Inside ./data:
mkdir git
^ For me this was the fix for this error. I'd propose it just be added to the tutorial if it works for others.
I think the cases is that you setup Docker daemon as a non-root user (Rootless mode)
Although the gitea rootless image run gitea daemon as a non-root user, but the docker-setup.sh reuire root privilege to initialize the environment. So, its also reqired Docker daemon run as a root mode.
ah so perhaps we need to pre-prepare the rootless docker to have these directories ready in case the daemon is running as non-root?
+1 to @philip-peterson's fix!
For posterity and in the interest of providing a reproducible motivating example, here are some relevant sections of my scaffolding script for a homebrew gitea server (+ other things).
The script (within the context of this thread) ...
- ... runs on a bare debian 11 image, ...
- ... backs up gitea data (if present), ...
- ... deletes the work of all previous runs, ...
- ... sets up and starts a
gitea:dev-rootlessserver on a git.<domain> (nginx fwds the subdomain traffic to the local port gitea listens on)
Relevant sections:
- uid and gid of user
gitis1000 - back up or create from scratch
/home/git/ - create user
git - set
/home/git/permissions - start docker rootless
gitea - create
/usr/local/bin/gitea-shell- note: i added a line
docker context use rootlessto support ssh passthrough without adding mygituser to thedockergroup (effectively root access) - I'm still actively testing this and am not confident it works yet
- note: i added a line
/home/git/docker-compose.yml/etc/ssh/sshd_config
We have a similar issue in the helm chart: https://gitea.com/gitea/helm-chart/pulls/447
Writing into system-directories is not possible when running rootless. Maybe there could be a change for the rootless image WRT to to $HOME as proposed in the linked PR?
I was fine running rootless Gitea with root Docker and rootless Docker, but I ran into this issue after migrating to Docker Desktop (Linux); I got around the problem by setting I_AM_BEING_UNSAFE_RUNNING_AS_ROOT = true in the ini file, and user: root:root in the compose file. See https://github.com/docker/desktop-linux/issues/81.
I am also facing this issue. It seems to me that this design is fundamentally broken. Running Gitea as root in a rootless container shouldn't matter because the primary limiting factor in the security of the setup would be the security of the containerization technologies used. In my case, it is Podman. Sure, running Gitea as root can allow a malicious actor to do untold damage... to the container. If it somehow manages to exploit the container to the extent that it can infect the host system, well, the container is not running as root anyway - which is what matters. Ideally, the user that is running the container wouldn't have sudo or any other administrative privileges either - aside from systemd-journal for looking at logs, for example. Conversely, running Gitea rootless in a rootful container has marginally better security than running rootful in a rootless container because an exploit in the containerization technologies doesn't necessarily need root privileges inside of that container. If Gitea provides true support for running rootless containers, it should be considered to let Gitea inside the container run as root by default. Perhaps there is a better way by means of configuring the container's run parameters, but so far I haven't found the way that works for Gitea (for example, in my Joplin server I pass in --userns keep-id:uid=${id -u},gid=${id -g} to the podman run command in order to allow it to run as the correct user), and it would need to be documented in the setup. It's also not reasonable to expect that all users will want to run their rootless container as the first user created on their system. My Gitea user is the 14th user that I've created on my system. Perhaps the setup script could use the id commands as above in place of hard-coded values? Furthermore, in this instance, using the $HOME environment variable in configuration settings also seems to be not ideal as well. The $HOME environment variable is a default environment variable, so setting it to something different will most certainly break things.
Has there been any new development on this issue?
I ran into this issue as well, using this docker compose:
version: "2"
services:
server:
image: gitea/gitea:1.21.4-rootless
restart: always
volumes:
- ./data:/var/lib/gitea
- ./config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "2222:2222"
What I found is that when I spun up the container, the data and config folders were created as root. I stopped the container, and ran chown 1000:1000 data config to remap ownership to uid:gid 1000:1000 (which is the uid & gid of my principal user on the server.
I restarted the container and everything now works as expected
encountered the same problem, use podman but not docker.
Environment: Debian12, podman4.3.1, podman-compose1.0.3
follow the doc on https://docs.gitea.com/installation/install-with-docker-rootless
I have also try install on windows podman desktop, but this time I fixed the problem by edit docker-compose.yml add the line
version: "3"
services:
server:
image: gitea/gitea:latest-rootless
volumes:
- ./data:/var/lib/gitea
- ./config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "2222:2222"
+ userns_mode: "keep-id"
but on the linux this method failed. After tries, the only way I can successfully fix this is "chmod +rw"
I presume that it works on windows podman desktop because this podman-compose is an alias of the docker-compose.exe, and it parse the userns_mode: "keep-id" to a correct docker run cmd, but on linux, the podman-compose command is https://github.com/containers/podman-compose itself but not an alias.
[UPDATE 2024-3-6] Finally fixed this error by installing the docker-compose. From the idea of noticing podman on windows operating normally, I tried and it works!
Here is a way to fix it:
services:
server:
image: gitea/gitea:latest-rootless
userns_mode: keep-id:uid=1000,gid=1000
requires the use of podman-compose >= 1.0.6 or docker-compose >= 3.0
I met the same problem, and I think I found a simple solution:
Manually create folders ./data and ./config before run docker-compose up , before the root create it. Just like that:
mkdir data
mkdir config
docker-compose up
You should manually create the folder first, as docker will always create the folder under root permission if it is not existing. And it is not configurable. I think it is docker's fault.