Gitlab произошла ошибка при получении содержимого папки

Я случайно напутал владельцев файлов (chown на неправильном уровне …) на моем собственном Gitlab, запущенном в контейнере Docker. Мне удалось восстановить большую часть собственности.

Это было сделано путем бега. Однако это не сразу устранило проблему, поскольку журналы по-прежнему показывали ошибку отказа в разрешении для grafana db. Чтобы исправить это, я продолжил настройку нового Gitlab и сравнил / восстановил право собственности.

Хотя сам Gitlab теперь снова работает, я все еще получаю следующие ошибки:

  1. Когда я пытаюсь толкнуть, я получаю:
      remote: GitLab: Push operation timed out
remote:
remote: Timing information for debugging purposes:
remote: Running checks for ref: XXXX
remote: Checking if you are allowed to push... (62.94ms)
remote: Checking if default branch is being deleted... (0.31ms)
remote: Scanning repository for blobs stored in LFS and verifying their files have been uploaded to GitLab... (cancelled after 29547.57ms)
To http://gitlab.XXXX.XX/XXXX/XXXX.git
 ! [remote rejected]   XXXXX -> XXXX (pre-receive hook declined)
error: failed to push some refs to 'http://gitlab.XXXX.XX/XXXX/XXXX.git'
  1. Когда я нажимаю на проект в веб-интерфейсе, он показывает такую ​​информацию, как ветки, общий размер файла и т. Д., Но не сам список файлов / файлов. Скорее
    отображается.

Бег
при попытке нажать показывает следующее:

      {"level":"info","msg":"I, [2021-07-05T17:13:19.676164 #3372254]  INFO -- sentry: ** [Raven] Raven 3.0.4 configured not to capture errors: DSN not set","supervisor.args":["bundle","exec","bin/ruby-cd","/var/opt/gitlab/gitaly","/opt/gitlab/embedded/service/gitaly-ruby/bin/gitaly-ruby","3368488","/var/opt/gitlab/gitaly/internal_sockets/ruby.0"],"supervisor.name":"gitaly-ruby.0","time":"2021-07-05T17:13:19.692Z"}
{"error":"exit status 1","level":"warning","msg":"exited","supervisor.args":["bundle","exec","bin/ruby-cd","/var/opt/gitlab/gitaly","/opt/gitlab/embedded/service/gitaly-ruby/bin/gitaly-ruby","3368488","/var/opt/gitlab/gitaly/internal_sockets/ruby.0"],"supervisor.name":"gitaly-ruby.0","time":"2021-07-05T17:13:19.698Z"}
{"level":"info","msg":"I, [2021-07-05T17:13:20.817759 #3372257]  INFO -- sentry: ** [Raven] Raven 3.0.4 configured not to capture errors: DSN not set","supervisor.args":["bundle","exec","bin/ruby-cd","/var/opt/gitlab/gitaly","/opt/gitlab/embedded/service/gitaly-ruby/bin/gitaly-ruby","3368488","/var/opt/gitlab/gitaly/internal_sockets/ruby.1"],"supervisor.name":"gitaly-ruby.1","time":"2021-07-05T17:13:20.835Z"}
{"error":"exit status 1","level":"warning","msg":"exited","supervisor.args":["bundle","exec","bin/ruby-cd","/var/opt/gitlab/gitaly","/opt/gitlab/embedded/service/gitaly-ruby/bin/gitaly-ruby","3368488","/var/opt/gitlab/gitaly/internal_sockets/ruby.1"],"supervisor.name":"gitaly-ruby.1","time":"2021-07-05T17:13:20.843Z"}
[...]
{"correlation_id":"01F9VTFEM5X7N2PZR6WVDAQQYN","error":"GitLab: Push operation timed outnnTiming information for debugging purposes:nRunning checks for ref: XXXXnChecking if you are allowed to push... (13.42ms)nChecking if default branch is being deleted... (0.43ms)nScanning repository for blobs stored in LFS and verifying their files have been uploaded to GitLab... (cancelled after 29583.1ms)","grpc.meta.deadline_type":"none","grpc.method":"PreReceiveHook","grpc.request.fullMethod":"/gitaly.HookService/PreReceiveHook","grpc.request.glProjectPath":"XXXX/XXXX","grpc.request.glRepository":"project-5","grpc.request.repoPath":"@hashed/ef/2d/ef2d127de37b942baad06145e54b0c619a1f22327b2ebbcfbec78f5564afe39d.git","grpc.request.repoStorage":"default","grpc.request.topLevelGroup":"@hashed","grpc.service":"gitaly.HookService","grpc.start_time":"2021-07-05T17:11:59.178Z","level":"warning","msg":"stopping transaction because pre-receive hook failed","peer.address":"@","pid":3368488,"span.kind":"server","system":"grpc","time":"2021-07-05T17:12:29.025Z"}

