-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permission denied error when starting Gitea after updating to 1.17.0 #20570
Comments
For the time being, I have reverted to 1.16.5, and it seems to run as expected. |
Set See the breaking changes notices in our blog post: https://blog.gitea.io/2022/07/gitea-1.17.0-is-released/#-internal-gitconfig-19732httpsgithubcomgo-giteagiteapull19732 Copied below: Internal Gitconfig (#19732)Previously, Gitea used the users gitconfig ( Now, Gitea uses the system gitconfig ( |
Thank you for the information. I've read the mentioned breaking change notices, and I haven't modified the gitconfig of the user that runs Gitea. On the other hand, maybe I misunderstand something, but why should I override the git home path? The current path is fine to me, and even more, I prefer it to be in the original location. The problem is that Gitea is unable to create this new directory, because it does not have permission to do so. I think this might be caused by Gitea trying to fix the permissions of its own directory, but does it wrongly, and it gets in its own way. |
The error you're receiving is stating it can't create what is the new default |
I understand, but is that expected behavior? Is this specific to the Docker environment? I'm asking because you have defined that path as the default for a reason. |
I changed nothing to any ssh configs but the 1.17 update still breaks my SSH. |
What is the output of |
|
The It defaults to Simply create the directory |
In my configuration file
I haven't customized the value of
As you may see, the permissions for the directory is only reading and execution for the
I don't have a
|
I installed gitea 1.70 using
When I set the |
I am receiving the same error. I have the following mount: - /home/git/.gitconfig:/data/gitea/home/.gitconfig and I have set the following env definitions GITEA__git__HOME_PATH=/data/gitea/home
USER_UID=116
USER_GID=123 and the file $ sudo -u git ls -ln /home/git/.gitconfig
-rw-rw-r-- 1 116 123 1 Aug 16 21:57 /home/git/.gitconfig however, when starting up the container, I receive this error: - error: could not lock config file /data/gitea/home/.gitconfig: Permission denied I understand that the user whose UID/GID is defined in the environment is the one performing the operations and, as stated in the |
I made a fresh install on 1.17, which worked for a while. But now it is having the exact same problem as before, with permission errors when it tries to read the SSH key despite its permissions being correct as we established while troubleshooting the issue on Discord. I think 1.17 is flawed |
@swang-harbin I don't know how to install Gitea that way, but some things I wanted to let you know:
This looks like a path specification problem. I'm not sure where did you set "Repository Root Path", but looking at the error message it looks the first
There is the [git]
HOME_PATH=/your/path/goes/here Other settings and other sections can be before and after this excerpt, and this section can also contain other settings, but I think you should only define the
I think that is a different error, but it might have some similarities. Does the git user have the UID of 116, or is it in the group of GID 123? |
@techknowlogick @zeripath I feel my issue is ignored. To recap what has happened so far: The reason I didn't accept the workaround to set a different directory for the git home directory, is that my Gitea instance uses the default storage path configurations, and yet it mismanages the directory where it stores all its data. |
@mpeter50 First of all,thanks for your reply. And the access permissions of the /var/lib/gitea directory are:
And systemd unit file copied from here I found instructions for [git].HOME here, but it still gives the same error after I configure At the same time, after I set Environment to |
Could you run |
There are many different voices here and some are caused by different problems. IMO most of the problems are not related to Gitea itself, but related to the environment. I will provide a summary for various "permission" problems:
In short, in most cases permission problems are related to the environment, understand your environment and tune the permissions carefully (maybe in the future Gitea can provide a tool to help to check the environment) If you believe there is a bug, please report: What's the username and uid are for Gitea process, what are the filesystem permissions(owner/mod) for the Gitea's custom/data and related directories/files. If you are running Gitea with docker, please collect these information inside the docker container. |
If you see Or, you could try to use another directory for Gitea, eg: |
@lunny
|
@wxiaoguang
It can launch the configuration page.I use its default repository root path:
I think this error may be because I installed using snap, maybe I should use docker. |
Looks like your current user have no write permissions to the log directory. |
Do you say this to me or to swang-harbin? If to me, is it ok to try that in my Gitea 1.16.5 container, or should I use the 1.17.0 container to execute this command?
I have ran the following commands inside the Gitea container, while it is running with version 1.16.5:
ps cannot print the UID of processes as it seems the busybox of the container has a minimal version of it, so I used stat instead.
I currently don't have any program that manages backups or similar tasks.
I do, but it is only involved in starting the Docker daemon. The containers are managed by docker-compose.
Do you mean that both of the mentioned commands need to be run in the container?
Thanks for letting me know, the ownership of that directory was weird to me too, but didn't know what it should be. I'll let it alone for now, as I don't use it, and I think that feature has been removed from 1.17 anyway.
In my opinion I have already tried to tune the permissions carefully, but my tunings were reverted as soon as I started the Gitea container.
I have included these near the top of this comment, in my response to your first and second points. |
@mpeter50 This issue has became very long, I am not sure whether your problem has been resolved. My first thought about your original problem is that the Maybe you could do |
What are reverted? If you mean that you can not make the |
Whilst the error message is very unfriendly and should be fixed, you should read it and then think a bit more instead of throwing your hands up. What is the problem?The doctor command is panicking with What does that mean?The doctor command cannot write to doctor.log in its current directory How can this be solved?
Can the doctor command change where it logs?Look at the help sheet for the command online or by running: $ gitea doctor --help What does that say?
So how can I change the log file location?Add the gitea doctor --log-file "-" --all |
I agree, multiple people have been replying with different problems. My issue has not been resolved, I'm still running 1.16.5, and I would like to update to 1.17.
Yes, I understand that.
I meant this, yes. The permissions of the |
If you mean this feature of Docker, I have been using it for something else earlier, but currently it is disabled. To make sure that this is how it is actually, inside the container I see the same UIDs as the owner of the custom, git and ssh directories, as I see outside of the container, looking at my docker volumes: Inside the container:
On the host system:
The relevant volume mapping in the docker-compose file:
|
It really depends a lot of facts. Docker has root and rootless version. There doesn't seem to be an official document for it, I just searched and tried by myself before. So, the following information may not be accurate, just for your information. For docker-with-root, the UID/GID/mode are stored with the file on the file system. I guess you are using the docker-with-root image. For docker-rootless, the UID/GID/mode are stored with xattr or NTFS extended attribute. Docker for Windows has more complex behaviors, depending on which backend is used (WSL2 or not), it's off-topic for this problem. In my environment, the directories looks like this:
Then the question is, why your I think there could be some tests to try (if you have time ...)
|
If permissions are incorrect for writing to the doctor log simply disable the log file instead of panicing. Related go-gitea#20570 Signed-off-by: Andrew Thornton <art27@cantab.net>
@wxiaoguang thanks, I'll try these tests soon. |
Oh, one question. I should do the with-Gitea parts of the test with the 1.17 image, right? |
You could try it with 1.16.x first to see whether the behavior differs, in case it's a regression bug for 1.17? 😂 If you only has 1.17 database, only 1.17 is also fine, at least we can know the problem |
@mpeter50 regarding to the question you asked me, yes, cut -d ':' -f1-4 /etc/passwd | grep git
git:x:116:123 |
* Disable doctor logging on panic If permissions are incorrect for writing to the doctor log simply disable the log file instead of panicing. Related #20570 Signed-off-by: Andrew Thornton <art27@cantab.net> * Update cmd/doctor.go * Update cmd/doctor.go Co-authored-by: delvh <dev.lh@web.de> Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: delvh <dev.lh@web.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
The tests are done, here are the results. Docker bug testFirst I checked if just mounting to a docker container changes the permissions.
I started the container with this command:
( Checked the permissions inside too, and stopped the container:
Checked the permissions outside again:
Gitea bug testOut of curiosity first I tried with the current container (1.16.5). I checked if the permissions are still ok, before starting the container:
I started the container with docker-compose (if you're interested in the compose file, please let me know):
After the database and Gitea has finished starting up (~1 minute), I checked the permissions again:
The permissions have changed. I also checked inside the container:
I also checked this again with 1.17.0.
I changed the container image to start, and started the container:
When Gitea has started to start up and printed its first error messages, the permissions were changed again:
ConclusionThe strange behavior is connected to the Gitea container, but it looks it hasn't been introduced with 1.17.0, as the 1.16.5 container does this too. |
search all codebase with |
In most cases, Gitea uses 0o777 + umask for the mode. @mpeter50 Have you ever set some I can reproduce the behavior by: func main() {
syscall.Umask(0o277)
os.MkdirAll("/tmp/test-dir/test", os.ModePerm) // or 0o755, etc
}
// then you will get:
// dr-x------ 2 uid gid 64 Aug 19 16:10 test-dir/ Maybe you are using umask = 277 , if you are using a mount point, check the mount's arguments and make it 022 and take a look at it if there are other arguments affecting the modes. |
On the host OS I have the umask set to 022:
The container has this too: (for being able to execute this command, I started 1.16.5)
The directory where I store the data files of Gitea is stored on the root partition, and according to Otherwise I don't remember touching the umask setting on this system. |
Thank you for your time, I think I know the problem now. I found this: https://github.com/go-gitea/gitea/blob/main/docker/rootless/usr/local/bin/docker-setup.sh#L8
😂 |
I proposed a PR for it: But I haven't fully understand the problem at the moment. |
Backport go-gitea#20847 If permissions are incorrect for writing to the doctor log simply disable the log file instead of panicing. Related go-gitea#20570 Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: delvh <dev.lh@web.de>
* Disable doctor logging on panic If permissions are incorrect for writing to the doctor log simply disable the log file instead of panicing. Related go-gitea#20570 Signed-off-by: Andrew Thornton <art27@cantab.net> * Update cmd/doctor.go * Update cmd/doctor.go Co-authored-by: delvh <dev.lh@web.de> Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: delvh <dev.lh@web.de> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Today I updated my instance to version 1.17.2, and everything seems fine. |
Description
I have updated to Gitea 1.17.0, but when starting it I receive an error in the console, and then it exits. The message is available in the first file of my log gist.
In the docker compose file I have 2 volumes defined for use directly by Gitea:
/mnt/gitea/data/
-/var/lib/gitea
/mnt/gitea/custom
-/etc/gitea
Gitea should run under user 1000, as set up in the docker compose file:
According to the console log, Gitea tries to create the
/var/lib/gitea/custom/home
directory, which is mapped to/mnt/gitea/data/custom/home
on the host system.After inspecting this latter path, I see that no one is granted write permissions on the
custom
directory in it:However, if I grant write permission to the owner with
sudo chmod u+w custom
, Gitea will still produce the same error on startup, then exit, and when exited, the write permission on the directory have disappeared.I suspect that Gitea is unable to create the new
home
directory because it removes the write permission from it's parent directory, but I also suspect that I might be doing something wrong, as no one else has reported this bug yet.If I try to fix this problem by hand, by manually creating the directory and setting ownership, as seen here:
then starting up Gitea can continue a little, but will exit again because it wants yet another directory besides the new
home
one. The output from this run is in the second file in my log gist.Gitea Version
v1.17.0
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
https://gist.github.com/mpeter50/c7ba7eb7fc5e74fd708736736800a4e6
Screenshots
No response
Git Version
2.36.2
Operating System
Raspbian
How are you running Gitea?
I'm running Gitea in Docker, for which I have built the container image myself, using the Docker.rootless DOckerfile in the repo.
Database
MySQL
The text was updated successfully, but these errors were encountered: