Unable to push on binary installation #530

New Issue

GiteaMirror · 2025-11-02T03:26:59-06:00

GiteaMirror commented

2025-11-02 03:26:59 -06:00

Originally created by @aweiher on GitHub (Mar 17, 2017).

Gitea version (or commit ref): 1.1 ( https://dl.gitea.io/gitea/1.1/ )
Git version: 2.7.4
Operating system: Ubuntu 16.04.1
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

2017/03/17 18:18:57 [T] Custom path: /home/defel/bin/custom
2017/03/17 18:18:57 [T] Log path: /home/defel/Code/gitea/log
2017/03/17 18:18:58 Serving [::]:3030 with pid 5156

Description

I have freshly installed Gitea on localhost following the install from binary docs.

Then I created a user and a new repo.

Then I add this repo as a remote on my source repo and try to push.

Push (over http) fails with this error:

remote: 2017/03/17 18:19:18 [W] Custom config 'custom/conf/app.ini' not found, ignore this if you're running first time
remote: Gitea: Hook pre-receive init failed
remote: setup: Failed to connect to database: Unknown database type:

Originally created by @aweiher on GitHub (Mar 17, 2017). - Gitea version (or commit ref): 1.1 ( https://dl.gitea.io/gitea/1.1/ ) - Git version: 2.7.4 - Operating system: Ubuntu 16.04.1 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ``` 2017/03/17 18:18:57 [T] Custom path: /home/defel/bin/custom 2017/03/17 18:18:57 [T] Log path: /home/defel/Code/gitea/log 2017/03/17 18:18:58 Serving [::]:3030 with pid 5156 ``` ## Description I have freshly installed Gitea on localhost following the `install from binary` docs. Then I created a user and a new repo. Then I add this repo as a remote on my source repo and try to push. Push (over http) fails with this error: ``` remote: 2017/03/17 18:19:18 [W] Custom config 'custom/conf/app.ini' not found, ignore this if you're running first time remote: Gitea: Hook pre-receive init failed remote: setup: Failed to connect to database: Unknown database type: ```

GiteaMirror added the issue/stale type/bug labels 2025-11-02 03:27:00 -06:00

GiteaMirror closed this issue

2025-11-02 03:27:00 -06:00

GiteaMirror commented

2025-11-02 03:27:01 -06:00

@lunny commented on GitHub (Mar 18, 2017):

If you run the installation on the web, you should have a custom app.ini, so that you have a database type. You should visit /installation to config your self first.

@lunny commented on GitHub (Mar 18, 2017): If you run the installation on the web, you should have a custom app.ini, so that you have a database type. You should visit /installation to config your self first.

GiteaMirror commented

2025-11-02 03:27:01 -06:00

@aweiher commented on GitHub (Mar 18, 2017):

Yes, I have a custom app.ini under /home/defel/bin/custom/config/app.ini created by /installation. I was able to create a first user account and a repo with the web frontend. But I cant push to this repository.

@aweiher commented on GitHub (Mar 18, 2017): Yes, I have a custom app.ini under `/home/defel/bin/custom/config/app.ini` created by /installation. I was able to create a first user account and a repo with the web frontend. But I cant push to this repository.

GiteaMirror commented

2025-11-02 03:27:01 -06:00

@lunny commented on GitHub (Mar 18, 2017):

remote: 2017/03/17 18:19:18 [W] Custom config 'custom/conf/app.ini' not found, ignore this if you're running first time

but it seems the gitea serv cannot recognize your app.ini, maybe you can take a look at your authorized_keys to check it.

@lunny commented on GitHub (Mar 18, 2017): ``` remote: 2017/03/17 18:19:18 [W] Custom config 'custom/conf/app.ini' not found, ignore this if you're running first time ``` but it seems the `gitea serv` cannot recognize your app.ini, maybe you can take a look at your `authorized_keys` to check it.

GiteaMirror commented

2025-11-02 03:27:01 -06:00

@SpectralDuck commented on GitHub (Jul 10, 2018):

I think I had the same problem. I could browse the web interface and push through https, but pushing through ssh gave:

Gitea: System init failed
setup: Failed to connect to database: Unknown database type: 
fatal: Could not read from remote repository.

It looks like gitea serv through ssh was ignoring the config parameter passed through authorized_keys, because I worked around it by copying my config to /home/gitea/custom/conf/app.ini, even though gitea is configured to use /etc/gitea/app.ini in my .service file.

My authorized_keys:

# gitea public key
command="/usr/local/bin/gitea serv key-1 --config='/etc/gitea/app.ini'",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa my_public_key me@mypc`

@SpectralDuck commented on GitHub (Jul 10, 2018): I think I had the same problem. I could browse the web interface and push through https, but pushing through ssh gave: Gitea: System init failed setup: Failed to connect to database: Unknown database type: fatal: Could not read from remote repository. It looks like `gitea serv` through ssh was ignoring the config parameter passed through `authorized_keys`, because I worked around it by copying my config to `/home/gitea/custom/conf/app.ini`, even though gitea is configured to use `/etc/gitea/app.ini` in my .service file. My `authorized_keys`: # gitea public key command="/usr/local/bin/gitea serv key-1 --config='/etc/gitea/app.ini'",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa my_public_key me@mypc`

GiteaMirror commented

2025-11-02 03:27:01 -06:00

@alexandre-abrioux commented on GitHub (Aug 13, 2018):

I was able to fix this by entering an absolute path for the database file, as shown below.
I only have one configuration file unlike @SpectralDuck solution, located in /etc/gitea/app.ini.
But as he suggests it looks like behaviours are different depending on the service that loads it (gitea web vs. gitea serv) and relative paths don't seem to be targeting the same files.

[database]
DB_TYPE  = sqlite3
PATH     = /var/lib/gitea/data/gitea.db

@alexandre-abrioux commented on GitHub (Aug 13, 2018): I was able to fix this by entering an absolute path for the database file, as shown below. I only have one configuration file unlike @SpectralDuck solution, located in `/etc/gitea/app.ini`. But as he suggests it looks like behaviours are different depending on the service that loads it (`gitea web` vs. `gitea serv`) and relative paths don't seem to be targeting the same files. ``` [database] DB_TYPE = sqlite3 PATH = /var/lib/gitea/data/gitea.db ```

GiteaMirror commented

2025-11-02 03:27:01 -06:00

@lafriks commented on GitHub (Aug 13, 2018):

Yes seems to be that gitea serv does not have GITEA_DATA_DIR variable... We will need to think how to save/pass it from gitea web...

@lafriks commented on GitHub (Aug 13, 2018): Yes seems to be that gitea serv does not have `GITEA_DATA_DIR` variable... We will need to think how to save/pass it from gitea web...

GiteaMirror commented

2025-11-02 03:27:02 -06:00

@stale[bot] commented on GitHub (Jan 14, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 14, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 03:27:02 -06:00

@stale[bot] commented on GitHub (Feb 20, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Feb 20, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 11:46:28 -06:00

[PR #530] [MERGED] Search for issues/pulls #15435

GiteaMirror referenced this issue

2025-11-02 11:49:22 -06:00

[PR #755] [MERGED] bug fixed caused by #530 #15557

Sign in to join this conversation.