Кто-нибудь знает, как исправить эту проблему?

РЕДАКТИРОВАТЬ: я добавил информацию о
как обсуждалось в комментариях.

Когда я пытаюсь нажать на общий пульт git, я получаю следующую ошибку:
insufficient permission for adding an object to repository database

Затем я прочитал об исправлении здесь: Fix Это сработало для следующего нажатия, поскольку все файлы были правильной группы, но в следующий раз, когда кто-то подтолкнул изменение, он сделал новый элемент в папке объектов, в которой группа по умолчанию была группой. Единственное, что я могу придумать, это изменить всю группу разработчиков по умолчанию для элементов, которые они проверяют, но это похоже на взлома. Есть идеи? Спасибо.

4b9b3361

Ответ 1

Разрешения на ремонт

После того, как вы определили и устранили основную причину (см. Ниже), вы захотите восстановить разрешения:

cd /path/to/repo.git
sudo chgrp -R groupname .
sudo chmod -R g+rwX .
find . -type d -exec chmod g+s '{}' +

Обратите внимание: если вы хотите, чтобы все могли изменять репозиторий, вам не нужен chgrp и вы захотите изменить chmod на sudo chmod -R a+rwX.

Если вы не исправите основную причину, ошибка продолжит возвращаться, и вам придется снова и снова повторять -R отмену вышеуказанных команд.

Основные причины

Ошибка может быть вызвана одним из следующих:

  • Репозиторий не настроен для использования в качестве общего репозитория (см. core.sharedRepository в git help config). Если на выходе:

    git config core.sharedRepository
    

    не является group или true или 1 или какой-то маской, попробуйте выполнить:

    git config core.sharedRepository group
    

    а затем повторно -R un рекурсивные chmod и chgrp (см. «Разрешения на восстановление» выше).

  • Операционная система не интерпретирует бит setgid для каталогов, поскольку «все новые файлы и подкаталоги должны наследовать владельца группы».

    Когда core.sharedRepository имеет значение true или group, Git использует функцию операционных систем GNU (например, каждый дистрибутив Linux), чтобы гарантировать, что вновь созданные подкаталоги принадлежат правильной группе (группе, в которой находятся все пользователи репозитория). Эта функция описана в документации GNU coreutils:

    … [Если] установлен бит set-group-ID каталога, вновь созданные подфайлы наследуют ту же группу, что и каталог, а вновь созданные подкаталоги наследуют бит set-group-ID родительского каталога…. [Этот механизм позволяет] пользователям легче обмениваться файлами, уменьшая необходимость использовать chmod или chown для обмена новыми файлами.

    Однако не все операционные системы имеют эту функцию (NetBSD является одним из примеров). Для этих операционных систем вы должны убедиться, что все ваши пользователи Git имеют одинаковую группу по умолчанию. В качестве альтернативы, вы можете сделать хранилище доступным для записи в мире, запустив git config core.sharedRepository world (но будьте осторожны — это менее безопасно).

  • Файловая система не поддерживает бит setgid (например, FAT). ext2, ext3, ext4 все поддерживают бит setgid. Насколько я знаю, файловые системы, которые не поддерживают бит setgid, также не поддерживают концепцию владения группой, поэтому все файлы и каталоги в любом случае будут принадлежать одной и той же группе (какая группа является опцией монтирования). В этом случае убедитесь, что все пользователи Git входят в группу, которой принадлежат все файлы в файловой системе.
  • Не все пользователи Git находятся в одной группе, которая владеет каталогами репозитория. Убедитесь, что владелец группы в каталогах указан правильно и что все пользователи находятся в этой группе.

