gitea icon indicating copy to clipboard operation
gitea copied to clipboard

Gitea rootless setup error: mkdir: can't create directory '/var/lib/gitea/git': Permission denied

Open jpdelmundo opened this issue 2 years ago • 21 comments

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

jpdelmundo avatar Jan 03 '23 09:01 jpdelmundo

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).

jrjake avatar Jan 05 '23 21:01 jrjake

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.

thinegen avatar Jan 07 '23 16:01 thinegen

@wfjake

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).

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 avatar Jan 07 '23 16:01 jpdelmundo

@jpdelmundo Did you managed to find a solution? Im having the same issue in virtualy the exact same environment as yours.

ScarUY avatar Jan 13 '23 13:01 ScarUY

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.

thinegen avatar Jan 18 '23 14:01 thinegen

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?

zeripath avatar Jan 18 '23 17:01 zeripath

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.

thinegen avatar Jan 18 '23 17:01 thinegen

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.

thinegen avatar Feb 01 '23 13:02 thinegen

You can prevent Gitea from trying to create the directory by making it yourself. Inside ./data:

mkdir git

philip-peterson avatar Feb 06 '23 00:02 philip-peterson

^ For me this was the fix for this error. I'd propose it just be added to the tutorial if it works for others.

philip-peterson avatar Feb 06 '23 03:02 philip-peterson

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.

ghost avatar Feb 06 '23 03:02 ghost

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?

zeripath avatar Feb 06 '23 12:02 zeripath

+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) ...

  1. ... runs on a bare debian 11 image, ...
  2. ... backs up gitea data (if present), ...
  3. ... deletes the work of all previous runs, ...
  4. ... sets up and starts a gitea:dev-rootless server on a git.<domain> (nginx fwds the subdomain traffic to the local port gitea listens on)

Relevant sections:

  1. uid and gid of user git is 1000
  2. back up or create from scratch /home/git/
  3. create user git
  4. set /home/git/ permissions
  5. start docker rootless gitea
  6. create /usr/local/bin/gitea-shell
    • note: i added a line docker context use rootless to support ssh passthrough without adding my git user to the docker group (effectively root access) - I'm still actively testing this and am not confident it works yet
  7. /home/git/docker-compose.yml
  8. /etc/ssh/sshd_config

cakekindel avatar May 19 '23 03:05 cakekindel

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?

pat-s avatar May 21 '23 21:05 pat-s

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.

agcom avatar Sep 26 '23 11:09 agcom

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.

LinuxDragon57 avatar Oct 06 '23 05:10 LinuxDragon57

Has there been any new development on this issue?

malonzhao avatar Dec 19 '23 09:12 malonzhao

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

hnt3b453 avatar Feb 03 '24 21:02 hnt3b453

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 gitea_err_2024-3-5 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!

StevenModin avatar Mar 05 '24 14:03 StevenModin

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

Deflaktor avatar Apr 28 '24 23:04 Deflaktor

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

zzkluck avatar Aug 21 '24 06:08 zzkluck

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.

yp05327 avatar Sep 26 '24 02:09 yp05327