November 4, 20187 yr I have this docker working perfectly. Quick question, as I've attempted all over per Gitea's docs. Where would I create the 'custom' folder to be able to modify the templates? I've tried it in the /data directory, /data/gitea/... I can't get it to accept any modifications via any custom folder. Thanks.
January 6, 20197 yr port mapping is not working correctly mapped ssh port from 22 to 8097 but unraid docker list page still says 192.168.1.2:22 => 192.168.1.2:22 so I had to switch to bridged mode
January 6, 20197 yr 22 minutes ago, sadeq said: so I had to switch to bridged mode Because port mapping only works in bridged mode.
February 8, 20206 yr gitea is telling me the clone uri is: [email protected]:username/repo.git but I would like it to look like this instead: ssh://[email protected]:2244/username/repo.git Where can I change this setting?
February 8, 20206 yr 10 minutes ago, uek2wooF said: gitea is telling me the clone uri is: [email protected]:username/repo.git but I would like it to look like this instead: ssh://[email protected]:2244/username/repo.git Where can I change this setting? Ok all I had to do was set SSH_PORT in app.ini and it does it. I should have researched more before asking here.
November 6, 20205 yr Hi, woke up to Gieta not starting with this error: Quote Downgrading database version from '159' to '158' is not supported and may result in loss of data integrity. If you really know what you're doing, execute `UPDATE version SET version=158 WHERE id=1;` Received signal 15; terminating. please advise
November 7, 20205 yr I had the same problem with the downgrade on the database. This is how I solved it. 1. make a backup of the file in your appdata/gitea/gitea.db 2. copy the file appdata/gitea/gitea.db to your local computer 3. download a sqlite application that can view and edit. I used "DB Browser for SQLite" 4. open the local file gitea.db and look for where you can execute the command UPDATE version SET version=158 WHERE id=1; 5. save the changes 6. copy the file back to appdata/gitea/gitea.db 7. restart the docker container This worked for me. Just make sure you have a backup just in case.
November 7, 20205 yr @Nathan Chambers thank you for taking the time to post your solution for others. Your advise worked and was very clear/easy to follow. Internetpoints++ for you
November 14, 20205 yr I recently installed Gitea. This container seems to be upgraded every day, and with every update, Gitea gets installed anew, so the users and repositories, everything is gone. Do I have to backup/restore it manually before every update? Edited November 14, 20205 yr by kana Fix typo
November 14, 20205 yr 3 hours ago, kana said: I recently installed Gitea. This container seems to be upgraded every day, and with every update, Gitea gets installed anew, so the users and repositories, everything is gone. Do I have to backup/restore it manually before every update? Is your data folder pointing to a correct location ? Config and repos are stored in the data folder so for example if it points to appdata, an upgrade keeps the users and repos A month ago I got one issue with a new version but then I specified the version : gitea/gitea:1.14.0-dev and got my data back also no daily update anymore
November 19, 20205 yr My data storage path indeed points correctly to /mnt/user/appdata/gitea, but I still see the same issue, all context is gone after an update. When I look in /mnt/user/appdata/gitea/gitea, I see gitea.db which has not changed for 16 days now (I made approximately 10 updates in that time), and inside the "sessions" folder I see several folders with time stamps all before my today's commit, some are several days old, so the data itself seems to be persistent. Looks like gitea loses the ability to access that data with every update. Can the reason be that I'm using unraid 6.9.0-beta35 rather than the official version? Oh, btw, the command section of the Gitea update windows shows me "root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='Gitea' --net='bridge' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -p '3022:22/tcp' -p '3000:3000/tcp' -v '/mnt/user/appdata/gitea':'/data':'rw' 'gitea/gitea' da7e22c307253a32b7c2a0121a80a97ccba831315ec2a698d56cb8f678077d12 The command finished successfully!" The reference to the appdata folder in there looks ok, I see no indication the update itself screws things up.
November 22, 20205 yr Hi everyone, I've got gitea set up and running through the web UI internally but am having some trouble getting it to be accessible through a web url, I am just getting 502 errors. I have it set up using port 24 for SSH as 22 was taken by something else and have got it working with a mysql database through MariaDB. It has a https certificate from swag and that all seems to be fine, I have also added a CNAME record through cloudflare for the subdomain. I have edited the appdata/gitea/gitea/conf/app.ini file to have [server] DOMAIN = gitea.myserver.com SSH_DOMAIN = gitea.myserver.com HTTP_PORT = 3000 ROOT_URL = https://gitea.myserver.com DISABLE_SSH = false SSH_PORT = 24 SSH_LISTEN_PORT = 24 and have saved a copy of /swag/nginx/proxy-confs/gitea.subdomain.conf.sample as gitea.subdomain.conf I have changed round the SSH_PORT and SSH_LISTEN_PORT in the app.ini file to variations of 22 and 24 as I am not sure which it should be and where, advice on this would be appreciated. Gitea is running on a custom network with the ssh port mappings: 172.18.0.5:22/TCP <-> 192.168.1.41:24 Nextcloud and collabora are also on the custom network and are working perfectly on their subdomains. There are no errors in the swag or gitea log files.
November 29, 20205 yr I`m having a similar issue as above. I configured Gitea to work on my local network just fine, but once I tried configuring it to work by letsencrypt using the configuration provided by the website it does not work: app.ini: ... [server] APP_DATA_PATH = /data/gitea PROTOCOL = https DOMAIN = mygitdomain.duckdns.org SSH_DOMAIN = mygitdomain.duckdns.org ENABLE_LETSENCRYPT = true LETSENCRYPT_ACCEPTTOS = true LETSENCRYPT_DIRECTORY = https LETSENCRYPT_EMAIL = [email protected] HTTP_PORT = 3000 ROOT_URL = https://mygitdomain.duckdns.org/ DISABLE_SSH = true SSH_PORT = 22 SSH_LISTEN_PORT = 22 OFFLINE_MODE = false ... subdomain.conf ... server { listen 443 ssl; listen [::]:443 ssl; server_name mygitdomain.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app gitea; set $upstream_port 3000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } ... any suggestions? the Gitea log spits out: ... [36m2020/11/29 02:40:54 [0m[32m...s/graceful/server.go:79:[32mListenAndServe()[0m [1;31m[E][0m Unable to GetListener: [1mlisten tcp 0.0.0.0:80: bind: permission denied[0m [36m2020/11/29 02:40:54 [0m[32mcmd/web.go:87:[32mfunc1()[0m [1;41m[F][0m Failed to start the Let's Encrypt handler on port [1m80[0m: [1mlisten tcp 0.0.0.0:80: bind: permission denied[0m ... I think there is something wrong as Gitea is trying to bind port 80 and fails. I dont understand why its trying to.
November 29, 20205 yr I managed to make it work by using the following configurations: app.ini: ... [server] APP_DATA_PATH = /data/gitea PROTOCOL = http DOMAIN = mygitdomain.duckdns.org HTTP_PORT = 3000 ENABLE_LETSENCRYPT = true LETSENCRYPT_ACCEPTTOS = true LETSENCRYPT_DIRECTORY = https OFFLINE_MODE = false ... subdomain.conf ... server { listen 443 ssl; listen [::]:443 ssl; server_name mygitdomain.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app gitea; set $upstream_port 3000; set $upstream_proto http; proxy_pass http://[LOCAL IP OF THE SERVER]:3000; } } ...
December 4, 20205 yr On 11/29/2020 at 7:46 PM, Norton Barbieri said: I managed to make it work by using the following configurations: app.ini: ... [server] APP_DATA_PATH = /data/gitea PROTOCOL = http DOMAIN = mygitdomain.duckdns.org HTTP_PORT = 3000 ENABLE_LETSENCRYPT = true LETSENCRYPT_ACCEPTTOS = true LETSENCRYPT_DIRECTORY = https OFFLINE_MODE = false ... subdomain.conf ... server { listen 443 ssl; listen [::]:443 ssl; server_name mygitdomain.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app gitea; set $upstream_port 3000; set $upstream_proto http; proxy_pass http://[LOCAL IP OF THE SERVER]:3000; } } ... Legend, done the above and it's all working for me.
December 5, 20205 yr Hi， Thanks for your great work! But there is a problem that the tag :latest will install the current development version. For a stable release you can use :1 or specify a certain release like :1.13.0 I think stable release will be better. Here is gitea offical doc: https://docs.gitea.io/en-us/install-with-docker/
December 5, 20205 yr Tried going back to release 1.13 from latest, but I got some error regarding downgrading the database. I guess I'll stick to the next stable release as soon as it happens. Thanks for the support
December 21, 20205 yr Latest version of this container is not working for me either, cant load the webpage at all. What is the best method to downgrade in UnRaid? Delete it and add it again from CA? Ensuring I specify a specific release? Will all the repos/data I had in Gitea be restored or have I lost all that now?
March 26, 20215 yr im new to docker and unraid and was able to install this docket gitea, i just have some doubts, are the git repositories are contained inside the img file ? or those are actually saved in the host filesystem (appdata ?) are the git files in risk when the docker gets update/removed ? My objective is to have my home git server with the files being saved in the unraid array (i know files are already there) but have the git files accesible as a share in case i want to move them somewhere else , basically i would not want to have files encapsulated in an img file or dependant somehow to the docker container.
March 26, 20215 yr So after playing around , i found that i could create a share then take the path of that share (/mnt/user/repos) and when creating the gitea docker we can create a rule to map host /mnt/user/CyberRepos to guest /data , that way when the docker is created the git files actually show in the share . Then i found and option in plugin "fix common problems" to exclude my share from getting its file permissions changed which i guess might help to keep the files safe ? The last test i made was to remove the docker to see if the git files remained which it seems to be the case. But again, im a noob so i might be taking some shortcuts or bad practices, hope someone can confirm this is the right approach to keep git files safe. Edited March 26, 20215 yr by morty
May 10, 20215 yr On 11/6/2017 at 3:13 PM, cglatot said: Thanks @Ezro - I'm using a different format since I use relative URLs instead of subdomains so I had to take a different method, but seeing yours helped! Hope you can get nextcloud working Hey! I have the exact same issue on NginxProxyManager. Do you remember what did you do to solve that error?
May 15, 20215 yr On 1/16/2018 at 1:04 PM, CrunchyToast said: Thanks for your response. I did that, but it only wants to work on 3000 no matter what I do. In unRaid if you edit the gitea configs and hit the toggle in the upper right for advanced you will get a field like this where you can set the web ui port
May 31, 20215 yr Did someone succeed opening connecting via SSH through NPM? I can only connect via LAN IP not domain.name
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.