github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-09 04:25:18 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Unable to "adopt" orphaned packages like I'm able to adopt orphaned Repositories. #13610

New Issue
Open
opened 2025-11-02 10:48:08 -06:00 by GiteaMirror · 2 comments
GiteaMirror commented 2025-11-02 10:48:08 -06:00
Owner
Copy Link

Originally created by @CakePost on GitHub (Oct 17, 2024).

Description

A few days ago I encountered an issue with the postgres database I was using for our Gitea instance. I documented the events that caused the corruption of our database on serverfault in the hopes of being able to recover it, though that's looking unlikely.

I'm now facing the process of recovering our instance to the best of my ability. Using the "adopt repository" feature a lot of the stress is mitigated as I can just have users remake their accounts (of which there are only 30) and then relink their repositories. However, a few users have been using packages and I'd like to also be able to restore those as well.

Wiping the corrupted database (after a backup of course) and starting fresh, an execution of the gitea doctor shows this:

/$ gitea doctor check --all

[1] Garbage collect LFS
 - [W] Found 6975/6975 (23 GiB/23 GiB) orphaned LFS file(s)
OK

[2] Check paths and basic configuration
 - [I] Configuration File Path:    "/data/gitea/conf/app.ini"
 - [I] Repository Root Path:       "/data/git/repositories"
 - [I] Data Root Path:             "/data/gitea"
 - [I] Custom File Root Path:      "/data/gitea"
 - [I] Work directory:             "/data/gitea"
 - [I] Log Root Path:              "/data/gitea/log"
OK

[3] Check if there are orphaned archives in storage
 - [I] Found 0 (0 B) repo archive(s)
OK

[4] Check if there are orphaned attachments in storage
 - [I] Found 0 (0 B) attachment(s)
OK

[5] Check if there are orphaned avatars in storage
 - [W] Found 15/16 (1.8 MiB/1.8 MiB) orphaned avatar(s)
 - [I] Found 0 (0 B) repo avatar(s)
OK

[6] Check if there are orphaned lfs files in storage
 - [W] Found 6975/6975 (23 GiB/23 GiB) orphaned LFS file(s)
OK

[7] Check if there are orphaned package blobs in storage
 - [W] Found 81/81 (295 MiB/295 MiB) orphaned package blob(s)
OK

[8] Check if there are orphaned storage files
 - [I] Found 0 (0 B) attachment(s)
 - [W] Found 6975/6975 (23 GiB/23 GiB) orphaned LFS file(s)
 - [W] Found 15/16 (1.8 MiB/1.8 MiB) orphaned avatar(s)
 - [I] Found 0 (0 B) repo avatar(s)
 - [I] Found 0 (0 B) repo archive(s)
 - [W] Found 81/81 (295 MiB/295 MiB) orphaned package blob(s)
OK

[9] Check Database Version
 - [I] Expected database version: 280
OK

[10] Check consistency of database
 - [W] Found 2 Orphaned OAuth2Application without existing User
OK

[11] Check if user with wrong type exist
OK

[12] Check if OpenSSH authorized_keys file is up-to-date
OK

[13] Deleted all content related to orphaned repos
OK

[14] Check if SCRIPT_TYPE is available
 - [I] ScriptType bash is on the current PATH at /bin/bash
OK

[15] Check if hook files are up-to-date and executable
OK

[16] Recalculate Stars number for all user
 - [I] No check available for User Stars numbers (skipped)
OK

[17] Check old archives
 - [I] 0 old archives in repository need to be deleted
OK

[18] Check that all git repositories have receive.advertisePushOptions set to true
 - [I] Checked 1 repositories, 0 need updates.
OK