Ответ 2

Для Ubuntu (или любого Linux)

Из корня проекта

cd .git/objects
ls -al
sudo chown -R yourname:yourgroup *

Вы можете указать, что должно быть у вашего имени и вашей группы, посмотрев разрешения на большую часть вывода из этой команды ls -al

Примечание: помните звезду в конце строки sudo

Ответ 3

sudo chmod -R ug+w .;

В принципе, файл .git/objects не имеет разрешений на запись. Вышеупомянутая строка предоставляет разрешение всем файлам и папкам в каталоге.

Ответ 4

используйте следующую команду, работает как magic

sudo chown -R "${USER:-$(id -un)}" .

введите команду точно так, как она есть (с дополнительными пробелами и одной точкой в ​​конце)

Ответ 5

Я просто хотел добавить свое решение. У меня было репо на OS X, у которого было право на root в некоторых каталогах и Home (это мой каталог пользователей) на других, которые вызвали ту же ошибку, что и выше.

Решение было просто благодарно. От терминала:

sudo chown -R Home projectdirectory

Ответ 6

Хороший способ отладки — это в следующий раз, когда это произойдет, SSH в удаленное репо, cd в папку с объектами и выполните ls -al.

Если вы видите 2-3 файла с разными правами пользователя: группа, то это проблема.

В прошлом мне случалось, что некоторые устаревшие скрипты обращались к нашему репозиторию git и обычно означает, что другой (unix) пользователь вставлял/модифицировал файлы последним, и у вашего пользователя нет разрешений на перезапись этих файлов. Вы должны создать общую группу git, в которой находятся все git -enabled пользователи, а затем рекурсивно chgrp папка objects, и это содержимое, так что это групповое владение является общей группой git.

Вы также должны добавить липкий бит в папку, чтобы все файлы, созданные в папке, всегда имели группу git.

chmod g + s имя-каталога

Обновление: я не знал о core.sharedRepository. Полезно знать, хотя он, вероятно, просто делает это.

Ответ 7

Решенный для меня…
только это:

sudo chmod 777 -R .git/objects

Ответ 8

Это может произойти, если вы запустили git init с другим пользователем из того, который вы планируете использовать при нажатии изменений.

Если вы слепо следуете инструкциям в [1], это произойдет, поскольку вы, вероятно, создали git -user как root, а затем сразу же перешли к git init без изменения пользователя между ними.

[1] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server

Ответ 9

После того, как вы добавите некоторые вещи… зафиксируйте их и после того, как закончите, нажмите на них! BANG !! Начните все проблемы… Как вы должны заметить, существуют некоторые различия в способах определения как новых, так и существующих проектов. Если какой-то другой человек попытается добавить/зафиксировать/отправить те же файлы или содержимое (git сохранит оба одинаковых объекта), мы столкнемся со следующей ошибкой:

$ git push
Counting objects: 31, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (17/17), done.
Writing objects: 100% (21/21), 2.07 KiB | 0 bytes/s, done.
Total 21 (delta 12), reused 0 (delta 0)
remote: error: insufficient permission for adding an object to repository database ./objects  remote: fatal: failed to write object

Чтобы решить эту проблему, вы должны иметь в виду систему разрешений операционной системы, поскольку в этом случае вы ограничены ею. Чтобы лучше понять проблему, проверьте папку с объектами git (.git/objects). Вы, вероятно, увидите что-то подобное:

<your user_name>@<the machine name> objects]$ ls -la
total 200
drwxr-xr-x 25 <your user_name> <group_name> 2048 Feb 10 09:28 .
drwxr-xr-x  3 <his user_name> <group_name> 1024 Feb  3 15:06 ..
drwxr-xr-x  2 <his user_name> <group_name> 1024 Jan 31 13:39 02
drwxr-xr-x  2 <his user_name> <group_name> 1024 Feb  3 13:24 08

* Обратите внимание, что эти права доступа к файлам были предоставлены только вашим пользователям, никто никогда не сможет их изменить… *

