[Support] Gitea


Recommended Posts

Has anyone been able to get this container to work recently? I am trying to run it and any time I try to start it, all I get is "Execution error. Server error." I have tried deleting the container, image, and config files and starting from complete scratch. No dice.

  • Upvote 1
Link to comment
  • 2 months later...
  • 2 months later...
On 7/21/2021 at 11:39 AM, LTM said:

Has anyone been able to get this container to work recently? I am trying to run it and any time I try to start it, all I get is "Execution error. Server error." I have tried deleting the container, image, and config files and starting from complete scratch. No dice.

The way I got it to start was to change the port from 22 to 8022

Link to comment
  • 4 weeks later...
  • 1 month later...
On 1/7/2022 at 6:48 PM, ICULikeMac said:

The way I got it to start was to change the port from 22 to 8022

I just updated today and it broke mine instance with the same "execution error" and this solution fixed it for me, so just wanted to say thank you. I assume it must have something to do with trying to double bind a port or some such?

Link to comment
  • 2 months later...

Every single time I update this docker it adds in the default ports, as in, appends redundant configuration settings and not just reverts my existing ones. I then have to go into the docker settings and delete the two newly added default ports to get this working again.

 

I have custom ports configured, this works, leave it alone, stop appending new default ports - then this won't break on every single update.

 

:) All of the other dockers manage to do this, if they can update without screwing with the ports then so can you. 

Edited by SixClover
Link to comment
  • 1 month later...
On 1/7/2022 at 4:48 PM, ICULikeMac said:

The way I got it to start was to change the port from 22 to 8022

So confused why this specifically works.

Originally I setup the SSH port as 9772 but it would not work regardless of what I tried; switched it to port 8020 and it works perfectly now...

 

Edit: Turns out my issue was not the port, but the usage of Cloudflare Proxy. Beware that cloudflare will not forward the request even if it is meant to use another port other than 80/443

Edited by entropic
Link to comment
  • 1 month later...
  • 3 months later...

Cannot install.

 

Command execution
docker run
  -d
  --name='gitea'
  --net='IPZD'
  -e TZ="True/Hell"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="666"
  -e HOST_CONTAINERNAME="gitea"
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:3000]'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/fanningert/unraid-docker-templates/master/fanningert/icons/gitea.png'
  -p '22:22/tcp'
  -p '3000:3000/tcp'
  -v '/mnt/user/appdata/gitea':'/data':'rw' 'gitea/gitea'
docker: Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/41d60f1fea4ae0c5b9965a6f0f190f77beafe0355bfbe8bc8126029c62f47a7d-init/merged: too many levels of symbolic links.
See 'docker run --help'.

The command failed.

 

Link to comment
  • 2 weeks later...

has anyone been able to get this working again? I'm stuck with this:

 

Server listening on :: port 22.
Server listening on 0.0.0.0 port 22.
2023/01/12 05:43:34 cmd/web.go:106:runWeb() [I] Starting Gitea on PID: 18
2023/01/12 05:43:34 ...s/setting/setting.go:613:deprecatedSetting() [E] Deprecated fallback `[server]` `LFS_CONTENT_PATH` present. Use `[lfs]` `PATH` instead. This fallback will be removed in v1.19.0
2023/01/12 05:43:34 cmd/web.go:160:runWeb() [I] Global init
2023/01/12 05:43:34 ...s/setting/setting.go:613:deprecatedSetting() [E] Deprecated fallback `[server]` `LFS_CONTENT_PATH` present. Use `[lfs]` `PATH` instead. This fallback will be removed in v1.19.0
2023/01/12 05:43:34 routers/init.go:116:GlobalInitInstalled() [I] Git Version: 2.36.3, Wire Protocol Version 2 Enabled (home: /data/gitea/home)
2023/01/12 05:43:34 routers/init.go:117:GlobalInitInstalled() [I] AppPath: /usr/local/bin/gitea
2023/01/12 05:43:34 routers/init.go:118:GlobalInitInstalled() [I] AppWorkPath: /app/gitea
2023/01/12 05:43:34 routers/init.go:119:GlobalInitInstalled() [I] Custom path: /data/gitea
2023/01/12 05:43:34 routers/init.go:120:GlobalInitInstalled() [I] Log path: /data/gitea/log
2023/01/12 05:43:34 routers/init.go:121:GlobalInitInstalled() [I] Configuration file: /data/gitea/conf/app.ini
2023/01/12 05:43:34 routers/init.go:122:GlobalInitInstalled() [I] Run Mode: Prod
Received signal 15; terminating.

 

