Github fine grained access token does not work after initial pull #10053

New Issue

GiteaMirror · 2025-11-02T08:56:58-06:00

GiteaMirror commented

2025-11-02 08:56:58 -06:00

Originally created by @TheDom42 on GitHub (Jan 3, 2023).

I have configured a mirror repo to pull clone a github repo in my account, using the "new"/beta fine-grained access token (instead of classical tokens).

When setting up the repo in gitea, everything works perfectly and the inital pull is fast. However, the automatic cron pull as well as the manual pull fail complete silently:

The user initiating the pull manually receives the message that the repos will be synced
The cron is marked as "last run at..."
However, in both cases, no sync actually takes place!

As I'm rather new to gitea, I finally stumbled upon the admin logs which are spammed with messages looking like this:

Failed to update mirror repository '<REDACTED>': fatal: could not read Username for 'https://github.com': 
terminal prompts disabled
error: could not fetch origin

I have set tup the personal access tokens with read-only permissions and only allow access to that specific repo on Github. As the inital setup with the token worked, I was very surprised that the mirror updates fail afterwards.
Just as clarification for me: are the new Github "fine grained access tokens" fully supported yet? If so, which of the repo access rights (https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2022-11-28) are mandatory to work for a read-only pull mirror? Do I actually need to set some of them to write permissions (which I would like to avoid)?

Originally posted by @TheDom42 in https://github.com/go-gitea/gitea/issues/20984#issuecomment-1369257464

Originally created by @TheDom42 on GitHub (Jan 3, 2023). I have configured a mirror repo to pull clone a github repo in my account, using the "new"/beta fine-grained access token (instead of classical tokens). When setting up the repo in gitea, everything works perfectly and the inital pull is fast. However, the automatic cron pull as well as the manual pull fail complete silently: 1. The user initiating the pull manually receives the message that the repos will be synced 2. The cron is marked as "last run at..." However, in both cases, no sync actually takes place! As I'm rather new to gitea, I finally stumbled upon the admin logs which are spammed with messages looking like this: ``` Failed to update mirror repository '<REDACTED>': fatal: could not read Username for 'https://github.com': terminal prompts disabled error: could not fetch origin ``` I have set tup the personal access tokens with read-only permissions and only allow access to that specific repo on Github. As the inital setup with the token worked, I was very surprised that the mirror updates fail afterwards. Just as clarification for me: are the new Github "fine grained access tokens" fully supported yet? If so, which of the repo access rights (https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2022-11-28) are mandatory to work for a read-only pull mirror? Do I actually need to set some of them to write permissions (which I would like to avoid)? _Originally posted by @TheDom42 in https://github.com/go-gitea/gitea/issues/20984#issuecomment-1369257464_

GiteaMirror added the type/bug label 2025-11-02 08:56:58 -06:00

GiteaMirror commented

2025-11-02 08:56:59 -06:00

@Aric-Sun commented on GitHub (Oct 19, 2023):

My situation is similar to yours, but I'm using classic personal access tokens. The initial pull of the private repo is very fast, but when you click the "Sync Now" button in the repo settings, it will appear in the system prompt of the background management.Failed to update mirror repository 'F:\Gitea\data\gitea-repositories\xxxx\xxxxxx.git': fatal: could not read Username for 'https://github.com': terminal prompts disabled

@Aric-Sun commented on GitHub (Oct 19, 2023): My situation is similar to yours, but I'm using classic personal access tokens. The initial pull of the private repo is very fast, but when you click the "Sync Now" button in the repo settings, it will appear in the system prompt of the background management.`Failed to update mirror repository 'F:\Gitea\data\gitea-repositories\xxxx\xxxxxx.git': fatal: could not read Username for 'https://github.com': terminal prompts disabled`

GiteaMirror commented

2025-11-02 08:56:59 -06:00

@lng2020 commented on GitHub (Oct 19, 2023):

What's your Gitea version? Sometimes I encountered issues with the Gitea pull mirror too. But I don't know how to reproduce stably.

@lng2020 commented on GitHub (Oct 19, 2023): What's your Gitea version? Sometimes I encountered issues with the Gitea pull mirror too. But I don't know how to reproduce stably.

GiteaMirror commented

2025-11-02 08:56:59 -06:00

@Aric-Sun commented on GitHub (Oct 19, 2023):

What's your Gitea version? Sometimes I encountered issues with the Gitea pull mirror too. But I don't know how to reproduce stably.

Gitea Ver. 1.20.5 built with GNU Make 4.2.1, go1.20.8 : bindata, sqlite, sqlite_unlock_notify
Git Ver. 2.40.0, Wire Protocol Version 2 Enabled
Windows 10 22H2 Workstation

@Aric-Sun commented on GitHub (Oct 19, 2023): > What's your Gitea version? Sometimes I encountered issues with the Gitea pull mirror too. But I don't know how to reproduce stably. Gitea Ver. 1.20.5 built with GNU Make 4.2.1, go1.20.8 : bindata, sqlite, sqlite_unlock_notify Git Ver. 2.40.0, Wire Protocol Version 2 Enabled Windows 10 22H2 Workstation

GiteaMirror commented

2025-11-02 08:56:59 -06:00

@Aric-Sun commented on GitHub (Nov 7, 2023):

I found a detail: when I modify the interval for mirroring a mirror repository in the repository settings (changing the default 8h to 24h), and then click 'Update Mirror Settings,' the automatic mirroring functionality may not work properly. I suspect that leaving the authorization information (the input fields for only username and password) blank when updating the mirror settings will override the reserved personal access token, causing the mirroring to fail.

@Aric-Sun commented on GitHub (Nov 7, 2023): I found a detail: when I modify the interval for mirroring a mirror repository in the repository settings (changing the default 8h to 24h), and then click 'Update Mirror Settings,' the automatic mirroring functionality may not work properly. I suspect that leaving the authorization information (the input fields for only username and password) blank when updating the mirror settings will override the reserved personal access token, causing the mirroring to fail.

GiteaMirror commented

2025-11-02 08:57:00 -06:00

@delvh commented on GitHub (Nov 7, 2023):

@Aric-Sun Yes, I think I've observed similar behavior on 1.20.
However, I haven't observed it on 1.21. yet.

@delvh commented on GitHub (Nov 7, 2023): @Aric-Sun Yes, I think I've observed similar behavior on 1.20. However, I haven't observed it on 1.21. yet.

GiteaMirror commented

2025-11-02 08:57:00 -06:00

@lng2020 commented on GitHub (Nov 7, 2023):

I suspect that leaving the authorization information (the input fields for only username and password) blank when updating the mirror settings will override the reserved personal access token, causing the mirroring to fail.

Yes. I can recall such relevant code because I handled a similar issue before.

@lng2020 commented on GitHub (Nov 7, 2023): > I suspect that leaving the authorization information (the input fields for only username and password) blank when updating the mirror settings will override the reserved personal access token, causing the mirroring to fail. Yes. I can recall such relevant code because I handled a similar issue before.

GiteaMirror commented

2025-11-02 08:57:00 -06:00

@Aric-Sun commented on GitHub (Nov 7, 2023):

@Aric-Sun Yes, I think I've observed similar behavior on 1.20. However, I haven't observed it on 1.21. yet.

@delvh I am looking forward to the official release of 1.21.

@Aric-Sun commented on GitHub (Nov 7, 2023): > @Aric-Sun Yes, I think I've observed similar behavior on 1.20. However, I haven't observed it on 1.21. yet. @delvh I am looking forward to the official release of 1.21.

GiteaMirror commented

2025-11-02 08:57:00 -06:00

@Aric-Sun commented on GitHub (Nov 7, 2023):

I suspect that leaving the authorization information (the input fields for only username and password) blank when updating the mirror settings will override the reserved personal access token, causing the mirroring to fail.

Yes. I can recall such relevant code because I handled a similar issue before.

Based on my understanding, shouldn't updating the mirror settings ignore empty fields? So, does changing the sync interval of the mirror repository ultimately need to be modified in the global configuration file, for example:

[cron.update_mirrors]
SCHEDULE = @every 24h

@Aric-Sun commented on GitHub (Nov 7, 2023): > > I suspect that leaving the authorization information (the input fields for only username and password) blank when updating the mirror settings will override the reserved personal access token, causing the mirroring to fail. > > Yes. I can recall such relevant code because I handled a similar issue before. Based on my understanding, shouldn't updating the mirror settings ignore empty fields? So, does changing the sync interval of the mirror repository ultimately need to be modified in the global configuration file, for example: ```ini [cron.update_mirrors] SCHEDULE = @every 24h ```

GiteaMirror commented

2025-11-02 08:57:01 -06:00

@delvh commented on GitHub (Nov 7, 2023):

As I said: It's a bug, and I think 1.21. fixed it.

@delvh commented on GitHub (Nov 7, 2023): As I said: It's a bug, and I think 1.21. fixed it.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10053