Почему Mercurial возвращает "Abort: Access is Denied" при попытке нажать репозиторий?
я сталкиваюсь с проблемой, когда пользователь не может протолкнуть свои коммиты в репозиторий Mercurial, и я озадачен тем, почему он не работает для него. Я пробовал несколько вещей, чтобы понять, что происходит, гуглить не приносит ничего полезного... и вот я здесь.
во-первых, конфигурации. У нас есть машина Windows XP SP2 x64 в нашей сети, действующая как наш официальный сервер репозитория. Это содержит несколько репозиториев на нем. Мы клонируем / push / pull с помощью папки на этом диске, который является общим. Разрешения предоставляются каждому для доступа на чтение. Пользователям, которые могут нажимать (включая пользователя, у которого есть проблемы), предоставляется полный контроль. Машина пользователя основана на Win XP. Моя машина (используемая для устранения неполадок) также основана на Win XP.
во-вторых, симптомы. Пользователь использует TortoiseHg 2.1.1 для выполнения своей работы. Он может клонировать просто отлично, фиксируется на своем локальном РЕПО a-o-k и т. д. Однако, когда он пытается нажать, TortoiseHg возвращает " abort, ret 255" код. Не очень полезный. Итак, мы перешли в командную строку и выдали "HG push-v --debug". Здесь он возвращает "abort: Доступ запрещен". Этот же пользователь может писать в общую папку сервера без проблем - он может создавать файлы, каталоги и удалять то же самое. Таким образом, чтение / запись доступа к диску / папке не является проблемой.
в-третьих, результаты наших экспериментов. Вот некоторые странные результаты тестирования. Пользователь создал новое локальное тестовое РЕПО. Я вошел в серверная машина и создала тестовое РЕПО для его нажатия. Пользователь зарегистрировал файл, а затем подтолкнул его к тестовому РЕПО на серверной машине. Это сработало отлично. Никаких абортов. Жизнь была хороша. Он сумел сделать еще несколько толчков и он продолжал работать, как ожидалось. Затем я клонировал РЕПО на свою машину, обновил файл и вытолкнул его обратно. После того, как пользователь затем вытащил мои изменения и попытался вернуться на сервер, он снова столкнулся с ужасным " отказано в доступе" сообщение. Между тем, я все еще могу обновить проект без каких-либо проблем.
в качестве другого эксперимента у нас был выход пользователя и вход другого пользователя. Они сделали это и смогли без проблем нажать на серверное РЕПО. Оригинальный пользователь снова входит в систему,вносит некоторые изменения и т. д. и в очередной раз попадает в кирпичную стену "Доступ запрещен".
насколько мы можем судить, проблема не связана с учетными данными Windows. В противном случае мы ожидаем, что создание произвольных файлов на общая папка сервера не будет работать. Кроме того, пока я не сделал обновление для тестового РЕПО, созданного пользователем, он мог просто нажать на это конкретное РЕПО.
какие идеи? Какие дополнительные проверки учетных данных Mercurial делает, что может вызвать это?
обновление:
после подсказки от Wim я начал просматривать разрешения на различные объекты РЕПО с помощью "cacls". Это средство Windows, которое "отображает или изменяет доступ контрольные списки файлов". Я заставил пользователя создать новое РЕПО, а затем сделал снимок разрешений. Затем я проверил файл в том же РЕПО и сделал еще один снимок изменений.
оказывается, что есть несколько разрешений файла репо, которые обновляются в результате этого: отменить.закладки, отменить.ветвь, отменить.деск, отменить.dirstate, branchheads, 00changelog.я, 00manifest.i, undo и единственный файл репозитория. Все эти файлы имели разрешения, похожие на следующий:
C:ProjectsMercurialhgtest4.hgstoreundo BUILTINAdministrators:F
NT AUTHORITYSYSTEM:F
DOMAINxxxxUSERIDxxxx:F
BUILTINUsers:R
(фактические значения DOMAINxxxx и USERIDxxxx были изменены). До моей регистрации DOMAINxxxx & USERIDxxxx отражали домен пользователя и идентификатор пользователя. После моей регистрации они были обновлены до моего (мы находимся в одном домене, но userid явно отличается.) Я был в состоянии проверить вещи и даже мой userid не был указан, потому что я являюсь членом группы BUILTINAdministrators. Пользователь с проблемой не является. Итак, я предполагая, что после того, как я проверил вещи, система больше не видела его как пользователя с правами доступа на запись (BUILTINUser:R указывает доступ только для чтения) и поэтому вызвала отказ в доступе.
У меня есть ужасно Q&D исправление на месте прямо сейчас (пользователь теперь является частью группы администратора...) Реальное исправление будет заключаться в том, чтобы получить РЕПО от совместного использования Windows и на правильной конфигурации сервера.
4 ответов
Он смог сделать еще несколько толчков, и он продолжал работать, как ожидалось. Затем я клонировал РЕПО на свою машину, обновил файл и вытолкнул его обратно. После того, как пользователь затем вытащил мои изменения и попытался вернуться на сервер, он снова столкнулся с ужасным сообщением "Доступ запрещен".
похоже, что ваш push создает или изменяет файлы в.папка hg таким образом, что они являются (или становятся) недоступными для другого пользователя.
Я не эксперт по разрешениям файлов NTFS, но я думаю, что вы можете исправить такие ситуации, заставив все содержимое папки наследовать ее разрешения. Попробуйте выбрать"заменить все разрешения дочернего объекта на разрешения, наследуемые от этого объекта " в расширенных настройках безопасности папки.
однако общий доступ к файлам репозитория напрямую с общим доступом к файлам Windows -не рекомендуется. Вам нужен серверный процесс между пользователи и файлы репозитория для обеспечения производительности, целостности данных и безопасности. Без такого привратника предоставление доступа фиксации также означает предоставление возможности уничтожить / повредить файлы репозитория (или, как вы узнали в этом случае, изменить их разрешения).
посмотреть Публикация Репозиториев Mercurial на Mercurial wiki для получения дополнительной информации о других вариантах.
при попытке совершить на моем локально клонированном репозитории РЕПО кода на моем сетевом ресурсе, я получал то же сообщение об ошибке:
00manifest.i Access is denied
вероятно, слишком упрощенно, но удаление некоторых разрешений только для чтения для оскорбительных файлов сделало мой hg commit работать нормально.
У меня была такая же проблема abort: Access is denied. Причиной был мой брандмауэр (прайветфаерволл-privatefirewall) молча блокирует некоторые действия ртути.
Я получаю точно такое же сообщение об ошибке при попытке HG push в командной строке Windows. Недавно я получил новый профиль пользователя после того, как старый был поврежден. Затем я столкнулся с этим "Доступ Запрещен" ошибка. В TortoiseHg я получил аналогичное сообщение "Прервано: Ошибка 255".
Я попробовал совет, данный здесь ВИМ Кунен как показалось, подходит; учитывая мои новые учетные данные пользователя. В конце концов, я отследил ошибка плохо установленной Windows Git. Это было только сбой, когда я использовал репозитории с Git суб-РЕПО.
в случае, если у других есть аналогичная проблема с Git sub-repos:
- убедитесь, что Git установлен правильно. Я удалил и переустановил его полностью. (См.: https://code.google.com/p/msysgit/downloads/list для последней версии).
- убедитесь,что путь к Git находится в переменной среды path. (Правой Кнопкой Мыши Мой компьютер -> вкладка Дополнительно -> Переменные среды). Не забывайте, что некоторым приложениям не нравятся пути windows с пробелами, поэтому вам может потребоваться заменить "Program Files" на "PROGRA~1" (возможно, "PROGRA~2" в 64-битных системах).
- если вы используете прокси, убедитесь, что HTTP_PROXY и HTTPS_PROXY в переменных среды также установлены правильно.