Originally created by @RikudouGoku on GitHub (Jun 23, 2026).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/331
Originally assigned to: @arunavo4 on GitHub.
<img width="1889" height="885" alt="Image" src="https://github.com/user-attachments/assets/bd191bcc-de65-4883-a2b7-e25c39ddc348" />
Settings:
<img width="1604" height="556" alt="Image" src="https://github.com/user-attachments/assets/9b84fe18-75f1-41f1-b73f-669485dc68a4" />
<img width="1604" height="734" alt="Image" src="https://github.com/user-attachments/assets/07779a23-e8fd-404a-b703-ce3ac4b3fc72" />
Activity log:
<img width="1604" height="734" alt="Image" src="https://github.com/user-attachments/assets/8e68d642-c34c-4cd4-ab9e-c611d407b3ac" />
But in my forgejo instance:
<img width="1391" height="820" alt="Image" src="https://github.com/user-attachments/assets/0f0dca57-f24d-4529-8fc3-c572b6a3129f" />
<img width="1391" height="820" alt="Image" src="https://github.com/user-attachments/assets/4fe63199-8caa-4e8a-8da1-1167d3c78cc4" />
When i download that latest tag it is only 4.6mb, it should be around 70mb in total though as can be seen here.
<img width="1257" height="860" alt="Image" src="https://github.com/user-attachments/assets/912af878-1c76-4077-9a24-8a60f142b79d" />
https://github.com/shauninman/MinUI/releases/tag/v20251127-1
gitea-mirror part in my compose:
https://hastebin.com/share/utujuvosiy.ruby
No error in the logs either.
GiteaMirror
added the bug label 2026-07-16 01:41:44 -05:00
<!-- gh-comment-id:4781925641 -->
@RikudouGoku commented on GitHub (Jun 23, 2026):
> [@RikudouGoku](https://github.com/RikudouGoku) try the new version and thanks for reporting this.
Still the same
EDIT: I tried another repo I have not mirrored and it did not work either.
https://github.com/TheGammaSqueeze/GammaOSCore
<img width="1363" height="443" alt="Image" src="https://github.com/user-attachments/assets/507f4662-d92c-4a83-a0d5-eb596c48a097" />
Is just 45kb.
Here is a small part of it that I think is relevant:
2026-06-23T17:49:58.235054304Z [Releases] Found 5 releases (limited to latest 15) to mirror for TheGammaSqueeze/GammaOSCore
2026-06-23T17:49:58.235081652Z [Releases] Processing 5 releases for TheGammaSqueeze/GammaOSCore
2026-06-23T17:49:58.235096251Z [Releases] 1. beta3_a133p - published 2025-02-17T13:42:40.000Z (tag created 2025-02-08T04:23:11.000Z)
2026-06-23T17:49:58.235102343Z [Releases] 2. beta3 - published 2025-02-07T18:12:19.000Z (tag created 2025-01-14T00:32:36.000Z)
2026-06-23T17:49:58.235107996Z [Releases] 3. beta2.5_miyooflip - published 2025-01-11T19:00:40.000Z (tag created 2024-12-12T23:18:44.000Z)
2026-06-23T17:49:58.235139350Z [Releases] 4. beta2 - published 2024-12-12T22:22:41.000Z (tag created 2024-12-12T21:32:41.000Z)
2026-06-23T17:49:58.235148129Z [Releases] 5. beta1 - published 2024-09-15T23:00:05.000Z (tag created 2024-09-15T20:59:47.000Z)
2026-06-23T17:49:58.248877423Z [Releases] Including changelog for beta3_a133p (5300 characters + GitHub date header)
2026-06-23T17:49:58.259997961Z [Releases] Failed to mirror release beta3_a133p: HTTP 404: The target couldn't be found.
2026-06-23T17:49:58.270783671Z [Releases] Including changelog for beta3 (4507 characters + GitHub date header)
2026-06-23T17:49:58.282605892Z [Releases] Failed to mirror release beta3: HTTP 404: The target couldn't be found.
2026-06-23T17:49:58.296966441Z [Releases] Including changelog for beta2.5_miyooflip (4637 characters + GitHub date header)
2026-06-23T17:49:58.315478639Z [Releases] Failed to mirror release beta2.5_miyooflip: HTTP 404: The target couldn't be found.
2026-06-23T17:49:58.338507865Z [Releases] Including changelog for beta2 (4880 characters + GitHub date header)
2026-06-23T17:49:58.362905311Z [Releases] Failed to mirror release beta2: HTTP 404: The target couldn't be found.
2026-06-23T17:49:58.387186793Z [Releases] Including changelog for beta1 (5393 characters + GitHub date header)
2026-06-23T17:49:58.410773009Z [Releases] Failed to mirror release beta1: HTTP 404: The target couldn't be found.
2026-06-23T17:49:58.410787025Z ✅ Mirrored/Updated 0 releases to Gitea (0 already up-to-date); assets uploaded: 0, failed: 0
<!-- gh-comment-id:4782119807 -->
@RikudouGoku commented on GitHub (Jun 23, 2026):
> [@RikudouGoku](https://github.com/RikudouGoku) try the new version and thanks for reporting this.
Here are the logs (1k rows).
https://send.vis.ee/download/d07b35befc29e359/#FqTBLT2S7xSb7VxHlahzoA
(expires after 1 download or 1 day.)
Here is a small part of it that I think is relevant:
```
2026-06-23T17:49:58.235054304Z [Releases] Found 5 releases (limited to latest 15) to mirror for TheGammaSqueeze/GammaOSCore
2026-06-23T17:49:58.235081652Z [Releases] Processing 5 releases for TheGammaSqueeze/GammaOSCore
2026-06-23T17:49:58.235096251Z [Releases] 1. beta3_a133p - published 2025-02-17T13:42:40.000Z (tag created 2025-02-08T04:23:11.000Z)
2026-06-23T17:49:58.235102343Z [Releases] 2. beta3 - published 2025-02-07T18:12:19.000Z (tag created 2025-01-14T00:32:36.000Z)
2026-06-23T17:49:58.235107996Z [Releases] 3. beta2.5_miyooflip - published 2025-01-11T19:00:40.000Z (tag created 2024-12-12T23:18:44.000Z)
2026-06-23T17:49:58.235139350Z [Releases] 4. beta2 - published 2024-12-12T22:22:41.000Z (tag created 2024-12-12T21:32:41.000Z)
2026-06-23T17:49:58.235148129Z [Releases] 5. beta1 - published 2024-09-15T23:00:05.000Z (tag created 2024-09-15T20:59:47.000Z)
2026-06-23T17:49:58.248877423Z [Releases] Including changelog for beta3_a133p (5300 characters + GitHub date header)
2026-06-23T17:49:58.259997961Z [Releases] Failed to mirror release beta3_a133p: HTTP 404: The target couldn't be found.
2026-06-23T17:49:58.270783671Z [Releases] Including changelog for beta3 (4507 characters + GitHub date header)
2026-06-23T17:49:58.282605892Z [Releases] Failed to mirror release beta3: HTTP 404: The target couldn't be found.
2026-06-23T17:49:58.296966441Z [Releases] Including changelog for beta2.5_miyooflip (4637 characters + GitHub date header)
2026-06-23T17:49:58.315478639Z [Releases] Failed to mirror release beta2.5_miyooflip: HTTP 404: The target couldn't be found.
2026-06-23T17:49:58.338507865Z [Releases] Including changelog for beta2 (4880 characters + GitHub date header)
2026-06-23T17:49:58.362905311Z [Releases] Failed to mirror release beta2: HTTP 404: The target couldn't be found.
2026-06-23T17:49:58.387186793Z [Releases] Including changelog for beta1 (5393 characters + GitHub date header)
2026-06-23T17:49:58.410773009Z [Releases] Failed to mirror release beta1: HTTP 404: The target couldn't be found.
2026-06-23T17:49:58.410787025Z ✅ Mirrored/Updated 0 releases to Gitea (0 already up-to-date); assets uploaded: 0, failed: 0
```
@RikudouGoku it works on my end can you tell me which forgejo version are you using? specifically? also if possible can you do a fresh install of both gitea-mirror and forgejo and try again with one repo? I feel like some tags during creation might have not been created and that could have caused this.
Below are screenshots from my testing
<!-- gh-comment-id:4785536857 -->
@arunavo4 commented on GitHub (Jun 24, 2026):
@RikudouGoku it works on my end can you tell me which forgejo version are you using? specifically? also if possible can you do a fresh install of both gitea-mirror and forgejo and try again with one repo? I feel like some tags during creation might have not been created and that could have caused this.
Below are screenshots from my testing
<img width="1200" height="762" alt="Image" src="https://github.com/user-attachments/assets/79369860-5bfb-4ec0-8dcb-182f537abbcf" />
<img width="1200" height="1447" alt="Image" src="https://github.com/user-attachments/assets/f0bb4d8d-3d17-4ce9-896e-e259917da4ce" />
@RikudouGoku it works on my end can you tell me which forgejo version are you using? specifically? also if possible can you do a fresh install of both gitea-mirror and forgejo and try again with one repo? I feel like some tags during creation might have not been created and that could have caused this.
<!-- gh-comment-id:4787554585 -->
@RikudouGoku commented on GitHub (Jun 24, 2026):
> [@RikudouGoku](https://github.com/RikudouGoku) it works on my end can you tell me which forgejo version are you using? specifically? also if possible can you do a fresh install of both gitea-mirror and forgejo and try again with one repo? I feel like some tags during creation might have not been created and that could have caused this.
>
> Below are screenshots from my testing
>
> <img alt="Image" width="1200" height="762" src="https://private-user-images.githubusercontent.com/28377631/612215664-79369860-5bfb-4ec0-8dcb-182f537abbcf.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODIyOTE1MDQsIm5iZiI6MTc4MjI5MTIwNCwicGF0aCI6Ii8yODM3NzYzMS82MTIyMTU2NjQtNzkzNjk4NjAtNWJmYi00ZWMwLThkY2ItMTgyZjUzN2FiYmNmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA2MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNjI0VDA4NTMyNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTI3ZTJiNTJhZDdlOTQzOTIwZTBkZDBmMmJiMGU1N2Q3NmU0MmZjNDM0NzM2MWNmMjE0YmQzY2IyNjYwNTY0YmMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.WbxfOte_m5w7eBkAX_2HjJGTXz0N8rZN_DM6S8SMMMU"> <img alt="Image" width="1200" height="1447" src="https://private-user-images.githubusercontent.com/28377631/612215665-f0bb4d8d-3d17-4ce9-896e-e259917da4ce.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODIyOTE1MDQsIm5iZiI6MTc4MjI5MTIwNCwicGF0aCI6Ii8yODM3NzYzMS82MTIyMTU2NjUtZjBiYjRkOGQtM2QxNy00Y2U5LTg5NmUtZTI1OTkxN2RhNGNlLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA2MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNjI0VDA4NTMyNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWMxOGFhMTc2MTFkMTVjNjI5NGM0ZmQxMjNiZjkyNDA1ZTk5YTA4ZjhkZWFhMmIwNWE1M2JlOGQ1MTQzNzEyNWMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.WpwfMcouR5RKIGSlNlbnfJkVE8mDjkJQny3kLgJW_LA">
Here is my entire compose.
https://hastebin.com/share/zozitizaxu.yaml
Forgejo 15 rootless
Thanks for the version + full compose @RikudouGoku — that helped a lot.
I reproduced your exact Forgejo stack on a test box — forgejo:15-rootless with read_only: true, cap_drop: ALL, user 99:100, tmpfs /tmp — and gitea-mirror creates the releases with their assets without any problem (HTTP 201). I also tested Gitea 1.20–1.26 and Forgejo 1.21–15: on a healthy repo the release create always succeeds. So the Forgejo version and the read-only/rootless hardening are not the cause.
What 404 "The target couldn't be found" actually means: it's Gitea's generic not-found, and on the release-create call it fires in exactly one situation — when the release's git tag isn't present in the repo at the moment of creation. gitea-mirror was sending target=main so Gitea would try to create the tag, and if the tag/ref isn't there yet it 404s. This lines up with your symptom (every release failing while issues/PRs succeed, since those don't touch git refs) and with the idea that the git mirror hadn't finished syncing the tags when the release step ran.
Fix incoming (https://github.com/RayLabsHQ/gitea-mirror/pull/333): gitea-mirror will now only create a release when its git tag already exists in Gitea — if it's not synced yet it skips and retries on the next sync — and it no longer sends target at all. That removes the failure mode entirely.
To confirm the underlying cause on your side, could you grab your Forgejo container logs (not gitea-mirror's) during a sync that fails? gitea-mirror only sees the generic 404, but Forgejo logs the real error behind it:
That'll show whether the tag was missing / a git error at that moment. A fresh install with a single repo (as suggested) plus those logs would nail it. Thanks again for the detailed reports! 🙏
<!-- gh-comment-id:4788564954 -->
@arunavo4 commented on GitHub (Jun 24, 2026):
Thanks for the version + full compose @RikudouGoku — that helped a lot.
I reproduced your **exact** Forgejo stack on a test box — `forgejo:15-rootless` with `read_only: true`, `cap_drop: ALL`, `user 99:100`, tmpfs `/tmp` — and gitea-mirror creates the releases **with their assets** without any problem (HTTP 201). I also tested Gitea 1.20–1.26 and Forgejo 1.21–15: on a healthy repo the release create always succeeds. So the Forgejo version and the read-only/rootless hardening are not the cause.
What `404 "The target couldn't be found"` actually means: it's Gitea's **generic** not-found, and on the release-create call it fires in exactly one situation — when the release's **git tag isn't present in the repo at the moment of creation**. gitea-mirror was sending `target=main` so Gitea would try to *create* the tag, and if the tag/ref isn't there yet it 404s. This lines up with your symptom (every release failing while issues/PRs succeed, since those don't touch git refs) and with the idea that the git mirror hadn't finished syncing the tags when the release step ran.
**Fix incoming** (https://github.com/RayLabsHQ/gitea-mirror/pull/333): gitea-mirror will now only create a release when its git tag already exists in Gitea — if it's not synced yet it skips and retries on the next sync — and it no longer sends `target` at all. That removes the failure mode entirely.
To confirm the underlying cause on your side, could you grab your **Forgejo** container logs (not gitea-mirror's) during a sync that fails? gitea-mirror only sees the generic 404, but Forgejo logs the real error behind it:
```
docker logs forgejo --since 10m 2>&1 | grep -iE "release|tag|target|error"
```
That'll show whether the tag was missing / a git error at that moment. A fresh install with a single repo (as suggested) plus those logs would nail it. Thanks again for the detailed reports! 🙏
Thanks for the version + full compose @RikudouGoku — that helped a lot.
I reproduced your exact Forgejo stack on a test box — forgejo:15-rootless with read_only: true, cap_drop: ALL, user 99:100, tmpfs /tmp — and gitea-mirror creates the releases with their assets without any problem (HTTP 201). I also tested Gitea 1.20–1.26 and Forgejo 1.21–15: on a healthy repo the release create always succeeds. So the Forgejo version and the read-only/rootless hardening are not the cause.
What 404 "The target couldn't be found" actually means: it's Gitea's generic not-found, and on the release-create call it fires in exactly one situation — when the release's git tag isn't present in the repo at the moment of creation. gitea-mirror was sending target=main so Gitea would try to create the tag, and if the tag/ref isn't there yet it 404s. This lines up with your symptom (every release failing while issues/PRs succeed, since those don't touch git refs) and with the idea that the git mirror hadn't finished syncing the tags when the release step ran.
Fix incoming (#333): gitea-mirror will now only create a release when its git tag already exists in Gitea — if it's not synced yet it skips and retries on the next sync — and it no longer sends target at all. That removes the failure mode entirely.
To confirm the underlying cause on your side, could you grab your Forgejo container logs (not gitea-mirror's) during a sync that fails? gitea-mirror only sees the generic 404, but Forgejo logs the real error behind it:
That'll show whether the tag was missing / a git error at that moment. A fresh install with a single repo (as suggested) plus those logs would nail it. Thanks again for the detailed reports! 🙏
ok so to dumb it down since i understood nothing, you think it isnt my fault and you will have a fix incoming?
<!-- gh-comment-id:4790228231 -->
@RikudouGoku commented on GitHub (Jun 24, 2026):
e
> Thanks for the version + full compose [@RikudouGoku](https://github.com/RikudouGoku) — that helped a lot.
>
> I reproduced your **exact** Forgejo stack on a test box — `forgejo:15-rootless` with `read_only: true`, `cap_drop: ALL`, `user 99:100`, tmpfs `/tmp` — and gitea-mirror creates the releases **with their assets** without any problem (HTTP 201). I also tested Gitea 1.20–1.26 and Forgejo 1.21–15: on a healthy repo the release create always succeeds. So the Forgejo version and the read-only/rootless hardening are not the cause.
>
> What `404 "The target couldn't be found"` actually means: it's Gitea's **generic** not-found, and on the release-create call it fires in exactly one situation — when the release's **git tag isn't present in the repo at the moment of creation**. gitea-mirror was sending `target=main` so Gitea would try to _create_ the tag, and if the tag/ref isn't there yet it 404s. This lines up with your symptom (every release failing while issues/PRs succeed, since those don't touch git refs) and with the idea that the git mirror hadn't finished syncing the tags when the release step ran.
>
> **Fix incoming** ([#333](https://github.com/RayLabsHQ/gitea-mirror/pull/333)): gitea-mirror will now only create a release when its git tag already exists in Gitea — if it's not synced yet it skips and retries on the next sync — and it no longer sends `target` at all. That removes the failure mode entirely.
>
> To confirm the underlying cause on your side, could you grab your **Forgejo** container logs (not gitea-mirror's) during a sync that fails? gitea-mirror only sees the generic 404, but Forgejo logs the real error behind it:
>
> ```
> docker logs forgejo --since 10m 2>&1 | grep -iE "release|tag|target|error"
> ```
>
> That'll show whether the tag was missing / a git error at that moment. A fresh install with a single repo (as suggested) plus those logs would nail it. Thanks again for the detailed reports! 🙏
ok so to dumb it down since i understood nothing, you think it isnt my fault and you will have a fix incoming?
Here are the logs btw of my current container.
https://send.vis.ee/download/6aea6d1196db9cbf/#dKYgj75U6ollqP4aqOOYww
(expires after 1 day or 1 download)
@RikudouGoku sorry for confusing, its not your fault, just try the latest v3.20.2
<!-- gh-comment-id:4791009505 -->
@arunavo4 commented on GitHub (Jun 24, 2026):
@RikudouGoku sorry for confusing, its not your fault, just try the latest `v3.20.2`
<!-- gh-comment-id:4791268704 -->
@RikudouGoku commented on GitHub (Jun 24, 2026):
> [@RikudouGoku](https://github.com/RikudouGoku) sorry for confusing, its not your fault, just try the latest `v3.20.2`
Logs:
https://send.vis.ee/download/d137913f6242d79d/#GaeOcnG74iSztbf-U665WQ
Screenshot.
<img width="1873" height="897" alt="Image" src="https://github.com/user-attachments/assets/d59b97d1-e89d-46f7-8d05-fa85e9613092" />
<img width="1873" height="897" alt="Image" src="https://github.com/user-attachments/assets/dc53ea25-cd14-4f42-8ef2-effa1379262e" />
that zip is only 36,3MB, should it not be at least 121MB due to the komga-1.24.4.jar file?
https://github.com/gotson/komga/releases/tag/1.24.4
@RikudouGoku I tried to mirror and sync komga repo releases and I got the 121MB jar file you are trying to download the zip and tar.gz which is just the source code. as you can see on the releases page there is the jar file showing up.
and regarding the two thats failed try to retry them and cehck the logs
<!-- gh-comment-id:4795287520 -->
@arunavo4 commented on GitHub (Jun 25, 2026):
@RikudouGoku I tried to mirror and sync komga repo releases and I got the 121MB jar file you are trying to download the zip and tar.gz which is just the source code. as you can see on the releases page there is the jar file showing up.
<img width="1200" height="744" alt="Image" src="https://github.com/user-attachments/assets/e384b74c-f225-4430-8193-a6c380b12fa2" />
<img width="1200" height="2158" alt="Image" src="https://github.com/user-attachments/assets/6dfc5b44-57c4-4f22-ad54-21d78f898470" />
and regarding the two thats failed try to retry them and cehck the logs
@RikudouGoku I think I know why its failing on your side you have the "Releases" disabled as the tab is not shown on your screenshot can you turn it on?
<!-- gh-comment-id:4795336112 -->
@arunavo4 commented on GitHub (Jun 25, 2026):
@RikudouGoku I think I know why its failing on your side you have the "Releases" disabled as the tab is not shown on your screenshot can you turn it on?
<img width="1200" height="744" alt="Image" src="https://github.com/user-attachments/assets/068a6ef7-a9f6-4e36-a989-926a2584af47" />
@RikudouGoku I think I know why its failing on your side you have the "Releases" disabled as the tab is not shown on your screenshot can you turn it on?
I enabled this, but nothing shows up.
However this is the repo that also gives me errors.
I tried enabling the releases in the settings page for the others that does not have errors
The ones that errors out is "archived" in forgejo.
<!-- gh-comment-id:4800908697 -->
@RikudouGoku commented on GitHub (Jun 25, 2026):
> [@RikudouGoku](https://github.com/RikudouGoku) I think I know why its failing on your side you have the "Releases" disabled as the tab is not shown on your screenshot can you turn it on?
>
> <img alt="Image" width="1200" height="744" src="https://private-user-images.githubusercontent.com/28377631/612813770-068a6ef7-a9f6-4e36-a989-926a2584af47.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODI0MDAyMTQsIm5iZiI6MTc4MjM5OTkxNCwicGF0aCI6Ii8yODM3NzYzMS82MTI4MTM3NzAtMDY4YTZlZjctYTlmNi00ZTM2LWE5ODktOTI2YTI1ODRhZjQ3LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA2MjUlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNjI1VDE1MDUxNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTY2YWQyNDMyZTM4MTkzMzYwNDAwMTJmNzlkOWY4M2IyYTAyN2UzMDIyZjBkNzI5OTE3NWY0ZTJiNmMwOWJhMDcmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.fBlcFPUbgHJVcOvur9s3UzbvMZqZMxc-UhANBgT85uI">
I enabled this, but nothing shows up.
<img width="1423" height="435" alt="Image" src="https://github.com/user-attachments/assets/0b2881be-9141-4e3a-b3cb-76f3e758f867" />
However this is the repo that also gives me errors.
<img width="1615" height="619" alt="Image" src="https://github.com/user-attachments/assets/83e9c5ab-4e1a-435f-b65c-b98db80f5202" />
I tried enabling the releases in the settings page for the others that does not have errors
<img width="1615" height="811" alt="Image" src="https://github.com/user-attachments/assets/a5d4dbf9-5962-41d8-990d-76acd0b4acb3" />
And it does work here at least.
The logs for the ones that errors:
gitea-mirror log:
https://hastebin.com/share/ubidaforiz.typescript
forgejo log:
https://hastebin.com/share/rajafiwele.bash
The ones that errors out is "archived" in forgejo.
<img width="1615" height="811" alt="Image" src="https://github.com/user-attachments/assets/81b81536-7629-4785-b8a8-e9578ffb5385" />
<img width="1615" height="811" alt="Image" src="https://github.com/user-attachments/assets/b1be8e02-2db1-48a7-9bc2-c31d87f66506" />
<img width="1615" height="811" alt="Image" src="https://github.com/user-attachments/assets/c0905c79-0469-4425-abd2-3618ded2787c" />
The v3.20.2 release/asset fix works, that's why MinUI, Media-Server and Server sync fine.
The 3 that still fail (komga, beszel, GammaOSCore) show up in Forgejo as archived-komga, archived-beszel, archived-GammaOSCore. gitea-mirror auto-archived them by renaming, and the rename breaks the sync: Forgejo redirects the old name and the request ends in HTTP 405, so it never reaches the releases step. Not an asset bug this time.
Fix it now: in Forgejo rename them back (archived-komga → komga, etc.) then hit Sync, or delete the archived-* repos and re-mirror. Releases and assets will backfill.
One question: did you unstar those three on GitHub at some point? If yes, that's why they got archived; if no, it's a false-positive I'll fix.
Either way I'll fix gitea-mirror so archived/renamed repos don't get stuck in this 405 loop. Thanks for the great screenshots. 🙏
<!-- gh-comment-id:4851068357 -->
@arunavo4 commented on GitHub (Jul 1, 2026):
Quick update @RikudouGoku:
The v3.20.2 release/asset fix works, that's why MinUI, Media-Server and Server sync fine.
The 3 that still fail (komga, beszel, GammaOSCore) show up in Forgejo as `archived-komga`, `archived-beszel`, `archived-GammaOSCore`. gitea-mirror auto-archived them by renaming, and the rename breaks the sync: Forgejo redirects the old name and the request ends in HTTP 405, so it never reaches the releases step. Not an asset bug this time.
Fix it now: in Forgejo rename them back (`archived-komga` → `komga`, etc.) then hit Sync, or delete the `archived-*` repos and re-mirror. Releases and assets will backfill.
One question: did you unstar those three on GitHub at some point? If yes, that's why they got archived; if no, it's a false-positive I'll fix.
Either way I'll fix gitea-mirror so archived/renamed repos don't get stuck in this 405 loop. Thanks for the great screenshots. 🙏
The v3.20.2 release/asset fix works, that's why MinUI, Media-Server and Server sync fine.
The 3 that still fail (komga, beszel, GammaOSCore) show up in Forgejo as archived-komga, archived-beszel, archived-GammaOSCore. gitea-mirror auto-archived them by renaming, and the rename breaks the sync: Forgejo redirects the old name and the request ends in HTTP 405, so it never reaches the releases step. Not an asset bug this time.
Fix it now: in Forgejo rename them back (archived-komga → komga, etc.) then hit Sync, or delete the archived-* repos and re-mirror. Releases and assets will backfill.
One question: did you unstar those three on GitHub at some point? If yes, that's why they got archived; if no, it's a false-positive I'll fix.
Either way I'll fix gitea-mirror so archived/renamed repos don't get stuck in this 405 loop. Thanks for the great screenshots. 🙏
I will check it when I'm back from work.
But I am pretty damn sure I did not star/unstar anything when I tested it though. For example both komga and minui do not have stars now. All I did was go to the github page and copy the link and nothing else, I rarely star repos.
<!-- gh-comment-id:4852282247 -->
@RikudouGoku commented on GitHub (Jul 1, 2026):
> Quick update [@RikudouGoku](https://github.com/RikudouGoku):
>
> The v3.20.2 release/asset fix works, that's why MinUI, Media-Server and Server sync fine.
>
> The 3 that still fail (komga, beszel, GammaOSCore) show up in Forgejo as `archived-komga`, `archived-beszel`, `archived-GammaOSCore`. gitea-mirror auto-archived them by renaming, and the rename breaks the sync: Forgejo redirects the old name and the request ends in HTTP 405, so it never reaches the releases step. Not an asset bug this time.
>
> Fix it now: in Forgejo rename them back (`archived-komga` → `komga`, etc.) then hit Sync, or delete the `archived-*` repos and re-mirror. Releases and assets will backfill.
>
> One question: did you unstar those three on GitHub at some point? If yes, that's why they got archived; if no, it's a false-positive I'll fix.
>
> Either way I'll fix gitea-mirror so archived/renamed repos don't get stuck in this 405 loop. Thanks for the great screenshots. 🙏
I will check it when I'm back from work.
But I am pretty damn sure I did not star/unstar anything when I tested it though. For example both komga and minui do not have stars now. All I did was go to the github page and copy the link and nothing else, I rarely star repos.
@RikudouGoku Can you try once more on a fresh install of gitea and gitea-mirror?
<!-- gh-comment-id:4852296685 -->
@arunavo4 commented on GitHub (Jul 1, 2026):
@RikudouGoku Can you try once more on a fresh install of gitea and gitea-mirror?
@RikudouGoku Can you try once more on a fresh install of gitea and gitea-mirror?
I don't use gitea. I will try to spin up another container with the same compose pointing to a new folder when I'm home.
<!-- gh-comment-id:4852353662 -->
@RikudouGoku commented on GitHub (Jul 1, 2026):
> [@RikudouGoku](https://github.com/RikudouGoku) Can you try once more on a fresh install of gitea and gitea-mirror?
I don't use gitea. I will try to spin up another container with the same compose pointing to a new folder when I'm home.
@RikudouGoku Can you try once more on a fresh install of gitea and gitea-mirror?
I don't use gitea. I will try to spin up another container with the same compose pointing to a new folder when I'm home.
right sorry Forgejo
<!-- gh-comment-id:4852388584 -->
@arunavo4 commented on GitHub (Jul 1, 2026):
> > [@RikudouGoku](https://github.com/RikudouGoku) Can you try once more on a fresh install of gitea and gitea-mirror?
>
> I don't use gitea. I will try to spin up another container with the same compose pointing to a new folder when I'm home.
right sorry Forgejo
@RikudouGoku Can you try once more on a fresh install of gitea and gitea-mirror?
I don't use gitea. I will try to spin up another container with the same compose pointing to a new folder when I'm home.
right sorry Forgejo
Ok so spun up a completely new forgejo (and its db) and gitea-mirror containers. I do not get archived with komga/minui but nothing is downloaded via assets. The gitea-mirror configuration settings are identical as the pictures posted previously in this thread.
<!-- gh-comment-id:4855889917 -->
@RikudouGoku commented on GitHub (Jul 1, 2026):
> > > [@RikudouGoku](https://github.com/RikudouGoku) Can you try once more on a fresh install of gitea and gitea-mirror?
> >
> >
> > I don't use gitea. I will try to spin up another container with the same compose pointing to a new folder when I'm home.
>
> right sorry Forgejo
Ok so spun up a completely new forgejo (and its db) and gitea-mirror containers. I do not get archived with komga/minui but nothing is downloaded via assets. The gitea-mirror configuration settings are identical as the pictures posted previously in this thread.
<img width="1897" height="878" alt="Image" src="https://github.com/user-attachments/assets/d7e38184-5021-4a71-abf8-109f752a44f6" />
Logs:
https://send.vis.ee/download/cf52e51774c08dae/#NwnUNLbYqRjpWD2uVXAdvg
<img width="1351" height="811" alt="Image" src="https://github.com/user-attachments/assets/07de8594-17d6-4ebb-8ac7-428af5c69b29" />
<img width="1351" height="811" alt="Image" src="https://github.com/user-attachments/assets/2749388a-4b94-40ab-b222-b11afcbb823e" />
<img width="1677" height="885" alt="Image" src="https://github.com/user-attachments/assets/198a0446-8636-4c69-90e7-e7ffc57819f6" />
(same with komga)
Do i need to star them first?
The v3.20.2 release/asset fix works, that's why MinUI, Media-Server and Server sync fine.
The 3 that still fail (komga, beszel, GammaOSCore) show up in Forgejo as archived-komga, archived-beszel, archived-GammaOSCore. gitea-mirror auto-archived them by renaming, and the rename breaks the sync: Forgejo redirects the old name and the request ends in HTTP 405, so it never reaches the releases step. Not an asset bug this time.
Fix it now: in Forgejo rename them back (archived-komga → komga, etc.) then hit Sync, or delete the archived-* repos and re-mirror. Releases and assets will backfill.
One question: did you unstar those three on GitHub at some point? If yes, that's why they got archived; if no, it's a false-positive I'll fix.
Either way I'll fix gitea-mirror so archived/renamed repos don't get stuck in this 405 loop. Thanks for the great screenshots. 🙏
Ok soo im back to the old container, and renaming the archived- ones to the proper name and all 3 that had errors works now! With assets/release and everything!
And I tried to add some new repos into it but im not fully sure if it works or not as i seem to have hit the rate limit.
And they dont seem to have the same releases page as komga, do you have an example of another repo that i can test that does releases like komga?
And do i have to manually tick the enable repository releases in the settings inside the forgejo repos for every repo?
edit:
they got archived after a while.
But does at least work when i renamed it back from archived- to the actual name and sync (just one) again.
<!-- gh-comment-id:4857235961 -->
@RikudouGoku commented on GitHub (Jul 1, 2026):
> Quick update [@RikudouGoku](https://github.com/RikudouGoku):
>
> The v3.20.2 release/asset fix works, that's why MinUI, Media-Server and Server sync fine.
>
> The 3 that still fail (komga, beszel, GammaOSCore) show up in Forgejo as `archived-komga`, `archived-beszel`, `archived-GammaOSCore`. gitea-mirror auto-archived them by renaming, and the rename breaks the sync: Forgejo redirects the old name and the request ends in HTTP 405, so it never reaches the releases step. Not an asset bug this time.
>
> Fix it now: in Forgejo rename them back (`archived-komga` → `komga`, etc.) then hit Sync, or delete the `archived-*` repos and re-mirror. Releases and assets will backfill.
>
> One question: did you unstar those three on GitHub at some point? If yes, that's why they got archived; if no, it's a false-positive I'll fix.
>
> Either way I'll fix gitea-mirror so archived/renamed repos don't get stuck in this 405 loop. Thanks for the great screenshots. 🙏
Ok soo im back to the old container, and renaming the archived- ones to the proper name and all 3 that had errors works now! With assets/release and everything!
<img width="1276" height="680" alt="Image" src="https://github.com/user-attachments/assets/9a527786-53bb-4d13-b7fc-1c88a489c81b" />
And I tried to add some new repos into it but im not fully sure if it works or not as i seem to have hit the rate limit.
<img width="1194" height="639" alt="Image" src="https://github.com/user-attachments/assets/4a767a2d-9f73-43fa-bafc-e7658df16dc1" />
And they dont seem to have the same releases page as komga, do you have an example of another repo that i can test that does releases like komga?
And do i have to manually tick the enable repository releases in the settings inside the forgejo repos for every repo?
edit:
<img width="1589" height="793" alt="Image" src="https://github.com/user-attachments/assets/c124f139-414e-4443-bdf3-42461f86eee1" />
they got archived after a while.
But does at least work when i renamed it back from archived- to the actual name and sync (just one) again.
<img width="1589" height="793" alt="Image" src="https://github.com/user-attachments/assets/d99b6f8e-8cb6-4a35-ba5d-230fe1dbfbdd" />
@RikudouGoku so it gets archived cause the orginal github repo is marked archive. the goal is to mirror the same state. are you looking to disable this feature?
Edit: Sorry looks like Komga is not archived in github but minui is. let me testvit again on my end if this is an issue.
<!-- gh-comment-id:4861773028 -->
@arunavo4 commented on GitHub (Jul 2, 2026):
@RikudouGoku so it gets archived cause the orginal github repo is marked archive. the goal is to mirror the same state. are you looking to disable this feature?
Edit: Sorry looks like Komga is not archived in github but minui is. let me testvit again on my end if this is an issue.
And do i have to manually tick the enable repository releases in the settings inside the forgejo repos for every repo?
So I am not sure how you are setting up Forgejo, but on my end when I set it up it did show up with releases on by default.
If you can share your config of docker for Forgejo I can maybe help
<!-- gh-comment-id:4861794401 -->
@arunavo4 commented on GitHub (Jul 2, 2026):
> And do i have to manually tick the enable repository releases in the settings inside the forgejo repos for every repo?
So I am not sure how you are setting up Forgejo, but on my end when I set it up it did show up with releases on by default.
If you can share your config of docker for Forgejo I can maybe help
<!-- gh-comment-id:4863595668 -->
@RikudouGoku commented on GitHub (Jul 2, 2026):
> > And do i have to manually tick the enable repository releases in the settings inside the forgejo repos for every repo?
>
> So I am not sure how you are setting up Forgejo, but on my end when I set it up it did show up with releases on by default.
>
> If you can share your config of docker for Forgejo I can maybe help
https://hastebin.com/share/emibuvibav.yaml
And do i have to manually tick the enable repository releases in the settings inside the forgejo repos for every repo?
So I am not sure how you are setting up Forgejo, but on my end when I set it up it did show up with releases on by default.
If you can share your config of docker for Forgejo I can maybe help
Can you share the environment variables you have? i assume i am missing something there.
<!-- gh-comment-id:4866559796 -->
@RikudouGoku commented on GitHub (Jul 2, 2026):
> > And do i have to manually tick the enable repository releases in the settings inside the forgejo repos for every repo?
>
> So I am not sure how you are setting up Forgejo, but on my end when I set it up it did show up with releases on by default.
>
> If you can share your config of docker for Forgejo I can maybe help
Can you share the environment variables you have? i assume i am missing something there.
Thanks for the follow-up and the compose file, that's what cracked it. There were actually two bugs here, and both are fixed in v3.20.4.
First, the archiving. Repos you add through the "+" dialog belong to other people and aren't starred, so they never show up in the GitHub listing the cleanup job was using to figure out what still exists. It took that as "deleted from GitHub" and archived them on every pass. Nothing ever changed on GitHub's side, beszel and the rest were alive the whole time. Cleanup now checks each repo directly against GitHub and only archives on a real 404.
Second, the 405. Archiving renames the repo to archived-{name} in Forgejo, but the app kept the old name in its database. Forgejo redirects requests for the old name, and following that redirect silently turns the sync POST into a GET, which the mirror-sync endpoint rejects with a 405. Sync now picks up the repo's current name from Forgejo first, so renamed mirrors just work. Renaming them back like you did was the right workaround, you just won't need it anymore.
So: update to v3.20.4 and everything heals itself on the next sync, including anything still sitting under an archived-* name. No need to delete or re-mirror anything.
I verified this with your repos on a Forgejo 15 rootless instance running the released image. Here's beszel after I renamed it to archived-beszel with the database still pointing at the old name, then hit Sync:
And GammaOSCore added through the "+" dialog, surviving a cleanup pass that would have archived it before:
GET /repos/TheGammaSqueeze/GammaOSCore - 200
[Repository Cleanup] No orphaned repositories found
On the missing Releases tab: that one isn't coming from gitea-mirror. The app never touches repo units, and mirrors created on a default Forgejo come out with the tab enabled. Your compose mounts a custom app.ini, so could you check it for DEFAULT_REPO_UNITS or DISABLED_REPO_UNITS under [repository]? If releases is missing or disabled there, Forgejo turns the tab off for every new repo it creates, mirrors included.
<!-- gh-comment-id:4867054096 -->
@arunavo4 commented on GitHub (Jul 2, 2026):
Thanks for the follow-up and the compose file, that's what cracked it. There were actually two bugs here, and both are fixed in [v3.20.4](https://github.com/RayLabsHQ/gitea-mirror/releases/tag/v3.20.4).
First, the archiving. Repos you add through the "+" dialog belong to other people and aren't starred, so they never show up in the GitHub listing the cleanup job was using to figure out what still exists. It took that as "deleted from GitHub" and archived them on every pass. Nothing ever changed on GitHub's side, beszel and the rest were alive the whole time. Cleanup now checks each repo directly against GitHub and only archives on a real 404.
Second, the 405. Archiving renames the repo to `archived-{name}` in Forgejo, but the app kept the old name in its database. Forgejo redirects requests for the old name, and following that redirect silently turns the sync POST into a GET, which the mirror-sync endpoint rejects with a 405. Sync now picks up the repo's current name from Forgejo first, so renamed mirrors just work. Renaming them back like you did was the right workaround, you just won't need it anymore.
So: update to v3.20.4 and everything heals itself on the next sync, including anything still sitting under an `archived-*` name. No need to delete or re-mirror anything.
I verified this with your repos on a Forgejo 15 rootless instance running the released image. Here's beszel after I renamed it to `archived-beszel` with the database still pointing at the old name, then hit Sync:
And GammaOSCore added through the "+" dialog, surviving a cleanup pass that would have archived it before:
```
GET /repos/TheGammaSqueeze/GammaOSCore - 200
[Repository Cleanup] No orphaned repositories found
```
On the missing Releases tab: that one isn't coming from gitea-mirror. The app never touches repo units, and mirrors created on a default Forgejo come out with the tab enabled. Your compose mounts a custom app.ini, so could you check it for `DEFAULT_REPO_UNITS` or `DISABLED_REPO_UNITS` under `[repository]`? If releases is missing or disabled there, Forgejo turns the tab off for every new repo it creates, mirrors included.
Thanks for the follow-up and the compose file, that's what cracked it. There were actually two bugs here, and both are fixed in v3.20.4.
First, the archiving. Repos you add through the "+" dialog belong to other people and aren't starred, so they never show up in the GitHub listing the cleanup job was using to figure out what still exists. It took that as "deleted from GitHub" and archived them on every pass. Nothing ever changed on GitHub's side, beszel and the rest were alive the whole time. Cleanup now checks each repo directly against GitHub and only archives on a real 404.
Second, the 405. Archiving renames the repo to archived-{name} in Forgejo, but the app kept the old name in its database. Forgejo redirects requests for the old name, and following that redirect silently turns the sync POST into a GET, which the mirror-sync endpoint rejects with a 405. Sync now picks up the repo's current name from Forgejo first, so renamed mirrors just work. Renaming them back like you did was the right workaround, you just won't need it anymore.
So: update to v3.20.4 and everything heals itself on the next sync, including anything still sitting under an archived-* name. No need to delete or re-mirror anything.
I verified this with your repos on a Forgejo 15 rootless instance running the released image. Here's beszel after I renamed it to archived-beszel with the database still pointing at the old name, then hit Sync:
And GammaOSCore added through the "+" dialog, surviving a cleanup pass that would have archived it before:
GET /repos/TheGammaSqueeze/GammaOSCore - 200
[Repository Cleanup] No orphaned repositories found
On the missing Releases tab: that one isn't coming from gitea-mirror. The app never touches repo units, and mirrors created on a default Forgejo come out with the tab enabled. Your compose mounts a custom app.ini, so could you check it for DEFAULT_REPO_UNITS or DISABLED_REPO_UNITS under [repository]? If releases is missing or disabled there, Forgejo turns the tab off for every new repo it creates, mirrors included.
Ok just upgraded and im running the syncs, will let you know how it goes after a while.
It does seem to be working though, but for the ones that did get "archived-" in their names, they do seem to be syncing but the name in forgejo is still archived- i assume i would need to manually rename them back?
I do not believe i have anything like repo units there?
<!-- gh-comment-id:4867227399 -->
@RikudouGoku commented on GitHub (Jul 2, 2026):
> Thanks for the follow-up and the compose file, that's what cracked it. There were actually two bugs here, and both are fixed in [v3.20.4](https://github.com/RayLabsHQ/gitea-mirror/releases/tag/v3.20.4).
>
> First, the archiving. Repos you add through the "+" dialog belong to other people and aren't starred, so they never show up in the GitHub listing the cleanup job was using to figure out what still exists. It took that as "deleted from GitHub" and archived them on every pass. Nothing ever changed on GitHub's side, beszel and the rest were alive the whole time. Cleanup now checks each repo directly against GitHub and only archives on a real 404.
>
> Second, the 405. Archiving renames the repo to `archived-{name}` in Forgejo, but the app kept the old name in its database. Forgejo redirects requests for the old name, and following that redirect silently turns the sync POST into a GET, which the mirror-sync endpoint rejects with a 405. Sync now picks up the repo's current name from Forgejo first, so renamed mirrors just work. Renaming them back like you did was the right workaround, you just won't need it anymore.
>
> So: update to v3.20.4 and everything heals itself on the next sync, including anything still sitting under an `archived-*` name. No need to delete or re-mirror anything.
>
> I verified this with your repos on a Forgejo 15 rootless instance running the released image. Here's beszel after I renamed it to `archived-beszel` with the database still pointing at the old name, then hit Sync:
>
> 
>
> 
>
> And GammaOSCore added through the "+" dialog, surviving a cleanup pass that would have archived it before:
>
> ```
> GET /repos/TheGammaSqueeze/GammaOSCore - 200
> [Repository Cleanup] No orphaned repositories found
> ```
>
> 
>
> On the missing Releases tab: that one isn't coming from gitea-mirror. The app never touches repo units, and mirrors created on a default Forgejo come out with the tab enabled. Your compose mounts a custom app.ini, so could you check it for `DEFAULT_REPO_UNITS` or `DISABLED_REPO_UNITS` under `[repository]`? If releases is missing or disabled there, Forgejo turns the tab off for every new repo it creates, mirrors included.
Ok just upgraded and im running the syncs, will let you know how it goes after a while.
It does seem to be working though, but for the ones that did get "archived-" in their names, they do seem to be syncing but the name in forgejo is still archived- i assume i would need to manually rename them back?
app.ini:
https://hastebin.com/share/vohukawuhu.ini
I do not believe i have anything like repo units there?
Can you start with a fresh Forgejo so that we can check if teh archived issue was fixed or not?
<!-- gh-comment-id:4867433252 -->
@arunavo4 commented on GitHub (Jul 2, 2026):
Can you start with a fresh Forgejo so that we can check if teh archived issue was fixed or not?
<!-- gh-comment-id:4867477202 -->
@RikudouGoku commented on GitHub (Jul 2, 2026):
> Can you start with a fresh Forgejo so that we can check if teh archived issue was fixed or not?
Judging by the logs it should be working, i seem to be hitting the api rate limit.
https://send.vis.ee/download/b52d21df47f666f4/#hPJFgvYiiOpzjkv_q5jbRg
I will wait and see how it goes.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @RikudouGoku on GitHub (Jun 23, 2026).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/331
Originally assigned to: @arunavo4 on GitHub.
Settings:
Activity log:
But in my forgejo instance:
gitea-mirror part in my compose:
https://hastebin.com/share/utujuvosiy.ruby
No error in the logs either.
@arunavo4 commented on GitHub (Jun 23, 2026):
@RikudouGoku try the new version and thanks for reporting this.
@RikudouGoku commented on GitHub (Jun 23, 2026):
Still the same
EDIT: I tried another repo I have not mirrored and it did not work either.
https://github.com/TheGammaSqueeze/GammaOSCore
@RikudouGoku commented on GitHub (Jun 23, 2026):
Here are the logs (1k rows).
https://send.vis.ee/download/d07b35befc29e359/#FqTBLT2S7xSb7VxHlahzoA
(expires after 1 download or 1 day.)
Here is a small part of it that I think is relevant:
@arunavo4 commented on GitHub (Jun 24, 2026):
@RikudouGoku it works on my end can you tell me which forgejo version are you using? specifically? also if possible can you do a fresh install of both gitea-mirror and forgejo and try again with one repo? I feel like some tags during creation might have not been created and that could have caused this.
Below are screenshots from my testing
@RikudouGoku commented on GitHub (Jun 24, 2026):
Here is my entire compose.
https://hastebin.com/share/zozitizaxu.yaml
Forgejo 15 rootless
@arunavo4 commented on GitHub (Jun 24, 2026):
Thanks for the version + full compose @RikudouGoku — that helped a lot.
I reproduced your exact Forgejo stack on a test box —
forgejo:15-rootlesswithread_only: true,cap_drop: ALL,user 99:100, tmpfs/tmp— and gitea-mirror creates the releases with their assets without any problem (HTTP 201). I also tested Gitea 1.20–1.26 and Forgejo 1.21–15: on a healthy repo the release create always succeeds. So the Forgejo version and the read-only/rootless hardening are not the cause.What
404 "The target couldn't be found"actually means: it's Gitea's generic not-found, and on the release-create call it fires in exactly one situation — when the release's git tag isn't present in the repo at the moment of creation. gitea-mirror was sendingtarget=mainso Gitea would try to create the tag, and if the tag/ref isn't there yet it 404s. This lines up with your symptom (every release failing while issues/PRs succeed, since those don't touch git refs) and with the idea that the git mirror hadn't finished syncing the tags when the release step ran.Fix incoming (https://github.com/RayLabsHQ/gitea-mirror/pull/333): gitea-mirror will now only create a release when its git tag already exists in Gitea — if it's not synced yet it skips and retries on the next sync — and it no longer sends
targetat all. That removes the failure mode entirely.To confirm the underlying cause on your side, could you grab your Forgejo container logs (not gitea-mirror's) during a sync that fails? gitea-mirror only sees the generic 404, but Forgejo logs the real error behind it:
That'll show whether the tag was missing / a git error at that moment. A fresh install with a single repo (as suggested) plus those logs would nail it. Thanks again for the detailed reports! 🙏
@RikudouGoku commented on GitHub (Jun 24, 2026):
e
ok so to dumb it down since i understood nothing, you think it isnt my fault and you will have a fix incoming?
Here are the logs btw of my current container.
https://send.vis.ee/download/6aea6d1196db9cbf/#dKYgj75U6ollqP4aqOOYww
(expires after 1 day or 1 download)
@arunavo4 commented on GitHub (Jun 24, 2026):
@RikudouGoku sorry for confusing, its not your fault, just try the latest
v3.20.2@RikudouGoku commented on GitHub (Jun 24, 2026):
Logs:
https://send.vis.ee/download/d137913f6242d79d/#GaeOcnG74iSztbf-U665WQ
Screenshot.
@arunavo4 commented on GitHub (Jun 25, 2026):
@RikudouGoku I tried to mirror and sync komga repo releases and I got the 121MB jar file you are trying to download the zip and tar.gz which is just the source code. as you can see on the releases page there is the jar file showing up.
and regarding the two thats failed try to retry them and cehck the logs
@arunavo4 commented on GitHub (Jun 25, 2026):
@RikudouGoku I think I know why its failing on your side you have the "Releases" disabled as the tab is not shown on your screenshot can you turn it on?
@RikudouGoku commented on GitHub (Jun 25, 2026):
I enabled this, but nothing shows up.
However this is the repo that also gives me errors.
I tried enabling the releases in the settings page for the others that does not have errors
And it does work here at least.
The logs for the ones that errors:
gitea-mirror log:
https://hastebin.com/share/ubidaforiz.typescript
forgejo log:
https://hastebin.com/share/rajafiwele.bash
The ones that errors out is "archived" in forgejo.
@arunavo4 commented on GitHub (Jul 1, 2026):
Quick update @RikudouGoku:
The v3.20.2 release/asset fix works, that's why MinUI, Media-Server and Server sync fine.
The 3 that still fail (komga, beszel, GammaOSCore) show up in Forgejo as
archived-komga,archived-beszel,archived-GammaOSCore. gitea-mirror auto-archived them by renaming, and the rename breaks the sync: Forgejo redirects the old name and the request ends in HTTP 405, so it never reaches the releases step. Not an asset bug this time.Fix it now: in Forgejo rename them back (
archived-komga→komga, etc.) then hit Sync, or delete thearchived-*repos and re-mirror. Releases and assets will backfill.One question: did you unstar those three on GitHub at some point? If yes, that's why they got archived; if no, it's a false-positive I'll fix.
Either way I'll fix gitea-mirror so archived/renamed repos don't get stuck in this 405 loop. Thanks for the great screenshots. 🙏
@RikudouGoku commented on GitHub (Jul 1, 2026):
I will check it when I'm back from work.
But I am pretty damn sure I did not star/unstar anything when I tested it though. For example both komga and minui do not have stars now. All I did was go to the github page and copy the link and nothing else, I rarely star repos.
@arunavo4 commented on GitHub (Jul 1, 2026):
@RikudouGoku Can you try once more on a fresh install of gitea and gitea-mirror?
@RikudouGoku commented on GitHub (Jul 1, 2026):
I don't use gitea. I will try to spin up another container with the same compose pointing to a new folder when I'm home.
@arunavo4 commented on GitHub (Jul 1, 2026):
right sorry Forgejo
@RikudouGoku commented on GitHub (Jul 1, 2026):
Ok so spun up a completely new forgejo (and its db) and gitea-mirror containers. I do not get archived with komga/minui but nothing is downloaded via assets. The gitea-mirror configuration settings are identical as the pictures posted previously in this thread.
Logs:
https://send.vis.ee/download/cf52e51774c08dae/#NwnUNLbYqRjpWD2uVXAdvg
@RikudouGoku commented on GitHub (Jul 1, 2026):
Ok soo im back to the old container, and renaming the archived- ones to the proper name and all 3 that had errors works now! With assets/release and everything!
And I tried to add some new repos into it but im not fully sure if it works or not as i seem to have hit the rate limit.
And they dont seem to have the same releases page as komga, do you have an example of another repo that i can test that does releases like komga?
And do i have to manually tick the enable repository releases in the settings inside the forgejo repos for every repo?
edit:
But does at least work when i renamed it back from archived- to the actual name and sync (just one) again.
@arunavo4 commented on GitHub (Jul 2, 2026):
@RikudouGoku so it gets archived cause the orginal github repo is marked archive. the goal is to mirror the same state. are you looking to disable this feature?
Edit: Sorry looks like Komga is not archived in github but minui is. let me testvit again on my end if this is an issue.
@arunavo4 commented on GitHub (Jul 2, 2026):
So I am not sure how you are setting up Forgejo, but on my end when I set it up it did show up with releases on by default.
If you can share your config of docker for Forgejo I can maybe help
@RikudouGoku commented on GitHub (Jul 2, 2026):
https://hastebin.com/share/emibuvibav.yaml
@RikudouGoku commented on GitHub (Jul 2, 2026):
Can you share the environment variables you have? i assume i am missing something there.
@arunavo4 commented on GitHub (Jul 2, 2026):
Thanks for the follow-up and the compose file, that's what cracked it. There were actually two bugs here, and both are fixed in v3.20.4.
First, the archiving. Repos you add through the "+" dialog belong to other people and aren't starred, so they never show up in the GitHub listing the cleanup job was using to figure out what still exists. It took that as "deleted from GitHub" and archived them on every pass. Nothing ever changed on GitHub's side, beszel and the rest were alive the whole time. Cleanup now checks each repo directly against GitHub and only archives on a real 404.
Second, the 405. Archiving renames the repo to
archived-{name}in Forgejo, but the app kept the old name in its database. Forgejo redirects requests for the old name, and following that redirect silently turns the sync POST into a GET, which the mirror-sync endpoint rejects with a 405. Sync now picks up the repo's current name from Forgejo first, so renamed mirrors just work. Renaming them back like you did was the right workaround, you just won't need it anymore.So: update to v3.20.4 and everything heals itself on the next sync, including anything still sitting under an
archived-*name. No need to delete or re-mirror anything.I verified this with your repos on a Forgejo 15 rootless instance running the released image. Here's beszel after I renamed it to
archived-beszelwith the database still pointing at the old name, then hit Sync:And GammaOSCore added through the "+" dialog, surviving a cleanup pass that would have archived it before:
On the missing Releases tab: that one isn't coming from gitea-mirror. The app never touches repo units, and mirrors created on a default Forgejo come out with the tab enabled. Your compose mounts a custom app.ini, so could you check it for
DEFAULT_REPO_UNITSorDISABLED_REPO_UNITSunder[repository]? If releases is missing or disabled there, Forgejo turns the tab off for every new repo it creates, mirrors included.@RikudouGoku commented on GitHub (Jul 2, 2026):
Ok just upgraded and im running the syncs, will let you know how it goes after a while.
It does seem to be working though, but for the ones that did get "archived-" in their names, they do seem to be syncing but the name in forgejo is still archived- i assume i would need to manually rename them back?
app.ini:
https://hastebin.com/share/vohukawuhu.ini
I do not believe i have anything like repo units there?
@arunavo4 commented on GitHub (Jul 2, 2026):
Can you start with a fresh Forgejo so that we can check if teh archived issue was fixed or not?
@RikudouGoku commented on GitHub (Jul 2, 2026):
Judging by the logs it should be working, i seem to be hitting the api rate limit.
https://send.vis.ee/download/b52d21df47f666f4/#hPJFgvYiiOpzjkv_q5jbRg
I will wait and see how it goes.