github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

gitea dump suddenly stops working: Failed to dump database: no such column: is_restricted #5706

New Issue
Closed
opened 2025-11-02 06:33:38 -06:00 by GiteaMirror · 6 comments
GiteaMirror commented 2025-11-02 06:33:38 -06:00
Owner
Copy Link

Originally created by @thomashoullier on GitHub (Jul 7, 2020).

  • Gitea version (or commit ref): v1.12.1
  • Git version: 2.17.1
  • Operating system: Ubuntu 18.04 LTS
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant

Description

I use the command gitea dump -c /etc/gitea/app.ini as the git user for creating backups. It has always worked fine. It has already worked with the currently installed version of gitea.

Apparently with no external issues, the command now gives:

git@vps:~$ gitea dump -c /etc/gitea/app.ini
2020/07/07 19:30:46 ...dules/setting/git.go:93:newGit() [I] Git Version: 2.17.1
2020/07/07 19:30:46 ...dules/setting/log.go:233:newLogService() [I] Gitea v1.12.1 built with GNU Make 4.1, go1.14.4 : bindata, sqlite, sqlite_unlock_notify
Failed to dump database: no such column: is_restricted

It does not stop right away. It seemingly goes through a lot of files when running with the -V option. A dump is produced but it is 22 bytes long (100MB usually).

https://github.com/go-gitea/gitea/issues/10207 seems related but I am running the correct binary (the versions from the GUI and from gitea --version match). Restarting the service or even the whole machine does nothing at all. The dump always fails the same way.

Originally created by @thomashoullier on GitHub (Jul 7, 2020). - Gitea version (or commit ref): v1.12.1 - Git version: 2.17.1 - Operating system: Ubuntu 18.04 LTS - 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 ## Description I use the command `gitea dump -c /etc/gitea/app.ini` as the `git` user for creating backups. It has always worked fine. It has already worked with the currently installed version of gitea. Apparently with no external issues, the command now gives: ``` git@vps:~$ gitea dump -c /etc/gitea/app.ini 2020/07/07 19:30:46 ...dules/setting/git.go:93:newGit() [I] Git Version: 2.17.1 2020/07/07 19:30:46 ...dules/setting/log.go:233:newLogService() [I] Gitea v1.12.1 built with GNU Make 4.1, go1.14.4 : bindata, sqlite, sqlite_unlock_notify Failed to dump database: no such column: is_restricted ``` It does not stop right away. It seemingly goes through a lot of files when running with the `-V` option. A dump is produced but it is 22 bytes long (100MB usually). https://github.com/go-gitea/gitea/issues/10207 seems related but I am running the correct binary (the versions from the GUI and from `gitea --version` match). Restarting the service or even the whole machine does nothing at all. The dump always fails the same way.
GiteaMirror commented 2025-11-02 06:33:39 -06:00
Author
Owner
Copy Link

@thomashoullier commented on GitHub (Jul 7, 2020):

I find in /var/lib/gitea/log/gitea.log:

2020/07/07 19:52:17 ...m.io/xorm/core/db.go:154:QueryContext() [I] [SQL] SELECT `id`, `lower_name`, `nam
e`, `full_name`, `email`, `keep_email_private`, `email_notifications_preference`, `passwd`, `passwd_hash
_algo`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website
`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_
repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `is_restricted`, `allow_git_hook`, `allo
w_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_av
atar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `repo_admin_change_team_access`, `diff_view_style`, `theme` FROM `user` [] - 2.134588ms
2020/07/07 19:52:17 cmd/dump.go:64:fatal() [F] Failed to dump database: no such column: is_restricted

Which is not much more information about the problem.

@thomashoullier commented on GitHub (Jul 7, 2020): I find in `/var/lib/gitea/log/gitea.log`: ``` 2020/07/07 19:52:17 ...m.io/xorm/core/db.go:154:QueryContext() [I] [SQL] SELECT `id`, `lower_name`, `nam e`, `full_name`, `email`, `keep_email_private`, `email_notifications_preference`, `passwd`, `passwd_hash _algo`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website `, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_ repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `is_restricted`, `allow_git_hook`, `allo w_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_av atar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `repo_admin_change_team_access`, `diff_view_style`, `theme` FROM `user` [] - 2.134588ms 2020/07/07 19:52:17 cmd/dump.go:64:fatal() [F] Failed to dump database: no such column: is_restricted ``` Which is not much more information about the problem.
GiteaMirror commented 2025-11-02 06:33:39 -06:00
Author
Owner
Copy Link

@thomashoullier commented on GitHub (Jul 7, 2020):

For context, I always update gitea by downloading the binary from the github releases. I've kept up to date with whatever the latest release was for some time now. Is my database too old? Why doesn't it have the is_restricted column?

@thomashoullier commented on GitHub (Jul 7, 2020): For context, I always update gitea by downloading the binary from the github releases. I've kept up to date with whatever the latest release was for some time now. Is my database too old? Why doesn't it have the `is_restricted` column?
GiteaMirror commented 2025-11-02 06:33:39 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jul 7, 2020):

Are you trying to run gitea dump before you've migrated the database to the latest version?

You should run gitea dump with the old version of gitea, not the new.

@zeripath commented on GitHub (Jul 7, 2020): Are you trying to run `gitea dump` before you've migrated the database to the latest version? You should run `gitea dump` with the old version of gitea, not the new.
GiteaMirror commented 2025-11-02 06:33:39 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jul 7, 2020):

Or let gitea do the migration first

@zeripath commented on GitHub (Jul 7, 2020): Or let gitea do the migration first
GiteaMirror commented 2025-11-02 06:33:39 -06:00
Author
Owner
Copy Link

@thomashoullier commented on GitHub (Jul 7, 2020):

Ok I did try to dump without migrating first. It has worked by chance for a year and a half and every version of gitea. I don't understand whether the migration happened automatically? (I just stopped gitea, switched the binaries and restarted everytime)

Migrating with the newest binary, and then dumping fixes the problem:

As user git:

gitea migrate -c /etc/gitea/app.ini
gitea dump -c /etc/gitea/app.ini

I'll just add the migration command to my (hacky) update script. Thanks for the answer!

@thomashoullier commented on GitHub (Jul 7, 2020): Ok I did try to `dump` without migrating first. It has worked by chance for a year and a half and every version of gitea. I don't understand whether the migration happened automatically? (I just stopped gitea, switched the binaries and restarted everytime) Migrating with the newest binary, and then dumping fixes the problem: As user `git`: ``` gitea migrate -c /etc/gitea/app.ini gitea dump -c /etc/gitea/app.ini ``` I'll just add the migration command to my (hacky) update script. Thanks for the answer!
GiteaMirror commented 2025-11-02 06:33:40 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jul 8, 2020):

you probably want to dump before updating the version of gitea - that way if there is a problem with migration you still have the previous DB to return to.

@zeripath commented on GitHub (Jul 8, 2020): you probably want to dump before updating the version of gitea - that way if there is a problem with migration you still have the previous DB to return to.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#5706
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?