Error Pushing to Git

We recently updated GitLab to version 14.10.2. We see the following error when pushing to git,

Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 32 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 481 bytes | 240.00 KiB/s, done.
Total 5 (delta 4), reused 0 (delta 0), pack-reused 0
remote: Missing unknown 3ead6b526d8c560c20ea52ca3c561f7da85e5308
remote: Git object 3ead6b526d8c560c20ea52ca3c561f7da85e5308 can’t be accessed in the Git repository [/home/git-data/repositories/@hashed/12/53/1253e9373e781b7500266caa55150e08e210bc8cd8cc70d89985e3600155e860.git]
remote: 1) Git server is out of memory, available disk space,
remote: processes count, or open files limits;
remote: 2) When pushing through SSH, the system user on behalf of which.
remote: SubGit daemon is running is not allowed to read files created by SSH user.
remote: TO RECOVER:
remote: 1) Make sure Git server has enough memory, disk resources AND high enough
remote: open handler and processes count limits.
remote: 2) When pushing through SSH, either
remote: A) make sure the SSH user is the same user on behalf of which the SubGit is running
remote: AND
remote: is the same as the system user which is the owner of the Git repository; OR
remote: B) set ‘core.shared’ option to ‘true’ in SubGit configuration file, run
remote: to apply changes and make sure the owner of the Git repository and SSH user
remote: belong to the same system group.
remote: For details regarding sharing Git repository for a system group see:
remote: Once you have (1) and (2) fixed, retry push.
remote: TO REPORT:
remote: 1) Get error log from the server at
remote: path to home
remote: 2) Report an issue
remote: THANK YOU!
! [remote rejected] trunk → trunk (pre-receive hook declined)
error: failed to push some refs to ‘’

The Git server has memory and disk space, so we know this is not the issue.
Can you help?


thank you for reporting this issue.

May I ask you which GitLab version have you updated the server from and what is the version of SubGit that you are using? The issue looks pretty similar to SGT-1327 we resolved before, so if you are using SubGit earlier than v.3.3.12, I would recommend updating SubGit to at least this version or the latest version.
Also, here is a workaround that allows overcoming this issue:

  • in the custom_hooks directory in an affected repository remove or rename both fast-pre-receive and fast-post-receive hooks
  • edit the pre-receive hook adding the following line

right above this line:

 if [ -x "$C_HOOK" ] ; then

save the edited hook.

This change will allow SubGit to get all the needed information GitLab changes in v.14 and thus will resolve the issue. I will let you know as we release the new version that does not need such a workaround to be made.

Hello ildar,
Thank you for your prompt reply. I am please to confirm that you suggested workaround fixed the issue, so thank you for that.
You were also correct when you suggested we might be using SubGit earlier than v.3.3.12. Do you have any links to the upgrade procedure? The engineer who performed the original installation is no longer with the company.


great to know the cause is now known, thank you for confirmation.

I’m afraid that we don’t have a written procedure on the upgrade, just because the upgrade procedure does not require any special steps, it’s just upgrade of SubGit binaries and running mirrors restart. Thus, to upgrade SubGit first upgrade installed SubGit binaries following the steps for a particular operating system:

Installation - SubGit - TMate Docs

after that re-install SubGit in every mirrored repository:

subgit install REPO

REPO here stands for a particular mirrored repository path. The above command will shutdown running mirror, upgrade SubGit binaries in the repository and then start SubGit daemon again using the new binaries.