Link to comment
  • 4 months later...

I'm in the process of switching from Synology to Unraid. One issue I'm having is getting Gitea operational again. Gitea was a docker container on Synology and obviously a docker container on Unraid, was hoping it'd be simple.

 

I rsync'd over the appdata, had to tweak the web port from 3000 to 3001, ssh port is the same. Originally, I was getting the install web page, but I fixed that with some permissions. Now I can login with my normal username and password to the webui.

 

Problem now is all my repos in the webui say:

image.thumb.png.20615488f6397448930a6f9fd8e17307.png

 

And when I try to push changes to a branch:

Gitea: Incorrect configuration, no repository directory.
Gitea: Internal error
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

 

I deleted and re-added my SSH key from this particular machine, no joy. I imagine it has to be permissions related. Docker logs just show the API hits, no errors.

 

Any advice? I really don't want to start over from scratch if it can be avoided.

Link to comment

Yup, same here, same username as the first share created. Perms look right, tree looks similar to yours:

image.png.0724dbfbd05ce49bd487b0459c89443f.png

 

Everything in the ssh folder is owned by root:root and has 600 permissions which is what I'd expect for SSH keys

My DB appears to be 644, I'm thinking that's (at least part of) the issue. I had issues with the container giving me the install page and had to copy over the DB alone to get out of that loop.

 

Edit: Nope, that wasn't it, changed it, didn't work, changed it back. Also, when I was in Site Admin, there was an error about my root_url. Fixed the error, but still can't see the repos

 

I see this within the Gitea System Notices

May 15, 2023

Failed to health check repository (buee/gps_tracker): fork/exec /usr/bin/git: no such file or directory


So I checked it:

/ # which git
/usr/bin/git
/ # ls -alh /usr/bin/git
-rwxr-xr-x    1 root     root        2.7M Apr 25 17:13 /usr/bin/git

root != buee

The env var for USER is buee but it's still executable for anyone...

Edited by buee
Updated information
Link to comment
9 hours ago, Kilrah said:

Not really, you're missing git/repositories, that's where all repos are supposed to be! (didn't include them in tree because sensitive names)

Ah, I was solely looking at permissions, users, and groups. Didn't even catch that. No idea how that did not get synced over with everything else.

 

I rsynced it again, checked permissions, had to modify the app.ini file again to reflect the new IP/hostnames, etc. But it appears as though I can see the repos and push to them now. Thanks Kilrah!

  • Like 1
Link to comment
  • 1 month later...

Hi Guys, I am having issues when running gitea, when run it runs perfectly, but after a while it loses the repositories mapping.

image.png.34eabaa2ea19c62831eb99a58ba6ec19.png
In the image you can see that in the first run there is a mapping for repositories and in the second run, this mapping disappeared.

 

It seems to happen when sync repos begin, but I have not been able to replicate consistently.


image.png.d9ef75387509baf32b6ebc0e1b608b9c.png

 

Have you found something similar? I have been trying to access more logs to see what can be happening without success.

 

Note: I have several other docker containers with the same volumes and it only happens with gitea and the repositories volume.

 

Thanks in advance.

image.png

image.png

image.png

Link to comment
  • 2 weeks later...
On 1/13/2023 at 9:57 PM, pkoasne said:

has anyone been able to get this working again? I'm stuck with this:

 

Server listening on :: port 22.
Server listening on 0.0.0.0 port 22.
2023/01/12 05:43:34 cmd/web.go:106:runWeb() [I] Starting Gitea on PID: 18
2023/01/12 05:43:34 ...s/setting/setting.go:613:deprecatedSetting() [E] Deprecated fallback `[server]` `LFS_CONTENT_PATH` present. Use `[lfs]` `PATH` instead. This fallback will be removed in v1.19.0
2023/01/12 05:43:34 cmd/web.go:160:runWeb() [I] Global init
2023/01/12 05:43:34 ...s/setting/setting.go:613:deprecatedSetting() [E] Deprecated fallback `[server]` `LFS_CONTENT_PATH` present. Use `[lfs]` `PATH` instead. This fallback will be removed in v1.19.0
2023/01/12 05:43:34 routers/init.go:116:GlobalInitInstalled() [I] Git Version: 2.36.3, Wire Protocol Version 2 Enabled (home: /data/gitea/home)
2023/01/12 05:43:34 routers/init.go:117:GlobalInitInstalled() [I] AppPath: /usr/local/bin/gitea
2023/01/12 05:43:34 routers/init.go:118:GlobalInitInstalled() [I] AppWorkPath: /app/gitea
2023/01/12 05:43:34 routers/init.go:119:GlobalInitInstalled() [I] Custom path: /data/gitea
2023/01/12 05:43:34 routers/init.go:120:GlobalInitInstalled() [I] Log path: /data/gitea/log
2023/01/12 05:43:34 routers/init.go:121:GlobalInitInstalled() [I] Configuration file: /data/gitea/conf/app.ini
2023/01/12 05:43:34 routers/init.go:122:GlobalInitInstalled() [I] Run Mode: Prod
Received signal 15; terminating.

 

 

 In case anyone runs into the same issue, here's how to fix it:

 

Stop the Gitea container and change into the following folder:

appdata/gitea/data/gitea/conf

 

Edit the app.ini file to the following:

 

Comment out this line:

[server]
...
#LFS_CONTENT_PATH=/data/git/lfs

Add those lines:

[lfs]
PATH=/data/git/lfs

 

Start the Gitea container.

  • Like 3
  • Upvote 1
Link to comment
On 1/13/2023 at 3:57 PM, pkoasne said:

has anyone been able to get this working again? I'm stuck with this:

 

Server listening on :: port 22.
Server listening on 0.0.0.0 port 22.
2023/01/12 05:43:34 cmd/web.go:106:runWeb() [I] Starting Gitea on PID: 18
2023/01/12 05:43:34 ...s/setting/setting.go:613:deprecatedSetting() [E] Deprecated fallback `[server]` `LFS_CONTENT_PATH` present. Use `[lfs]` `PATH` instead. This fallback will be removed in v1.19.0
2023/01/12 05:43:34 cmd/web.go:160:runWeb() [I] Global init
2023/01/12 05:43:34 ...s/setting/setting.go:613:deprecatedSetting() [E] Deprecated fallback `[server]` `LFS_CONTENT_PATH` present. Use `[lfs]` `PATH` instead. This fallback will be removed in v1.19.0
2023/01/12 05:43:34 routers/init.go:116:GlobalInitInstalled() [I] Git Version: 2.36.3, Wire Protocol Version 2 Enabled (home: /data/gitea/home)
2023/01/12 05:43:34 routers/init.go:117:GlobalInitInstalled() [I] AppPath: /usr/local/bin/gitea
2023/01/12 05:43:34 routers/init.go:118:GlobalInitInstalled() [I] AppWorkPath: /app/gitea
2023/01/12 05:43:34 routers/init.go:119:GlobalInitInstalled() [I] Custom path: /data/gitea
2023/01/12 05:43:34 routers/init.go:120:GlobalInitInstalled() [I] Log path: /data/gitea/log
2023/01/12 05:43:34 routers/init.go:121:GlobalInitInstalled() [I] Configuration file: /data/gitea/conf/app.ini
2023/01/12 05:43:34 routers/init.go:122:GlobalInitInstalled() [I] Run Mode: Prod
Received signal 15; terminating.

 

 

https://github.com/go-gitea/gitea/issues/25915#issuecomment-1640933269
 

Followed this to get mine working.

Link to comment
  • 2 months later...

I'm trying to run gitea with an separate mariadb container, but i can't connect to it, i get everytime this error
 

Datenbankeinstellungen sind ungültig: dial tcp 10.0.0.10:3306: connect: no route to host

But with an tool on my pc, i can connect to it, without any problem.

Unraid Host / MariaDB Docker IP: 10.0.0.10
Unraid Host / Gitea Docker IP: 10.0.0.220

Edit: Running Gitea without an custom bridge and let it running at the same ip address like mariadb, it works. 

Edited by Rexima
Link to comment
  • 3 months later...

Just installed this container. I couldn't access the web interface until i edited the file /appdata/gitea/gitea/conf/app.ini

(Default settings do not work)

Changed

[server]
APP_DATA_PATH = /data/gitea
DOMAIN = x.x.x.x
SSH_DOMAIN = x.x.x.x
HTTP_PORT = 8300
ROOT_URL = http://x.x.x.x:8300/


to:
 

[server]
APP_DATA_PATH = /data/gitea
DOMAIN = x.x.x.x
SSH_DOMAIN = x.x.x.x
HTTP_PORT = 3000
ROOT_URL = http://x.x.x.x:8300/


So it matches the default container HTTP port of 3000

Link to comment
  • 1 month later...

Hi All,

 

I've had Gitea running for quite a while and it's all been working great. However, that was with all the repos set to public, I've now changed it so that some repos are private and am now struggling to access them through Git CLI. It still works perfectly through the browser and I can pull public repos with no issues.

 

When I try and clone a private repo using HTTPS it first opens a login page on my Gitea instance and then when I log in it redirects to an error page, with firefox saying:

 

    Secure Connection Failed

   

    An error occurred during a connection to 127.0.0.1:58683. SSL received a record that exceeded the maximum permissible length.

    Error code: SSL_ERROR_RX_RECORD_TOO_LONG

 

This is consistent on other browsers and I haven't been able to figure out why it is happening.

 

Looking through the socker logs as I request the repo shows:

 

    024/03/07 17:26:35 ...eb/routing/logger.go:102:func1() router: completed GET {REPO}.git/info/refs?service=git-upload-pack for 172.19.0.2:46594, 401 Unauthorized in 4.4ms @ repo/githttp.go:532(repo.GetInfoRefs)


    2024/03/07 17:26:40 ...eb/routing/logger.go:102:func1() router: completed GET /login/oauth/authorize?response_type=code&client_id={VALUE}&state={VALUE}&code_challenge_method=S256&code_challenge=k_{VALUE}&redirect_uri=http%3a%2f%2f127.0.0.1%3a50480%2f for 172.19.0.2:46618, 303 See Other in 14.8ms @ auth/oauth.go:362(auth.AuthorizeOAuth)

 

 

Which doesn't seem to show an obvious problems? Again, I can access everything perfectly normally through the browser it's just trying to pull it over Git CLI.

 

 

As a bonus question, does anyone have a guide for setting up SSH? I can't figure out how that works either. I have a SSH key (called "id_ed25519") in ~/.ssh which I have registered with the SSH agent as described [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#adding-your-ssh-key-to-the-ssh-agent) as well as adding and verifying the key on my GItea account through the browser.

 

When I then try and clone a repo using the address given on the browser, `git clone ssh://git@gitea.{MY_DOMAIN}:24/{REPO}.git`, then it just times out and says the host is unreachable. I realise SSH is typically port 22 but that is already used and so the container won't start if it tries to use that port so it is changed to "Git over SSH container port 22, host port 24". and shows up as SWAG connecting the host port 24 to the container port 22. SSH is enabled in the app.ini file for Gitea.

 

I can post any more configuration files if required but am honestly not sure what is pertinent.

 

Thanks in advance.

Edited by Generic
Link to comment
  • 3 weeks later...
On 3/7/2024 at 1:42 AM, Generic said:

Hi All,

 

I've had Gitea running for quite a while and it's all been working great. However, that was with all the repos set to public, I've now changed it so that some repos are private and am now struggling to access them through Git CLI. It still works perfectly through the browser and I can pull public repos with no issues.

 

When I try and clone a private repo using HTTPS it first opens a login page on my Gitea instance and then when I log in it redirects to an error page, with firefox saying:

 

    Secure Connection Failed

   

    An error occurred during a connection to 127.0.0.1:58683. SSL received a record that exceeded the maximum permissible length.

    Error code: SSL_ERROR_RX_RECORD_TOO_LONG

 

This is consistent on other browsers and I haven't been able to figure out why it is happening.

 

Looking through the socker logs as I request the repo shows:

 

    024/03/07 17:26:35 ...eb/routing/logger.go:102:func1() router: completed GET {REPO}.git/info/refs?service=git-upload-pack for 172.19.0.2:46594, 401 Unauthorized in 4.4ms @ repo/githttp.go:532(repo.GetInfoRefs)


    2024/03/07 17:26:40 ...eb/routing/logger.go:102:func1() router: completed GET /login/oauth/authorize?response_type=code&client_id={VALUE}&state={VALUE}&code_challenge_method=S256&code_challenge=k_{VALUE}&redirect_uri=http%3a%2f%2f127.0.0.1%3a50480%2f for 172.19.0.2:46618, 303 See Other in 14.8ms @ auth/oauth.go:362(auth.AuthorizeOAuth)

 

 

Which doesn't seem to show an obvious problems? Again, I can access everything perfectly normally through the browser it's just trying to pull it over Git CLI.

 

 

As a bonus question, does anyone have a guide for setting up SSH? I can't figure out how that works either. I have a SSH key (called "id_ed25519") in ~/.ssh which I have registered with the SSH agent as described [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#adding-your-ssh-key-to-the-ssh-agent) as well as adding and verifying the key on my GItea account through the browser.

 

When I then try and clone a repo using the address given on the browser, `git clone ssh://git@gitea.{MY_DOMAIN}:24/{REPO}.git`, then it just times out and says the host is unreachable. I realise SSH is typically port 22 but that is already used and so the container won't start if it tries to use that port so it is changed to "Git over SSH container port 22, host port 24". and shows up as SWAG connecting the host port 24 to the container port 22. SSH is enabled in the app.ini file for Gitea.

 

I can post any more configuration files if required but am honestly not sure what is pertinent.

 

Thanks in advance.


I don't think I have a silver bullet solution to your particular problem, but I do believe you can benefit from some trial and error with suggested settings and revisit your current setup if you wish to apply another layer to what you have which might actually solve your issue.

So I was getting similar symptoms you described with
 

Quote

 

    An error occurred during a connection to 127.0.0.1:58683. SSL received a record that exceeded the maximum permissible length.

    Error code: SSL_ERROR_RX_RECORD_TOO_LONG

 

and I'm not exactly sure what the cause or fix was, but I suspected it had to do with TLS error that was showing itself in the Gitea logs.  I don't know what I changed that fixed the problem, but this is what I did along the way so pick at it for details and see if one or more helps you:

  • Settings in Gitea's App.ini need tweaking or triple checking:
    • PROTOCOL must match what you're doing in the reverse proxy
    • DOMAIN, SSH_DOMAIN, and ROOT_URL also must agree with the reverse proxy config
    • I downgraded TLS for now since there was talk about it being a culprit:
      • SSL_MIN_VERSION = TLSv1.0
      • Also downgraded minimum on Cloudflare to TLSv1.0 which may not be applicable to you.
    • Above and beyond, but set FILE_MAX_SIZE to something high-ish like 512.  (located under [repository.upload])
  • Triple check your reverse proxy config.  Adopt SWAG docker container and/or view this mighty fine template and conform it to your environment.
  • Walkthrough the guide from Cloudflare for setting with GitLab.  Note the comments at the bottom of that page for dealing with push/pull over SSH.  This might be a good use-case for routing it through Cloudflare Zero Trust.
  • Combine the previous guide from Cloudflare with the IBRACORP guide for setting up a Cloudflare Tunnel. NOTE: I found this guide invaluable in getting things setup right.
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.