[19] Check for incorrectly dumped repo_units (See #16961)
 - [I] Found no broken repo_units
OK

[20] Check for incorrect can_create_org_repo for org owner teams
 - [I] Found no team with incorrect can_create_org_repo
OK

[21] Recalculate merge bases
 - [I] All 0 PRs in 1 repos have a correct mergebase
OK

[22] Synchronize repo HEADs
 - [I] All 1 repos have their HEADs in the correct state
OK

[23] Check git-daemon-export-ok files
 - [I] Checked 1 repositories, 0 need updates.
OK

[24] Check commit-graphs
 - [I] Checked 1 repositories, 1 without commit-graphs.
OK

[25] Check if users has an valid email address
 - [I] All users have a valid e-mail.
OK

[26] Check if users have a valid username
 - [I] All users have a valid username.
OK

All done (checks: 26).

Of course running gitea doctor check --all --fix just deletes anything that's orphaned. What I'd like to do is be able to re-associate all of the orphaned packages back with the accounts that made them.

I do not know if this is something that can be done through the interface somewhere I'm missing, or if it can be done through the command line. Before I start having people re-onboarded onto the server, I'd like to know what I can do to get their packages back onto their accounts.

Gitea Version

1.21.6

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

While the repository section in the site administration panel provides a really easy way to re-associate repos with their users (once recreating their accounts), the package code assets do not seem to have this option.

image
image

Git Version

2.30.2

Operating System

Debian GNU/Linux 11 (bullseye)

How are you running Gitea?

I am running gitea in a docker container using the following docker compose config.

version: "3.9"
services:
 gitea:
   image: gitea/gitea:latest
   restart: always
   hostname: ###.###.###.###
   environment:
     - USER=git
     - USER_UID=1000
     - USER_GID=998
     - GITEA__database__DB_TYPE=postgres
     - GITEA__database___HOST=giteadb:5432
     - GITEA__database__NAME=gitea
     - GITEA__database__USER=gitea
     - GITEA__database__PASSWD=###################
   networks:
     - gitea
   ports:
     - 3000:3000
     - 22:22
   volumes:
     - /mnt/###################/gitea/data:/data
     - /etc/timezone:/etc/timezone:ro
     - /etc/localtime:/etc/localtime:ro
   shm_size: 256m
   depends_on:
     - giteadb

 giteadb:
   image: postgres:14
   restart: always
   environment:
     - POSTGRES_USER=gitea
     - POSTGRES_PASSWORD=###################
     - POSTGRES_DB=gitea
   networks:
     - gitea
   volumes:
     - /srv/###################/gitea/db:/var/lib/postgresql/data

 runner:
   image: gitea/act_runner:latest
   restart: always
   depends_on:
     - gitea
   volumes:
     - /mnt/###################/gitea/data/act_runner:/data
     - /var/run/docker.sock:/var/run/docker.sock
   environment:
     - GITEA_INSTANCE_URL=https://git.###################.com
     # When using Docker Secrets, it's also possible to use
     # GITEA_RUNNER_REGISTRATION_TOKEN_FILE to pass the location.
     # The env var takes precedence.
     # Needed only for the first start.
     - GITEA_RUNNER_REGISTRATION_TOKEN=###################
networks:
 gitea:
   external: false

Database

PostgreSQL

Originally created by @CakePost on GitHub (Oct 17, 2024). ### Description A few days ago I encountered an issue with the postgres database I was using for our Gitea instance. I documented the events that caused the corruption of our database [on serverfault](https://serverfault.com/questions/1166604/what-are-some-strategies-for-recovery-of-a-postgres-database-that-had-two-postgr?noredirect=1#comment1527289_1166604) in the hopes of being able to recover it, though that's looking unlikely. I'm now facing the process of recovering our instance to the best of my ability. Using the "adopt repository" feature a lot of the stress is mitigated as I can just have users remake their accounts (of which there are only 30) and then relink their repositories. However, a few users have been using packages and I'd like to also be able to restore those as well. Wiping the corrupted database (after a backup of course) and starting fresh, an execution of the `gitea doctor` shows this: ``` /$ gitea doctor check --all [1] Garbage collect LFS - [W] Found 6975/6975 (23 GiB/23 GiB) orphaned LFS file(s) OK [2] Check paths and basic configuration - [I] Configuration File Path: "/data/gitea/conf/app.ini" - [I] Repository Root Path: "/data/git/repositories" - [I] Data Root Path: "/data/gitea" - [I] Custom File Root Path: "/data/gitea" - [I] Work directory: "/data/gitea" - [I] Log Root Path: "/data/gitea/log" OK [3] Check if there are orphaned archives in storage - [I] Found 0 (0 B) repo archive(s) OK [4] Check if there are orphaned attachments in storage - [I] Found 0 (0 B) attachment(s) OK [5] Check if there are orphaned avatars in storage - [W] Found 15/16 (1.8 MiB/1.8 MiB) orphaned avatar(s) - [I] Found 0 (0 B) repo avatar(s) OK [6] Check if there are orphaned lfs files in storage - [W] Found 6975/6975 (23 GiB/23 GiB) orphaned LFS file(s) OK [7] Check if there are orphaned package blobs in storage - [W] Found 81/81 (295 MiB/295 MiB) orphaned package blob(s) OK [8] Check if there are orphaned storage files - [I] Found 0 (0 B) attachment(s) - [W] Found 6975/6975 (23 GiB/23 GiB) orphaned LFS file(s) - [W] Found 15/16 (1.8 MiB/1.8 MiB) orphaned avatar(s) - [I] Found 0 (0 B) repo avatar(s) - [I] Found 0 (0 B) repo archive(s) - [W] Found 81/81 (295 MiB/295 MiB) orphaned package blob(s) OK [9] Check Database Version - [I] Expected database version: 280 OK [10] Check consistency of database - [W] Found 2 Orphaned OAuth2Application without existing User OK [11] Check if user with wrong type exist OK [12] Check if OpenSSH authorized_keys file is up-to-date OK [13] Deleted all content related to orphaned repos OK [14] Check if SCRIPT_TYPE is available - [I] ScriptType bash is on the current PATH at /bin/bash OK [15] Check if hook files are up-to-date and executable OK [16] Recalculate Stars number for all user - [I] No check available for User Stars numbers (skipped) OK [17] Check old archives - [I] 0 old archives in repository need to be deleted OK [18] Check that all git repositories have receive.advertisePushOptions set to true - [I] Checked 1 repositories, 0 need updates. OK [19] Check for incorrectly dumped repo_units (See #16961) - [I] Found no broken repo_units OK [20] Check for incorrect can_create_org_repo for org owner teams - [I] Found no team with incorrect can_create_org_repo OK [21] Recalculate merge bases - [I] All 0 PRs in 1 repos have a correct mergebase OK [22] Synchronize repo HEADs - [I] All 1 repos have their HEADs in the correct state OK [23] Check git-daemon-export-ok files - [I] Checked 1 repositories, 0 need updates. OK [24] Check commit-graphs - [I] Checked 1 repositories, 1 without commit-graphs. OK [25] Check if users has an valid email address - [I] All users have a valid e-mail. OK [26] Check if users have a valid username - [I] All users have a valid username. OK All done (checks: 26). ``` Of course running `gitea doctor check --all --fix` just deletes anything that's orphaned. What I'd like to do is be able to re-associate all of the orphaned packages back with the accounts that made them. I do not know if this is something that can be done through the interface somewhere I'm missing, or if it can be done through the command line. Before I start having people re-onboarded onto the server, I'd like to know what I can do to get their packages back onto their accounts. ### Gitea Version 1.21.6 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots While the repository section in the site administration panel provides a really easy way to re-associate repos with their users (once recreating their accounts), the package code assets do not seem to have this option. ![image](https://github.com/user-attachments/assets/2120cf90-35ac-446a-bc41-ccf5a6435bde) ![image](https://github.com/user-attachments/assets/75e6a896-f8f4-4367-8de4-05264ec7a5b7) ### Git Version 2.30.2 ### Operating System Debian GNU/Linux 11 (bullseye) ### How are you running Gitea? I am running gitea in a docker container using the following docker compose config. ``` version: "3.9" services: gitea: image: gitea/gitea:latest restart: always hostname: ###.###.###.### environment: - USER=git - USER_UID=1000 - USER_GID=998 - GITEA__database__DB_TYPE=postgres - GITEA__database___HOST=giteadb:5432 - GITEA__database__NAME=gitea - GITEA__database__USER=gitea - GITEA__database__PASSWD=################### networks: - gitea ports: - 3000:3000 - 22:22 volumes: - /mnt/###################/gitea/data:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro shm_size: 256m depends_on: - giteadb giteadb: image: postgres:14 restart: always environment: - POSTGRES_USER=gitea - POSTGRES_PASSWORD=################### - POSTGRES_DB=gitea networks: - gitea volumes: - /srv/###################/gitea/db:/var/lib/postgresql/data runner: image: gitea/act_runner:latest restart: always depends_on: - gitea volumes: - /mnt/###################/gitea/data/act_runner:/data - /var/run/docker.sock:/var/run/docker.sock environment: - GITEA_INSTANCE_URL=https://git.###################.com # When using Docker Secrets, it's also possible to use # GITEA_RUNNER_REGISTRATION_TOKEN_FILE to pass the location. # The env var takes precedence. # Needed only for the first start. - GITEA_RUNNER_REGISTRATION_TOKEN=################### networks: gitea: external: false ``` ### Database PostgreSQL
GiteaMirror added the type/proposalissue/not-a-bug labels 2025-11-02 10:48:08 -06:00
GiteaMirror commented 2025-11-02 10:48:09 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Oct 21, 2024):

This should be a proposal rather than a bug. And I don't know whether it's possible to recover packages from disk.

@lunny commented on GitHub (Oct 21, 2024): This should be a proposal rather than a bug. And I don't know whether it's possible to recover packages from disk.
GiteaMirror commented 2025-11-02 10:48:09 -06:00
Author
Owner
Copy Link

@CakePost commented on GitHub (Oct 21, 2024):

Thanks @lunny I wanted to make this a type/question as I wasn't sure if something like this was even implemented.

@CakePost commented on GitHub (Oct 21, 2024): Thanks @lunny I wanted to make this a `type/question` as I wasn't sure if something like this was even implemented.
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 issue/not-a-bug type/proposal
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#13610
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?