You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Log gist:
2019/08/05 09:50:47 ...uters/admin/users.go:255:DeleteUser() [E] DeleteUser: rename C:\Users\Administrator\.ssh\authorized_keys.tmp C:\Users\Administrator\.ssh\authorized_keys: The process cannot access the file because it is used by another process.
2019/08/05 09:50:47 ...s/context/context.go:137:HTML() [D] Template: status/500
[Macaron] 2019-08-05 09:50:47: Completed POST /admin/users/10/delete 500 Internal Server Error in 36.1925ms
Description
If you click on "Delete user", the upper error is thrown in the log. There is no hint in the user interface that something did not work. No SSH server is running on the computer and the internal SSH server is deactivated. Gitea is running with administrative privileges, so all access rights should be present.
The text was updated successfully, but these errors were encountered:
Ooh that's interesting - something is locking the authorized keys file. Two things come to mind: a) not being able to edit the authorized_keys file immediately should not cause everything to fail - so maybe we should just add a time delayed authorized keys goroutine. b) is it possible that Gitea has locked the authorized keys file itself?
How are you running SSH services? Are you even running SSH?
For a workaround whilst this is going on, if you need to delete the user you can tell Gitea not to use the authorized_keys file. Then you should be able to delete this user.
Given Windows locking behaviour - it might be that we have to recommend the use of the authorized keys command on doze.
I tried to find out if gitea locks the file "authorized_keys" itself but the process is too fast to check with the Windows resource monitor. Since I don't use a SSH server and use the values (DISABLE_SSH = true, START_SSH_SERVER = false) in the configuration, no other process should be responsible. Why is it actually tried to change the file "authorized_keys" if I have set "DISABLE_SSH = true" in the configuration?
[x]
):2019/08/05 09:50:47 ...uters/admin/users.go:255:DeleteUser() [E] DeleteUser: rename C:\Users\Administrator\.ssh\authorized_keys.tmp C:\Users\Administrator\.ssh\authorized_keys: The process cannot access the file because it is used by another process.
2019/08/05 09:50:47 ...s/context/context.go:137:HTML() [D] Template: status/500
[Macaron] 2019-08-05 09:50:47: Completed POST /admin/users/10/delete 500 Internal Server Error in 36.1925ms
Description
If you click on "Delete user", the upper error is thrown in the log. There is no hint in the user interface that something did not work. No SSH server is running on the computer and the internal SSH server is deactivated. Gitea is running with administrative privileges, so all access rights should be present.
The text was updated successfully, but these errors were encountered: