2017-11-27 05:44:32 +08:00
---
date: "2016-11-08T16:00:00+02:00"
title: "Troubleshooting"
slug: "troubleshooting"
weight: 10
toc: true
draft: false
menu:
sidebar:
2018-01-09 06:48:42 +08:00
parent: "help"
2017-11-27 05:44:32 +08:00
name: "Troubleshooting"
weight: 20
identifier: "troubleshooting"
---
# Troubleshooting
2018-01-09 06:48:42 +08:00
This page contains some common seen issues and their solutions.
2017-11-27 05:44:32 +08:00
## SSH issues
2019-03-10 05:15:45 +08:00
For issues reaching repositories over `ssh` while the Gitea web front-end, but
2018-01-09 06:48:42 +08:00
`https` based git repository access works fine, consider looking into the following.
2017-11-27 05:44:32 +08:00
```
Permission denied (publickey).
fatal: Could not read from remote repository.
```
2018-01-09 06:48:42 +08:00
This error signifies that the server rejected a log in attempt, check the
2017-11-27 05:44:32 +08:00
following things:
* On the client:
* Ensure the public and private ssh keys are added to the correct Gitea user.
2019-03-10 05:15:45 +08:00
* Make sure there are no issues in the remote url. In particular, ensure the name of the
2017-11-27 05:44:32 +08:00
git user (before the `@` ) is spelled correctly.
2018-01-09 06:48:42 +08:00
* Ensure public and private ssh keys are correct on client machine.
* Try to connect using ssh (ssh git@myremote.example) to ensure a connection
can be made.
2017-11-27 05:44:32 +08:00
* On the server:
2018-01-09 06:48:42 +08:00
* Make sure the repository exists and is correctly named.
* Check the permissions of the `.ssh` directory in the system user's home directory.
2017-11-27 05:44:32 +08:00
* Verify that the correct public keys are added to `.ssh/authorized_keys` .
Try to run `Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys)` on the
Gitea admin panel.
2019-03-10 05:15:45 +08:00
* Read Gitea logs.
2018-01-09 06:48:42 +08:00
* Read /var/log/auth (or similar).
* Check permissions of repositories.
2017-11-27 05:44:32 +08:00
2018-01-09 06:48:42 +08:00
The following is an example of a missing public SSH key where authentication
succeeded, but some other setting is preventing SSH from reaching the correct
repository.
2017-11-27 05:44:32 +08:00
```
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
```
In this case, look into the following settings:
* On the server:
2018-01-09 06:48:42 +08:00
* Make sure that the `git` system user has a usable shell set
* Verify this with `getent passwd git | cut -d: -f7`
* `usermod` or `chsh` can be used to modify this.
2017-11-27 05:44:32 +08:00
* Ensure that the `gitea serv` command in `.ssh/authorized_keys` uses the
2018-01-09 06:48:42 +08:00
correct configuration file.
2018-04-21 09:22:02 +08:00
## Missing releases after migrating repository with tags
2019-03-10 05:15:45 +08:00
To migrate an repository *with* all tags, you need to do two things:
2018-04-21 09:22:02 +08:00
* Push tags to the repository:
```
git push --tags
```
2019-03-10 05:15:45 +08:00
* (Re-)sync tags of all repositories within Gitea:
2018-04-21 09:22:02 +08:00
```
gitea admin repo-sync-releases
```
2018-10-21 00:49:04 +08:00
## LFS Issues
For issues concerning LFS data upload
```
batch response: Authentication required: Authorization error: < GITEA_LFS_URL > /info/lfs/objects/batch
Check that you have proper access to the repository
error: failed to push some refs to '< GIT_REPO_URL > '
```
2019-03-10 05:15:45 +08:00
Have you checked the value of `LFS_HTTP_AUTH_EXPIRY` in your `app.ini` file? By default, your LFS token will expire after 20 minutes. If you have a slow connection or a large file (or both), it may not finish uploading within the time limit.
2018-10-21 00:49:04 +08:00
You may want to set this value to `60m` or `120m` .
