Need to add --work-path to authorized_keys #9481

zzps · 2019-12-24T03:43:34Z

Gitea version (or commit ref): 1.10.1
Git version: 2.24.1
Operating system: centos 7.7
Database (use [x]): tidb 3.0 ok for mysql
- PostgreSQL
- [x ] MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- [x ] No
- Not relevant
Log gist:
can not clone repository over ssh , and it is work over http

Description


and I find some different detail between gogs and gitea when I installing :
1,the authorized_keys file show the line between command and ..app.ini in red color in gitea but not in gogs
2,when I try :  ssh -T git@ip .gogs respone : Hi there, You've successfully authenticated, but Gogs does not provide shell access ....      but gitea without this words
when I use :  git clone git@ip:pay-group/coocat-module-pay.git "  get error: " Could not read from remote repository.Please make sure you have the correct access rights and the repository exists"

down I cut 4 pic ,   the 1 , 2 is for gitea   and   the 3 ,4 is for gogs.

Screenshots

![图片](https://user-images.githubusercontent.com/33255974/71391823-bbdff300-2640-11ea-970f-06e61b6b56b8.png)
![图片](https://user-images.githubusercontent.com/33255974/71391847-d6b26780-2640-11ea-916e-e2887cd6ea0e.png)
![图片](https://user-images.githubusercontent.com/33255974/71391864-e336c000-2640-11ea-8a6b-ca7308103f92.png)

The text was updated successfully, but these errors were encountered:

bagasme · 2019-12-24T03:59:48Z

@zzps Perhaps at what repo you install Git?

And can you provide full log for this issue?

zzps · 2019-12-24T04:10:17Z

@zzps Perhaps at what repo you install Git?

And can you provide full log for this issue?

ok ,I have said that when gitea is not work, I do that use gogs with same way on the same machine . and clone work fine both over ssh and http. so it can prove git is ok.
and you ask more log ,i show some.
app.ini :
APP_NAME = 智脸猫
RUN_USER = git
RUN_MODE = prod

[oauth2]
JWT_SECRET = iY6hiKXXTNojeIufes_60zWdXGdA_Vdfg6cPHxmjYIs

[security]
INTERNAL_TOKEN = eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE1NzcwOTU3Nzh9.WPuyTLb3sG43w0nbczkPO_qvlN7eCgeROJQwWLKhfQk
INSTALL_LOCK = true
SECRET_KEY = HYG2JjZsVeYq71FWiHYj7Favq4lEjYnV1nIQYlbhSNMjElqDqhsr0pTjdWq97e9K

[database]
DB_TYPE = mysql
HOST = 192.168.1.253:4000
NAME = gitea
USER = root
PASSWD = coolcat@zzps@081341203
SSL_MODE = disable
CHARSET = utf8mb4
PATH = /usr/local/gitea/data/gitea.db

[repository]
ROOT = /home/git/repository

[server]
SSH_DOMAIN = 192.168.1.249
DOMAIN = 192.168.1.249
HTTP_PORT = 3000
ROOT_URL = http://192.168.1.249:3000/
DISABLE_SSH = false
SSH_PORT = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /usr/local/gitea/data/lfs
LFS_JWT_SECRET = M2-guVL-gKbsZHPXb6Ge-icZnuzgClt06FxwPQIMZbQ
OFFLINE_MODE = false
BUILTIN_SSH_SERVER_USER = git
#START_SSH_SERVER = true
[mailer]
ENABLED = false

[service]
REGISTER_EMAIL_CONFIRM = false
ENABLE_NOTIFY_MAIL = false
DISABLE_REGISTRATION = false
ALLOW_ONLY_EXTERNAL_REGISTRATION = false
ENABLE_CAPTCHA = false
REQUIRE_SIGNIN_VIEW = false
DEFAULT_KEEP_EMAIL_PRIVATE = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING = true
NO_REPLY_ADDRESS = noreply.example.org

[picture]
DISABLE_GRAVATAR = false
ENABLE_FEDERATED_AVATAR = true

[openid]
ENABLE_OPENID_SIGNIN = false
ENABLE_OPENID_SIGNUP = false

[session]
PROVIDER = file

[log]
MODE = file
LEVEL = info
ROOT_PATH = /usr/local/gitea/log

and I try : ssh -vT [email protected] .the response is
$ ssh -vT [email protected]
OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.1.249 [192.168.1.249] port 22.
debug1: Connection established.
debug1: identity file /c/Users/HZQ/.ssh/id_rsa type 0
debug1: identity file /c/Users/HZQ/.ssh/id_rsa-cert type -1
debug1: identity file /c/Users/HZQ/.ssh/id_dsa type -1
debug1: identity file /c/Users/HZQ/.ssh/id_dsa-cert type -1
debug1: identity file /c/Users/HZQ/.ssh/id_ecdsa type -1
debug1: identity file /c/Users/HZQ/.ssh/id_ecdsa-cert type -1
debug1: identity file /c/Users/HZQ/.ssh/id_ed25519 type -1
debug1: identity file /c/Users/HZQ/.ssh/id_ed25519-cert type -1
debug1: identity file /c/Users/HZQ/.ssh/id_xmss type -1
debug1: identity file /c/Users/HZQ/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to 192.168.1.249:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: compression: none
debug1: kex: client->server cipher: [email protected] MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:tb7qobfbP/lYnboDAQIZ0WUIhfxNc63cnQkMesnG+9o
debug1: Host '192.168.1.249' is known and matches the ECDSA host key.
debug1: Found key in /c/Users/HZQ/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /c/Users/HZQ/.ssh/id_rsa RSA SHA256:WIbTyJ25Y8s4rc5RKcIOQuFnLBImTfpbsJyIwztJLIA
debug1: Will attempt key: /c/Users/HZQ/.ssh/id_dsa
debug1: Will attempt key: /c/Users/HZQ/.ssh/id_ecdsa
debug1: Will attempt key: /c/Users/HZQ/.ssh/id_ed25519
debug1: Will attempt key: /c/Users/HZQ/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /c/Users/HZQ/.ssh/id_rsa RSA SHA256:WIbTyJ25Y8s4rc5RKcIOQuFnLBImTfpbsJyIwztJLIA
debug1: Server accepts key: /c/Users/HZQ/.ssh/id_rsa RSA SHA256:WIbTyJ25Y8s4rc5RKcIOQuFnLBImTfpbsJyIwztJLIA
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.249 ([192.168.1.249]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: PTY allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: PTY allocation disabled.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 3532, received 3412 bytes, in 0.2 seconds
Bytes per second: sent 14537.5, received 14043.6
debug1: Exit status 1

zzps · 2019-12-24T04:53:08Z

@zzps Perhaps at what repo you install Git?

And can you provide full log for this issue?

more information! when I use gitea inernal ssh server by add
START_SSH_SERVER = true
SSH_PORT = 22222
it works!!!
so why it can't work with openssh???why?

lunny · 2019-12-24T07:29:43Z

You cannot share the git account with other git service. I think that's the reason why ssh not work.

zzps · 2019-12-24T07:34:39Z

You cannot share the git account with other git service. I think that's the reason why ssh not work.

I create user git just for run gitea，no others。by the way I have said gogs works fine, and use gitea built ssh server works fine

lunny · 2019-12-24T07:44:25Z

You can go to gitea ui -> admin panel and run Update the '.ssh/authorized_keys' file with Gitea SSH keys. (Not needed for the built-in SSH server.) and Resynchronize pre-receive, update and post-receive hooks of all repositories.. That will overwrite other git services' public key and hooks.

zeripath · 2019-12-24T07:50:51Z

The key you use to connect to Gitea must be controlled by Gitea. That is, it must have been added to Gitea's db and must have been added to the authorized_keys file by Gitea.

zzps · 2019-12-24T07:52:17Z

You can go to gitea ui -> admin panel and run Update the '.ssh/authorized_keys' file with Gitea SSH keys. (Not needed for the built-in SSH server.) and Resynchronize pre-receive, update and post-receive hooks of all repositories.. That will overwrite other git services' public key and hooks.

i have done all that steps , no work!

zzps · 2019-12-24T07:53:43Z

The key you use to connect to Gitea must be controlled by Gitea. That is, it must have been added to Gitea's db and must have been added to the authorized_keys file by Gitea.

yes! I actualy do all these operation, but no work! but gogs works well !

zeripath · 2019-12-24T08:02:27Z

Are you running gogs and Gitea with the same user? Your description seems to imply that. That won't work and I'd ask you to think about why because the reason is simple.

Remove all of the gogs lines from authorized_keys.

zzps · 2019-12-24T08:04:23Z

The key you use to connect to Gitea must be controlled by Gitea. That is, it must have been added to Gitea's db and must have been added to the authorized_keys file by Gitea.

I do the gitea install strictly by the document, I see the key be added to the db and authorized_keys file all things be done ok, and it is fine in gogs but can not work in gitea

zzps · 2019-12-24T08:07:18Z

Are you running gogs and Gitea with the same user? Your description seems to imply that. That won't work and I'd ask you to think about why because the reason is simple.

Remove all of the gogs lines from authorized_keys.
yes , I run gogs and Gitea with the same user "git", before I change gogs to gitea, I have remove all the gogs key from authorized_keys . and it still not work

zeripath · 2019-12-24T08:30:07Z

If Gitea works on the internal SSH server then the problem lies at authorized_keys.

Let us begin again.

What user is running Gitea?
What config and what environment are you using to run Gitea and where?
Do the lines in .ssh/authorized_keys look correct for the above information? Give us an example - you can cut the key off after the first few letters.
Ensure that Gitea is now no longer running with the internal SSH server running otherwise the next step won't work.
Delete or better move the authorized_keys file, and regenerate it from the running Gitea process. Check how that differs.
When things fail are you even getting logs on the Gitea server?

I assure you this works - I use open sshd with Gitea myself - so the problem is with your configuration.

For simplicities sake don't try pushing just try SSHing in - that way we know if your key is being properly matched with an authorized key line.

zzps · 2019-12-24T09:04:57Z

If Gitea works on the internal SSH server then the problem lies at authorized_keys.

Let us begin again.
1. What user is running Gitea?

2. What config and what environment are you using to run Gitea and where?

3. Do the lines in .ssh/authorized_keys look correct for the above information? Give us an example - you can cut the key off after the first few letters.

4. Ensure that Gitea is now no longer running with the internal SSH server running otherwise the next step won't work.

5. Delete or better move the authorized_keys file, and regenerate it from the running Gitea process. Check how that differs.

6. When things fail are you even getting logs on the Gitea server?
I assure you this works - I use open sshd with Gitea myself - so the problem is with your configuration.

For simplicities sake don't try pushing just try SSHing in - that way we know if your key is being properly matched with an authorized key line.

ok, now I answer your question one by one:
1, I use user git run gitea , and only run gitea
2, I do not know your point about the config and environment, I could say that app.ini is above,and git version ,system too
3, I copy the key from authorized_keys here :

gitea public key

command="/usr/local/gitea/gitea --config='/usr/local/gitea/custom/conf/app.ini' serv key-14",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDkeFfDMzT355/gLB2OooglszXmLcYlOz/wrDjR4aJNV2aPBq7uKwktdZb+7ECZTT2DK6/BaC5cnbOmlqCt78dNWEMKx7jSgAOpEQSqY6EBGSsSkoQsXwjOwrfOPAfG/tQAXIKDhv51ih71MzHZFxcvw/eIOq+h3YvduBxXlrplJ+OfU68ecD26mCkrLhQCdB51ZZnSpGWJyEGucnXOrxuRooUlPZJnNSiRNb6nUmNKpsNqACygBJduxOIvVcEhizy6SSwXT0H+TQdE3kkfuCYHH7P9pShlPR5R5nyXRg/BZdA0tjPiD3CES5xnrc4tuiGBl/TpT4/t+RLPPzTgZSw3ayYXHzZMrLsoaMS5gpCK6TaJIc5OyS7oDNuDCRqPyJphQjISFG3kk+y2/Dnoy00TgAwJq5vaDBFiJwmpF/RQ3w9Dqb9PNNuCdhchCaPHnzOZqRvP82uQV2Nzv+0rBYAt3NQFAP0cZdXN+Td7kFvkrvFgaI3nkrxjilVnQPIUmywosmjcU1Rf+wN0hMSzJhOcOatef40vgM9MKUYQIRfaWpIPy4TTPs0LqPwPNIeSO8/TeS2VG0kmZAvlzEzH6AuXDTrEt1QmESD8w/iqrVDj8V9rZLKWDqBkV0TmGDgALyx/O7SLzdJLNU1ud5rbGGWZVty9tR5rQyAvZobraAA11w== HZQ@DESKTOP-PC28

4, I am sure I remove "START_SSH_SERVER = true" ,so it run with system ssh

5, every time I will manual delete authorized_keys and use Update the '.ssh/authorized_keys' on the gitea web ui for a new one

6, no more log I can find ,only gitea.log with a lot of sql, no valuable message

zeripath · 2019-12-24T09:12:00Z

What happens if you SSH directly without going through git? You should get told you have authenticated by Gitea does not provide a shell or thereabouts

zzps · 2019-12-24T09:16:09Z

What happens if you SSH directly without going through git? You should get told you have authenticated by Gitea does not provide a shell or thereabouts

ssh [email protected]
The authenticity of host '192.168.1.249 (192.168.1.249)' can't be established.
ECDSA key fingerprint is SHA256:tb7qobfbP/lYnboDAQIZ0WUIhfxNc63cnQkMesnG+9o.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.249' (ECDSA) to the list of known hosts.
PTY allocation request failed on channel 0
Connection to 192.168.1.249 closed.

zeripath · 2019-12-24T09:18:13Z

Well that's interesting.

From a command line on the server run:

/usr/local/gitea/gitea --config='/usr/local/gitea/custom/conf/app.ini' serv key-14

zzps · 2019-12-24T09:21:51Z

/usr/local/gitea/gitea --config='/usr/local/gitea/custom/conf/app.ini' serv key-14

/usr/local/gitea/gitea --config='/usr/local/gitea/custom/conf/app.ini' serv key-17
Hi there, zzps! You've successfully authenticated with the key named 本地pc, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.

zeripath · 2019-12-24T09:54:43Z

Did you deliberately change the key number? I'm going to assume that the key number still matches authorized keys.

So now the question comes as to why SSH can't run or it fails for that command.

There's an interesting bit where SSH states Pty allocation failed. Now that's weird because we explicitly say don't give a Pty in our authorized_keys

So I wonder, if you remove the no-pty from the authorised_keys line if that helps things. Did Gogs have that too?

Another thing is if your key having a non ASCII name if that is a cause of problems - it shouldn't be - but it might be worth a try to see if things work if you change it something like pi-key.

zzps · 2019-12-24T10:02:14Z

because I have change the key before run ,so that I should replace serv-14 to serv-17, and your command is serv-14 and I run serv-17,it doesn't matter.
abount the pty question , I can test it , I have environment

zeripath · 2019-12-24T10:26:04Z

Any progress on testing the pty things?

zeripath · 2019-12-24T10:27:02Z

You just need to remove the no-pty, from the authorized_keys and try SSHing again

zzps · 2019-12-24T10:43:49Z

after remove no-pty in the authorised_keys
it shows:
$ ssh [email protected]
Connection to 192.168.1.249 closed.

zzps · 2019-12-24T10:48:05Z

You just need to remove the no-pty, from the authorized_keys and try SSHing again

it still can not clone over ssh

zzps · 2019-12-24T11:09:02Z

You just need to remove the no-pty, from the authorized_keys and try SSHing again

I think I should show you a strange discovery, the gitea generate authorized_keys and the line
"/usr/local/gitea/gitea --config='/usr/local/gitea/custom/conf/app.ini' serv key-1" shows with red color .
and the gogs
generate authorized_keys and the line
"/usr/local/gogs/gogs serv key-3 --config='/usr/local/gogs/custom/conf/app.ini'" shows with white color .

!!!may be it is the clue!!!!!

zeripath · 2019-12-24T11:18:41Z

So for some reason it appears SSH cannot run the command. I guess check the permissions for everything? Is there a difference with gogs?

zzps · 2019-12-25T01:13:58Z

So for some reason it appears SSH cannot run the command. I guess check the permissions for everything? Is there a difference with gogs?

I have check everything permissions , no difference with gogs.

lunny · 2019-12-25T03:44:11Z

Have you tried run ssh -T [email protected] on your local machine?

zzps · 2019-12-25T03:51:51Z

Have you tried run ssh -T [email protected] on your local machine?

done that and no help . and I move the environment to machine :192.168.1.250, and do all the step as document, it still doesn't work !

Iced-Sun · 2020-02-01T16:10:50Z

Hi @zeripath, I am using the official binary gitea-1.10.0.

Per the doc at install-from-binary, I thought custom directory layout should work out-of-the-box.

Or am I missing anything?

zeripath · 2020-02-01T16:37:13Z

no you're not missing anything - just that if you were building from source you could simplify your codes to make everything a bit easier.

Anyway am I reading your comment correctly that you had to manually add a work-path to authorized_keys - if so that's a bug and we should fix that.

Iced-Sun · 2020-02-02T05:47:58Z

Yes, I have to manually add --work-path to .ssh/authorized_keys and all the git hooks ( pre-receive, update and post-receive).

stephenbmfj · 2020-02-09T14:05:27Z

I discovered yesterday that if the git user does not have a working shell (I had it set to /bin/true), I get the "Could not read from remote repository. Please make sure you have the correct access rights and the repository exists" error. I changed the git users's shell to /bin/sh, and everything started working. Might this be your problem?

stale · 2020-04-09T14:16:49Z

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

stale · 2020-04-25T09:03:44Z

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

zzps · 2020-05-08T07:20:07Z

after i add workpath it still clone fail over ssh!
why gogs work and gitea fail and they config all same!

zeripath · 2020-05-08T09:40:59Z

@zzps sorry we still haven't been able to work this out. Generally this is very easy.

Gogs may work simply because it doesn't attempt to communicate with the running Gogs server.

I still don't understand where things are failing for you.

There's something odd about your set-up that is breaking things - I also can't understand why people would ever need the work-path setting up either.

I'm going to take a look at the work-path now.

zeripath · 2020-05-08T10:01:15Z

I still can't work out why you would ever need to set the --work-path - except if your config option is incorrect...

None of this makes any sense.

zzps · 2020-05-08T10:11:59Z

I still can't work out why you would ever need to set the --work-path - except if your config option is incorrect...

None of this makes any sense.

maybe you chould check my compute , i could give you ip and account over secret channel

zeripath · 2020-05-08T10:13:32Z

you can message me on discord as @zeripath

zzps · 2020-05-08T10:34:29Z

you can message me on discord as @zeripath

how? email or?

Iced-Sun · 2020-05-10T08:07:58Z

after i add workpath it still clone fail over ssh!
why gogs work and gitea fail and they config all same!

Per the comment, I have to add --work-path to not only .ssh/authorized_key, but also all the hooks under each repository (*.git/hooks/{pre-receive,update,post-receive}).

FYI, @zeripath @zzps

zeripath · 2020-05-10T09:30:11Z

@sunbing81 - so I had a cursory look at this yesterday - I still can't work out why you need to do this.

I wonder if something is trying to create a directory. Do you have ROOT_PATH set in [log]?

zeripath · 2020-05-10T09:32:31Z

Ah... what do you have set for LFS_CONTENT_PATH in [server] ? Is it an absolute path?

Fix go-gitea#9481 (probably others too) Signed-off-by: Andrew Thornton <[email protected]>

Fix #9481 (probably others too) Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: Lauris BH <[email protected]>

Iced-Sun · 2020-05-11T06:23:06Z

@sunbing81 - so I had a cursory look at this yesterday - I still can't work out why you need to do this.

I wonder if something is trying to create a directory. Do you have ROOT_PATH set in [log]?

Yes, I have a ROOT_PATH=/var/log/gitea in [log]

Ah... what do you have set for LFS_CONTENT_PATH in [server] ? Is it an absolute path?

I have a LFS_CONTENT_PATH = ./data/lfs in [server].

zzps · 2020-05-11T08:11:43Z

you can message me on discord as @zeripath

could you give me an email address?

zeripath · 2020-05-11T09:36:06Z

@sunbing81 - so your problem should have been fixed by #11136
@zzps - Go to https://discord.gg/Gitea

Fix go-gitea#9481 (probably others too) Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: Lauris BH <[email protected]>

lunny added the type/question Issue needs no code to be fixed, only a description on how to fix it yourself. label Dec 24, 2019

stale bot added the issue/stale label Apr 9, 2020

stale bot closed this as completed Apr 25, 2020

zeripath reopened this Apr 29, 2020

stale bot removed the issue/stale label Apr 29, 2020

zeripath changed the title ~~can not clone repository over ssh , and it is work over http~~ Need to add --workpath to authorized_keys Apr 29, 2020

zeripath changed the title ~~Need to add --workpath to authorized_keys~~ Need to add --work-path to authorized_keys May 8, 2020

zeripath added a commit to zeripath/gitea that referenced this issue May 10, 2020

Move LFS directory creation out of NewContext

326f51a

Fix go-gitea#9481 (probably others too) Signed-off-by: Andrew Thornton <[email protected]>

zeripath mentioned this issue May 10, 2020

Fix hook failure due to relative LFS_CONTENT_PATH #11362

Merged

lafriks closed this as completed in #11362 May 10, 2020

lafriks added a commit that referenced this issue May 10, 2020

Move LFS directory creation out of NewContext (#11362)

f8e015e

Fix #9481 (probably others too) Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: Lauris BH <[email protected]>

go-gitea locked and limited conversation to collaborators Nov 24, 2020

Uh oh!

Need to add --work-path to authorized_keys #9481

Need to add --work-path to authorized_keys #9481

Comments

zzps commented Dec 24, 2019

Description

Screenshots

bagasme commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

lunny commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

lunny commented Dec 24, 2019

Uh oh!

zeripath commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

zeripath commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

zeripath commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

gitea public key

Uh oh!

zeripath commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

zeripath commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

zeripath commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

zeripath commented Dec 24, 2019

Uh oh!

zeripath commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019

Uh oh!

zzps commented Dec 24, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zeripath commented Dec 24, 2019

Uh oh!

zzps commented Dec 25, 2019

Uh oh!

lunny commented Dec 25, 2019

Uh oh!

zzps commented Dec 25, 2019

Uh oh!

Iced-Sun commented Feb 1, 2020

Uh oh!

zeripath commented Feb 1, 2020

Uh oh!

Iced-Sun commented Feb 2, 2020

Uh oh!

stephenbmfj commented Feb 9, 2020

Uh oh!

stale bot commented Apr 9, 2020

Uh oh!

stale bot commented Apr 25, 2020

Uh oh!

zzps commented May 8, 2020

zzps commented Dec 24, 2019 •

edited

Loading