Failed to collect changes, 'git fetch' command failed Unreadable pack index on Docker
Hi,
I met the issue while setup Team City from docker image.
Failed to collect changes, error: Error collecting changes for VCS repository ... 'git fetch' command failed (repository dir: <TeamCity data dir>/system/caches/git/git-4B5DD42A.git).
stderr: Failed to update 'refs/heads/master' (IO_FAILURE)
stdout: [2020-03-27 08:10:14,010] ERROR - l.storage.file.ObjectDirectory - Exception caught while accessing pack file /data/teamcity_server/datadir/system/caches/git/git-4B5DD42A.git/objects/pack/pack-38215679c9892147a83add1ddc8dae76e3bb76b8.pack, the pack file might be corrupt. Caught 1 consecutive errors while trying to read this pack. java.io.IOException: Unreadable pack index: /data/teamcity_server/datadir/system/caches/git/git-4B5DD42A.git/objects/pack/pack-38215679c9892147a83add1ddc8dae76e3bb76b8.idx at org.eclipse.jgit.internal.storage.file.PackIndex$PackIndexFactory.open(PackIndex.java:398) at org.eclipse.jgit....
I setup TC on docker image and maped volumes.
To learn more i checked logs and there there was entry:
Caused by: java.io.FileNotFoundException: /data/teamcity_server/datadir/system/caches/git/git-8F9F1F58.git/objects/pack/pack-944413b1a33e1810aadfd3190d8e5c0eb41abf7e.idx (Operation not permitted)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at org.eclipse.jgit.internal.storage.file.PackIndex$PackIndexFactory.open(PackIndex.java:395)
... 16 more
File of course were there but it was set to readonly.

Temporary fix was to set permisions to all files in /data/teamcity_server/datadir/system/caches/git/git-8F9F1F58.git/objects/pack/ to
chmod 777 *
But need to do it after each fetch because new idx and packs are set to readonly when created.
Using windows 10 as host for docker.
Image: jetbrains/teamcity-server latest c024daa169bf 4 weeks ago 1.8GB
Anyone have met this?
Please sign in to leave a comment.
I have faced to exactly same problem and fixed with using same workaround.
Hi both,
I have not seen this issue before or reported elsewhere, so I'd recommend double checking that the directories mapped from windows are not marked as read only before hand, nor blocked by something else.
I'll forward this to the dev of the docker subsystem to see if there is anything we can do on our end to avoid this scenario.