failed to write new configuration file /data/git/.gitconfig.lock

[dbabits]

same issue as #1728, #1624 and some others.

ln: ./log/log: Operation not permitted
ln: ./data/data: Operation not permitted
ln: /home/git/git: Operation not permitted

2016/12/10 02:51:02 [T] Custom path: /data/gogs
2016/12/10 02:51:02 [T] Log path: /app/gogs/log
2016/12/10 02:51:02 [I] Gogs: Go Git Service 0.9.99.0915
2016/12/10 02:51:02 [I] Build Time: 2016-09-16 12:10:31 UTC
2016/12/10 02:51:02 [I] Build Git Hash:
2016/12/10 02:51:02 [I] Log Mode: File(Info)
2016/12/10 02:51:02 [I] Cache Service Enabled
2016/12/10 02:51:02 [I] Session Service Enabled
2016/12/10 02:51:02 [I] Mail Service Enabled
2016/12/10 02:51:02 [I] Git Version: 2.6.6
2016/12/10 02:51:03 [.../gogs/models/repo.go:146 NewRepoContext()] [E] Fail to execute 'git config --global core.quotepath false': error: failed to write new configuration file /data/git/.gitconfig.lock

bash-4.3# ls -al /data
total 484
drwxrwxrwx    5 git      git          32768 Dec  9 02:54 .
drwxr-xr-x    1 root     root          4096 Dec 10 02:44 ..
drwxrwxrwx    4 git      git          32768 Dec 10 02:54 git
drwxrwxrwx    5 git      git          32768 Nov 13 03:06 gogs
-rwx------    1 git      git         339968 Dec  4 03:39 gogs.db
drwxrwxrwx    2 git      git          32768 Nov 13 03:07 ssh

gogs running in docker like this:

docker run -ti -d --name=gogs -p 10022:22 -p 10080:3000 -v /mnt/usb1/data_gogs:/data gogs/gogs-rpi

It seems that the file is being created and immediately deleted by the running gogs process:

bash-4.3# ls -l /data/git/.gitconfig.lock
-rwx------    1 git      git              0 Dec 10 03:24 /data/git/.gitconfig.lock
bash-4.3# ls -l /data/git/.gitconfig.lock
ls: /data/git/.gitconfig.lock: No such file or directory

Update. Gogs seems to have entered an infinite loop with git config process constantly being spawned :

bash-4.3# ps -ef
PID   USER     TIME   COMMAND
    1 root       0:00 /bin/s6-svscan /app/gogs/docker/s6/
   20 root       0:00 s6-supervise openssh
   21 root       0:00 s6-supervise syslogd
   22 root       0:00 s6-supervise crond
   23 root       0:06 s6-supervise gogs
   24 root       0:00 /sbin/syslogd -nS -O-
   26 root       0:00 /usr/sbin/sshd -D -f /app/gogs/docker/sshd_config
 1901 root       0:00 bash
28172 git        0:00 /app/gogs/gogs web
28191 git        0:00 git config --global core.quotepath false

[Mic92]

it fails to already writes to this directory (/app/gogs): https://github.com/gogits/gogs/blob/master/docker/s6/gogs/setup#L13

/app/gogs should be writeable by git user

[dbabits]

It is.
Please see my description of the problem:
"It seems that the file is being created..."

[Mic92]

Of course it is restarted in a loop, because s6 tries to constantly restart it. You showed the permissions for /data not for /app/gogs

[unknwon]

I think this is permission problem other than bug of Gogs... not sure if you've tried solution in #1728 (comment) but I'm going to close this issue.

[dbabits]

I do not think it's a permission issue because all directories are on a FAT32 partition, where there are no permissions. Anyway, I could not try and paste more output because something else happened and that Rpi is broken now. Could you keep the issue open until I have a chance? Thanks. On Dec 22, 2016 5:17 AM, "无闻" <notifications@github.com> wrote: I think this is permission problem other than bug of Gogs... not sure if you've tried solution in #1728 (comment) <#1728 (comment)> but I'm going to close this issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3944 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACX3nhpdxCOClNvXg5Hy2x-C6gICxuhRks5rKk5LgaJpZM4LJiXf> .

[Mic92]

@dbabits Of course fat32 has permissions. It does not have ownership though, but the owner is fixed by mount options. In this case gogs probably run not as root, but as a unprivileged, while your mount is owned by root.

[dbabits]

The mount is owned by unpriviledged, set in fstab. Gogs runs (ran) as root, inside docker container. The important thing is this setup worked. Until it stopped. I suspect corruption of that fat32 partition that probably happened when that Rpi lost power. It's a speculation at this point, as I could still read files from that partition. I will rebuild and retry and let know. Perhaps Fat32 is not the best choice, but I had a req to also be able to mount that drive on my android phone, which left Fat32 as the only choice. El 23 dic. 2016 8:23 AM, "Jörg Thalheim" <notifications@github.com> escribió: @dbabits <https://github.com/dbabits> Of course fat32 has permissions. It does not have ownership though, but the owner is fixed by mount options. In this case gogs probably run not as root, but as a unprivileged, while your mount is owned by root. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3944 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACX3nux58JmMO7lWgEfrEvXK-STUg8Xsks5rK8tRgaJpZM4LJiXf> .

[prologic]

I'm running into this too in a Docker Swarm cluster; doesn't look like permission issues; all files/directories are owned by git(uid=1000;gid=1000).

Frustrating part if the error isn't showing the underlying error I don't think:

git_gogs.1.lztimofpzgy9@dm1.mills.io    | 2019/11/02 01:01:26 [FATAL] [.../internal/cmd/web.go:172 runWeb()] Fail to execute 'git config --global core.quotepath false': error: failed to write new configuration file /data/git/.gitconfig.lock

[prologic]

Over the weekend I tried to chown -R git:git data on my instance and I still end up with the same error. /data for me is a named docker local volume.

[unknwon]

Hi @prologic, I pushed a patch to print more error info about this case, the Docker image is currently building: https://cloud.docker.com/u/gogs/repository/registry-1.docker.io/gogs/gogs/builds/54c297da-dfc6-4248-8a52-4d237ce70bcc

[prologic]

Thanks! That should help the next poor soul that runs in to this :) In my case it was the disk had ran out of space :) -- But yeah without the underlying error being printed its really hard to tell!