Level       u   g   o
Permission rwx r-x ---
Binary     111 101 000
Octal       7   5   0

РЕШЕНИЕ ПРОБЛЕМЫ

Если у вас есть разрешение суперпользователя, вы можете перейти вперед и изменить все разрешения самостоятельно, выполнив второй шаг. В любом другом случае вам нужно будет спросить всех пользователей, объекты которых созданы с их пользователями, используйте следующую команду, чтобы узнать, кто они:

$ ls -la | awk '{print $3}' | sort -u 
<your user_name>
<his user_name>

Теперь вам и всем пользователям-владельцам файлов придется изменить разрешение на эти файлы, выполнив:

$ chmod -R 774 .

После этого вам нужно будет добавить новое свойство, которое эквивалентно —shared = group, для нового репозитория, в соответствии с документацией, это сделает репозиторий доступным для записи в группу, выполнив его:

$ git config core.sharedRepository group

https://coderwall.com/p/8b3ksg

Ответ 10

Linux, macOS:

cd .git/
sudo chown -R name:group *

где name — ваше имя пользователя, а group — это группа, к которой принадлежит ваше имя пользователя.

Ответ 11

В моем случае ни один из предложений не работал. Я нахожусь в Windows, и это сработало для меня:

  • Копирование удаленного репо в другую папку
  • Разделите папку и укажите соответствующие разрешения.
  • Убедитесь, что вы можете получить доступ к папке с локальной машины.
  • Добавьте это репо в качестве другого удаленного репо в вашем локальном репо. (git remote add foo //SERVERNAME/path/to/copied/git)
  • Нажмите на foo. git push foo master. Это сработало? Большой! Теперь удалите нерабочее репо и переименуйте его во все, что было раньше. Удостоверьтесь, что права и свойство share остаются прежними.

Ответ 12

Я попал в эту же проблему. Прочитав здесь, я понял, что это права на файлы, на которые ссылалось сообщение. Исправление для меня было:

/etc/inetd.d/git -gpv

Он начинал с git -demon как пользователь ‘ nobody, поэтому не было права на запись.

# Who   When    What
# GPV   20Nov13 Created this by hand while reading: http://linuxclues.blogspot.co.uk/2013/06>/git-daemon-ssh-create-repository-debian.html
# GPV   20Nov13 Changed owner (to user_git) otherise nobody lack permission to update the repository
#git stream tcp nowait nobody  /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo
git stream tcp nowait user_git  /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo

(Я сомневаюсь, что другие вызовут их inetd conf файл git -gpv. Обычно это было бы непосредственно в/etc/inetd.conf)

Ответ 13

Вам нужны достаточные права на запись в каталоге, на который вы нажимаете.

В моем случае: сервер Windows 2008

щелкните правой кнопкой мыши каталог git repo или родительский каталог.

Свойствa > вкладка «Общий доступ» > «Расширенный доступ» > «Разрешения» > убедитесь, что у пользователя есть соответствующие права доступа.

Ответ 14

Возможно, вы случайно вложили git-репозитории

Ответ 15

выполните следующую команду для .git:

chmod -R 777 .git

Ответ 16

Также возможно, что вы добавили другой локальный репозиторий с тем же псевдонимом. Например, теперь у вас есть 2 локальные папки, называемые origin поэтому при попытке отправки удаленный репозиторий не примет ваши учетные данные.

Переименуйте псевдонимы локального репозитория, вы можете перейти по этой ссылке fooobar.com/questions/18602/…

Возможно, вы можете оставить 1 локальный репозиторий по своему вкусу как origin а другие переименовать их, например, из origin в anotherorigin. Помните, что это просто псевдонимы, и все, что вам нужно сделать, это запомнить новые псевдонимы и их соответствующие удаленные ветки.

Ответ 17

Я получаю эту ошибку при попытке проталкивания через среду IDE (в данном случае PHPStorm).
Когда я пытался использовать терминал (OSX), он работает! Таким образом, это явно проблема разрешения.
Хотя я не могу найти, как навсегда исправить его, используя

$ sudo git push origin master

выполнит трюк

Ответ 18

Работает для меня

sudo chmod -R g+rwX .

Ответ 19

Я получил это при подключении к проекту Rstudio. Я понял, что забыл сделать:

sudo rstudio

при запуске программы. На самом деле, поскольку у меня есть еще одна ошибка, мне нужно сделать:

sudo rstudio --no-sandbox

По умолчанию вы не можете вносить изменения в выделенную ветку репозитория. Это обычно вызывает серьезные проблемы! Вот что обычно происходит:

$ git push heroku master
...error messages...
To heroku
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'heroku'

Поскольку вы не указали никаких сообщений об ошибках, я предполагаю, что вы добавили следующее в heroku репозитория heroku, или вы используете довольно старую версию Git:

[receive]
        denyCurrentBranch = false

Похоже, вы хотите проверить свежую копию ведущей ветки всякий раз, когда вы нажимаете новую версию в свой репозиторий heroku. Это может быть достигнуто с помощью крюка после приема. Создайте файл в репозитории heroku .git/hooks/post-receive и дайте ему +x разрешения.

#!/bin/sh
while read oldrev newrev refname
do
    if test "$refname" = refs/heads/master
    then
        ( cd ..; GIT_DIR=.git; git reset --hard )
    fi
done

Теперь, всякий раз, когда вы нажимаете новую ветку master на heroku, крючок запускается и проверяет новую ветку. Есть лучшие способы сделать такие вещи, но это просто.

Резюме. По умолчанию при нажатии изменений изменяется только история, но не рабочее дерево. Предполагается, что кто-то может работать над этим деревом, поэтому делать что-либо с ним может быть разрушительным.

Добрый день! Установил себе расширение для yii2 — yii2-user. Добавил его в composer.json, затем сделал composer update, все поставилось. Но когда я захотел заккоминить изменения я обнаружил, что git добавил папку vendor/dektrium/yii2-user, а файлы внутри этой папки нет, так как не видит их. Смотрел в .gitignore, про эту папку там ничего нет. Расширение добавилось вроде не как субмодуль, в чем может быть причина?


  • Вопрос задан

    более трёх лет назад

  • 3378 просмотров

The «src» folder in one of my repository is grayed out (and is not clickable):

screenshot

I took the following steps before pushing to the GitHub:

  1. I created a new repository on GitHub.
  2. I initialize dthe git on my project.
  3. git add .
  4. git commit -m "comment"
  5. git remote add origin url
  6. git push -u origin master
  7. username
  8. password

The «src» folder is showing up on GitHub but cannot be opened. What can I do?

jub0bs's user avatar

jub0bs

59.9k25 gold badges181 silver badges183 bronze badges

asked Feb 7, 2015 at 16:24

Anushka's user avatar

4

I solved the problem by deleting .git folder inside subfolders (Hidden files and folders). You should have only one .git in the root folder.

Git recognized that folder as modified but untracked content.
There are other solutions for this problem, look this thread: Git — how to track untracked content?

answered Oct 8, 2015 at 10:12

Ivan Aracki's user avatar

Ivan ArackiIvan Aracki

4,73111 gold badges58 silver badges70 bronze badges

3

There are two possible reasons to this

  1. You have a git folder within a git folder i.e. your src folder is a git folder itself. To fix that simply delete the .git folder within the src and
git add <foldername>
git commit -m "commit msg"
git push origin master

Incase if it still doesn’t get fixed then, there maybe the problem because of cache. To fix that simple type

git rm --cached <foldername>

and repeat the above steps again. Your problem should get fixed.

answered Apr 30, 2020 at 13:24

Tanishq Vyas's user avatar

Tanishq VyasTanishq Vyas

1,3401 gold badge12 silver badges24 bronze badges

1

After you added a local folder:

  1. Remove .git folder inside of untracked submodule.
  • Powershell: Remove-Item -Recurse -Force ..git
  • Linux Terminal: rm -rf ./.git
  1. Run git rm --cached . -rf inside the submodule, which was the key for me.
  2. git add . in parent or root folder and you are good to go.

answered Sep 7, 2021 at 9:28

Giorgi Gvimradze's user avatar

Giorgi GvimradzeGiorgi Gvimradze

1,6111 gold badge16 silver badges34 bronze badges

The icon mean that you have marked this folder as submodule.
open your .gitmodules and you will see there the folder named as src bin.

Remove them from your submodule and it will become a regular folder

What is this grey git icon?

Community's user avatar

answered Feb 7, 2015 at 18:31

CodeWizard's user avatar

CodeWizardCodeWizard

126k21 gold badges141 silver badges163 bronze badges

I tried everything from above and nothing seemed to work in my case so I just renamed the trouble folder in something else then Github recognized it for some reason when I pushed the changes.

answered Dec 2, 2019 at 15:36

Terchila Marian's user avatar

Terchila MarianTerchila Marian

2,2053 gold badges24 silver badges47 bronze badges

If you clone the project you will find, that these folders are in fact empty:

​$ ls -la bin
total 0
drwxr-xr-x+ 2 fabiopoloni  staff   68  8 Okt 12:18 .
drwxr-xr-x+ 8 fabiopoloni  staff  272  8 Okt 12:18 ..

​$ ls -la src
total 0
drwxr-xr-x+ 2 fabiopoloni  staff   68  8 Okt 12:18 .
drwxr-xr-x+ 8 fabiopoloni  staff  272  8 Okt 12:18 ..

There is also no .gitmodules so it’ll show you an error when viewing the status / syncing it:

​$ git submodule status
No submodule mapping found in .gitmodules for path 'bin'

​$ git submodule sync
No submodule mapping found in .gitmodules for path 'bin'
No submodule mapping found in .gitmodules for path 'src'

Since they’re empty, the easiest way is to delete them and commit:

​$ rm -rf bin
​$ rm -rf src
​$ git commit -a -m 'Removed empty submodules folders'
$ git push

answered Oct 8, 2015 at 10:28

Fabio Poloni's user avatar

Fabio PoloniFabio Poloni

8,2015 gold badges43 silver badges74 bronze badges

I encountered the same issue.

The command I gave was :

git add <foldername>

The problem here is we forgot to mention that we need this as a folder :

git add <foldername>/

With the backslash , we can now see that all the files of this folder are getting displayed and this works for me!

AS Mackay's user avatar

AS Mackay

2,8319 gold badges19 silver badges25 bronze badges

answered Jul 26, 2019 at 19:34

Aakanksha Duggal's user avatar

I had the same problem in my react folder but I had solved it by
.
.
git rm —cached

answered Oct 17, 2021 at 7:26

MrEpic's user avatar

Despite deleting the .git folder github did not add properly the affected folder. I did not want to delete the folder and I instead did the following:

I’ve solved it with the following order

In my example let’s say that I’ve the following repo structure

app
| - .git # <- Correct .git of the repo
| - dir1
| - dir2
| - subApp
| ---
    | - .git # <- Mistake here because there was another .git
    | - subfolder1
    | - ....
| - dir 3 
 

Now with the followig structure and git with not allow you to push the content of the subfolder because it contains already a .git (in my case it was created by an automatic process)

Solution

  1. Remove the .git folder
rm -rf ./subApp/.git
  1. Rename subApp and push changes
rm subApp subAppTemp
  1. Add and push
git add subAppTemp
git commit -m "Temporary push"
git push 
  1. Rename it to original name and push back to git
rm subAppTemp subApp
git add subApp
git commit -m "Correct push of dir.."
git push

answered May 29, 2022 at 19:55

Federico Baù's user avatar

Federico BaùFederico Baù

5,6655 gold badges28 silver badges36 bronze badges

This can happen when you initialize a repository in the child directories.
For me, I’d initialized a git repo inside the client directory.
In your case it might be the src directory, try rm -rf .git inside the src directory, this would delete the .git file inside the src directory, and try pushing the changes again src would be available then.

answered Jan 26, 2021 at 18:51

reaped juggler's user avatar

Возможно, вам также будет интересно:

  • Git ошибка при установке
  • Git ошибка при построении деревьев
  • Git ошибка non fast forward
  • Git ошибка error src refspec master does not match any
  • Git ошибка error failed to push some refs to

  • Понравилась статья? Поделить с друзьями:
    0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии