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.

IM having a hell of time getting SSH to work with gitea. Im using a custom network and have it mapped to 25 on the host. I have set the port to 25 in the app.ini and restarted. When trying to clone a repo, it just hangs at cloning repo. I have already added my key to gitea.

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

@Zotarios, did you found a solution?

 

I am also using nginx proxy manager. When I git clone using ssh, it works locally, but not for remote server. I think it has something to do with NPM port

Heyy, I'm new to Gitea and wanted to change the domain in app.ini. The change is never applied, even after restarting the Docker container or the entire Unraid server. Do you have an idea what I did wrong?

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?

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 June 16, 20224 yr by SixClover

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 August 4, 20223 yr by entropic

On https://docs.gitea.io/en-us/fail2ban-setup/, it states we need to add the following:

proxy_set_header X-Real-IP $remote_addr;

Where in the SWAG config would I add this?

Edited September 21, 20223 yr by Hammy Havoc

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.

 

6 minutes ago, jafi said:

Cannot install.

 

That's usually some issue with your docker image, not the specific container.

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.

 

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:

 

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.

Perms are 755 for me, owner is my first samba user from when I did the transfer back then...

 

Is the folder structure right?

 

 

 

 

Edited May 15, 20233 yr by Kilrah

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

 

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 May 16, 20233 yr by buee
Updated information

4 hours ago, buee said:

tree looks similar to yours

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)

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!

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

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.

 

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.

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.

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.

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 October 19, 20232 yr by Rexima

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

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 March 7, 20242 yr by Generic

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.

In case anyone had the same issue as above, I have no idea what was actually wrong but after spending hours mucking around trying different things what I believe fixed it was using `git clone http://....` rather than `git clone https://...`.

 

This bought up the git credential manager instead of opening a browser page of my server login, and upon putting my user/password into the manager (it should have already had both and in fact had the user name auto-filled so beats me) it all worked.

Now it is back to all working with using `git clone https://...` as it was previously and in fact git will give me an output saying it is changing over to https if I use http.

 

Again, I have no idea why this happened or what was going on but it seems to be working and I'm not going to worry about it any more then that.

Edited April 1, 20242 yr by Generic