У одного из моих коллег возникла проблема с отправкой изменений из git на его машину. Если он входит в систему на другой машине, он может нормально нажимать, но со своей машины, когда он пытается нажать, он получает следующую ошибку
D:\Projects\test1\best-practices>git push
Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 273 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
error: unable to create temporary sha1 filename ./objects/42: Permission denied
fatal: failed to write object
error: unpack failed: unpacker exited with error code
To //civ3s012/gitrepos/best-practices/.git
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to '//civ3s012/gitrepos/best-practices/.git'
Сервер - это машина с Windows, как и клиент. Ни у кого больше нет этой проблемы - похоже, это проблема с разрешениями сервера, но мы исключили это, насколько можем судить. Кроме того, тот факт, что он может войти на другую машину и нажать, используя то же имя пользователя, заставляет думать, что это не разрешения сервера. Есть идеи, что здесь может быть не так?





Может быть, он создал ветку в своем локальном репо, которая уже существует на сервере, и эту ссылку нельзя обновить, потому что она была создана кем-то другим?
Он только что начал работать над этим проектом и не создавал никаких веток явно.
Я знаю, что это простой ответ системного администратора, но вы проверили, что его жесткий диск не заполнен?
Да, со мной этого случилось достаточно, что я проверяю это в первую очередь сейчас.
Я не являюсь пользователем Windows, поэтому я здесь немножко колю в темноте. Похоже, удаленная файловая система смонтирована, и вы просто нажимаете на нее (не используя ssh: // или git: //). Эта FS как-то смонтирована только для чтения? Может ли он там создавать / изменять файлы (кроме git)?
Моя ошибка - remote unpack failed: unable to create temporary object directory To //<my local computer>/repository/tutorial3.git. Да, я использую свою собственную машину Win7. Ваш ответ мне помогает. Как только я изменю «Разрешение общего доступа» к папке репозитория (добавив «Изменить» рядом с «прочитанным»), я могу нажать. Спасибо.
Попробуйте добавить эту переменную конфигурации в удаленный репозиторий:
$ git config core.sharedRepository "all"
$ git config receive.denyNonFastForwards True
Обычно они устанавливаются опцией --shared в git init при настройке репо.
Я не знаю, как взаимодействуют разрешения Windows, поэтому не уверен, что это решение. Но я знаю, что иногда пользователь Linux может создавать файлы с разрешениями, которые не работают на удаленном компьютере Git именно таким образом. Это произошло, когда они принадлежат к правильной группе, но не имеют ее в качестве группы начальный. Установка совместного использования репо на all позволяет обойти это.
Похоже, это происходит с общими репозиториями, импортированными из SVN или CVS.
Это не решило проблему для нас - и, как примечание, это репо не было импортировано из SVN или CVS, оно было запущено из git. Спасибо хоть.
Еще один мертвый ответ. Вы уверены, что у вас есть разрешение на чтение этих файлов? Со мной случалось несколько раз, когда я по ошибке вносил изменения в качестве другого пользователя. Потом позже я не могу толкаться. Чоун - твой друг.
Проблема заключалась в том, что для этого общего ресурса был сохранен пароль, который разрешал доступ для чтения, но не для записи. Даже когда мы явно подключили диск с соответствующим именем пользователя и паролем, сохраненный пароль должен был использоваться в фоновом режиме, что затрудняло его отслеживание. Чтобы очистить пароль, мы перешли в Панель управления, Учетные записи пользователей, нажали «Дополнительно», «Управление паролями» и удалили информацию для входа на рассматриваемый сервер. После этого все заработало как надо. Я принимаю ответ Пэта Нотца, поскольку в конечном итоге он оказался доступной только для чтения. Спасибо!
Спасибо, что разместили подробную информацию о корневой проблеме и решении!
Я согласен. Ах да, ик! Не знаю, подумал бы я когда-нибудь проверить это.
Проблемы с разрешениями были причиной этой ошибки.