LTM Posted July 21, 2021 Share Posted July 21, 2021 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. 1 Quote Link to comment
mkono87 Posted October 13, 2021 Share Posted October 13, 2021 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. Quote Link to comment
ICULikeMac Posted January 8, 2022 Share Posted January 8, 2022 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 Quote Link to comment
shawnngtq Posted February 5, 2022 Share Posted February 5, 2022 @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 Quote Link to comment
Timo Stöckmann Posted February 8, 2022 Share Posted February 8, 2022 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? Quote Link to comment
Raleford Posted March 21, 2022 Share Posted March 21, 2022 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? Quote Link to comment
SixClover Posted June 16, 2022 Share Posted June 16, 2022 (edited) 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, 2022 by SixClover Quote Link to comment
entropic Posted August 4, 2022 Share Posted August 4, 2022 (edited) 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, 2022 by entropic Quote Link to comment
Hammy Havoc Posted September 21, 2022 Share Posted September 21, 2022 (edited) 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, 2022 by Hammy Havoc Quote Link to comment
jafi Posted January 4, 2023 Share Posted January 4, 2023 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. Quote Link to comment
Kilrah Posted January 4, 2023 Share Posted January 4, 2023 6 minutes ago, jafi said: Cannot install. That's usually some issue with your docker image, not the specific container. 1 Quote Link to comment
pkoasne Posted January 13, 2023 Share Posted January 13, 2023 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. Quote Link to comment
buee Posted May 15, 2023 Share Posted May 15, 2023 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. Quote Link to comment
Kilrah Posted May 15, 2023 Share Posted May 15, 2023 (edited) 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, 2023 by Kilrah 1 Quote Link to comment
buee Posted May 16, 2023 Share Posted May 16, 2023 (edited) 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, 2023 by buee Updated information Quote Link to comment
Kilrah Posted May 16, 2023 Share Posted May 16, 2023 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) 1 Quote Link to comment
buee Posted May 16, 2023 Share Posted May 16, 2023 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! 1 Quote Link to comment
laromicas Posted July 4, 2023 Share Posted July 4, 2023 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. Quote Link to comment
adibue Posted July 19, 2023 Share Posted July 19, 2023 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. 3 1 Quote Link to comment
urmyboyblue Posted July 23, 2023 Share Posted July 23, 2023 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. Quote Link to comment
Rexima Posted October 19, 2023 Share Posted October 19, 2023 (edited) 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, 2023 by Rexima Quote Link to comment
brentk Posted January 26 Share Posted January 26 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 Quote Link to comment
Generic Posted March 7 Share Posted March 7 (edited) 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 by Generic Quote Link to comment
Sn3akyP3t3 Posted March 22 Share Posted March 22 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. Quote Link to comment
Generic Posted April 1 Share Posted April 1 (edited) 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 by Generic Quote Link to comment
Recommended Posts
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.