Docker authorized_keys not initialized on container start #2250

New Issue

GiteaMirror · 2025-11-02T04:29:29-06:00

GiteaMirror commented

2025-11-02 04:29:29 -06:00

Originally created by @Shadow53 on GitHub (Aug 26, 2018).

Gitea version (or commit ref): Docker gitea/gitea:latest (1.5.0)
Git version: N/A
Operating system: Fedora Server w/ Docker
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

If the Docker container is taken down and brought back up (in this case with docker stack deploy/rm), the server's authorized_keys does not persist, nor is it initialized with the data from the database, or wherever the information gets persisted. Running the "Update the '.ssh/authorized_keys' file with Gitea SSH keys" action from the admin page fixes the issue, but this should probably be run when the container starts.

I've worked around the issue for now by creating a volume for /data/git/.ssh in the container, though I personally think ensuring the file gets generated is a better solution.

Originally created by @Shadow53 on GitHub (Aug 26, 2018). - Gitea version (or commit ref): Docker gitea/gitea:latest (1.5.0) - Git version: N/A - Operating system: Fedora Server w/ Docker - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description If the Docker container is taken down and brought back up (in this case with `docker stack deploy`/`rm`), the server's `authorized_keys` does not persist, nor is it initialized with the data from the database, or wherever the information gets persisted. Running the "Update the '.ssh/authorized_keys' file with Gitea SSH keys" action from the admin page fixes the issue, but this should probably be run when the container starts. I've worked around the issue for now by creating a volume for `/data/git/.ssh` in the container, though I personally think ensuring the file gets generated is a better solution.

GiteaMirror added the issue/stale label 2025-11-02 04:29:29 -06:00

GiteaMirror closed this issue

2025-11-02 04:29:29 -06:00

GiteaMirror commented

2025-11-02 04:29:31 -06:00

@stale[bot] commented on GitHub (Jan 12, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 12, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:29:31 -06:00

@stale[bot] commented on GitHub (Feb 21, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Feb 21, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 12:07:13 -06:00

[PR #2250] [MERGED] update code.gitea.io/git in vendor to fix delete branch fails #16305

Sign in to join this conversation.