"Username or password is not correct" when running as windows service #303

Closed
opened 2025-11-02 03:17:43 -06:00 by GiteaMirror · 5 comments
Owner

Originally created by @DocumentRoot on GitHub (Jan 30, 2017).

  • Gitea version (or commit ref): 1.0.1
  • Git version: 2.11.0.windows.1
  • Operating system: Windows 10
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

When running Gitea as windows service i cannot login to it, got "Username or password is not correct".
I have only one account, its root:password, password is copied from keepass, so no mistake here.
I stop service, run 'gitea web' manually, and now i can login. but not when i run it as a service.
...

Originally created by @DocumentRoot on GitHub (Jan 30, 2017). - Gitea version (or commit ref): 1.0.1 - Git version: 2.11.0.windows.1 - Operating system: Windows 10 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description When running Gitea as windows service i cannot login to it, got "Username or password is not correct". I have only one account, its root:password, password is copied from keepass, so no mistake here. I stop service, run 'gitea web' manually, and now i can login. but not when i run it as a service. ...
GiteaMirror added the issue/not-a-bug label 2025-11-02 03:17:43 -06:00
Author
Owner

@lunny commented on GitHub (Jan 30, 2017):

Could you test it in master? I think there is already a PR to fix this.

@lunny commented on GitHub (Jan 30, 2017): Could you test it in master? I think there is already a PR to fix this.
Author
Owner

@DocumentRoot commented on GitHub (Jan 30, 2017):

Same on master (Gitea Version: 1.0.0+149-g8bc4319)
(I'm sure I recreate service with new name and gitea-master-windows-4.0-amd64.exe target)

I realized what happens, when I tried to clean install database running Gitea as a service...

Manual gitea web uses data/ directory to store db,
but gitea service uses c:\windows\system32\data (even if relative to gitea.exe data/gitea.db exists)

So I delete c:\Windows\System32\data and create symlink:
mklink /d c:\Windows\System32\data d:\bin\gitea\data

Now it works, I can login to my old db.

@DocumentRoot commented on GitHub (Jan 30, 2017): Same on master (Gitea Version: 1.0.0+149-g8bc4319) (I'm sure I recreate service with new name and gitea-master-windows-4.0-amd64.exe target) I realized what happens, when I tried to clean install database running Gitea as a service... Manual `gitea web` uses `data/` directory to store db, but gitea service uses `c:\windows\system32\data` (even if relative to gitea.exe `data/gitea.db` exists) So I delete c:\Windows\System32\data and create symlink: `mklink /d c:\Windows\System32\data d:\bin\gitea\data` Now it works, I can login to my old db.
Author
Owner

@tboerger commented on GitHub (Jan 30, 2017):

So you have to set proper paths within the app.ini, not really a Gitea bug.

@tboerger commented on GitHub (Jan 30, 2017): So you have to set proper paths within the app.ini, not really a Gitea bug.
Author
Owner

@DocumentRoot commented on GitHub (Jan 30, 2017):

Yes it can be fixed by app.ini, but the bug is default settings PATH = data/gitea.db leads to various paths if Gitea runs as gitea.exe web or as a service. User should realize it somehow and fix it.

Also, is this correct that the user app stores anything in c:\Windows?
At major Windows upgrades, or at clean Windows install, when people make backup of c:\Users, it will lead to db loss.

@DocumentRoot commented on GitHub (Jan 30, 2017): Yes it can be fixed by app.ini, but the bug is default settings `PATH = data/gitea.db` leads to various paths if Gitea runs as `gitea.exe web` or as a service. User should realize it somehow and fix it. Also, is this correct that the user app stores anything in c:\Windows\? At major Windows upgrades, or at clean Windows install, when people make backup of c:\Users, it will lead to db loss.
Author
Owner

@tboerger commented on GitHub (Jan 30, 2017):

If the custom path isn't defined via environment variable it takes on Unix systems the path relative to the binary, for Windows it seems to be a different path. This is the current default behavior and it should be still the same behavior as Gogs.

@tboerger commented on GitHub (Jan 30, 2017): If the custom path isn't defined via environment variable it takes on Unix systems the path relative to the binary, for Windows it seems to be a different path. This is the current default behavior and it should be still the same behavior as Gogs.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#303