Почему Mercurial возвращает «Abort: доступ запрещен» при попытке отправить хранилище?

Question

Я сталкиваюсь с проблемой, когда пользователь не может вставить свои коммиты в репозиторий Mercurial, и я озадачен, почему он не работает для него.Я попробовал несколько вещей, чтобы выяснить, в чем дело, Google не находит ничего полезного ... вот и я.

Во-первых, конфигурация.В нашей сети есть машина с Windows XP SP2 x64, которая выступает в качестве официального сервера хранилища.Это содержит несколько репозиториев на нем.Мы клонируем / толкаем / вытягиваем, используя папку на этом диске, которая является общей.Разрешения предоставляются каждому для доступа на чтение.Пользователи, которые могут нажать (включая пользователя, у которого есть проблемы), получают полный контроль.Машина пользователя основана на Win XP.Моя машина (используется для устранения неполадок) также основана на Win XP.

Во-вторых, симптомы.Пользователь использует TortoiseHg 2.1.1 для выполнения своей работы.Он может клонировать просто отлично, коммиты в его локальный репозиторий принимаются и т. Д. Однако, когда он пытается нажать, TortoiseHg возвращает код «abort, ret 255».Не очень полезно.Итак, мы перешли в командную строку и выдали «hg push -v --debug».Здесь возвращается «abort: доступ запрещен».Этот же пользователь может без проблем писать в общую папку сервера - он может создавать файлы, каталоги и удалять их.Таким образом, доступ для чтения / записи к диску / папке не является проблемой.

В-третьих, наши результаты экспериментов.Вот некоторые странные результаты тестирования.Пользователь создал новое локальное тестовое репо.Я вошел в систему на сервере и создал тестовое репо, чтобы он мог нажать на него.Пользователь зарегистрировал файл и затем отправил его в тестовое хранилище на сервере.Это работало нормально.Нет прерываний.Жизнь была хорошей.Он смог сделать еще несколько толчков, и он продолжал работать, как ожидалось.Затем я клонировал репо на свою машину, обновил файл и вытолкнул его обратно.После того как пользователь извлек мои изменения и попытался вернуться на сервер, он снова столкнулся с ужасным сообщением «Доступ запрещен».Между тем, я все еще могу обновить проект без каких-либо проблем.

В качестве другого эксперимента у нас был выход пользователя из системы и другой вход пользователя. Они сделали это и смогли без проблем перейти на репозиторий сервера.Исходный пользователь снова входит в систему, вносит некоторые изменения и т. Д. И снова сталкивается с кирпичной стеной «Доступ запрещен».

Насколько мы можем судить, проблема не связана с учетными данными Windows.В противном случае мы ожидаем, что создание произвольных файлов в общей папке на сервере не будет работать.Кроме того, до тех пор, пока я не обновил тестовое репо, созданное пользователем, он мог просто толкнуть этот репо.

Есть идеи?Какие дополнительные проверки учетных данных выполняет Mercurial, что может вызвать это?

ОБНОВЛЕНИЕ:

После получения подсказки от Wim я начал просматривать разрешения на различные объектырепо с использованием «cacls».Это инструмент Windows, который «отображает или изменяет списки контроля доступа к файлам».Я попросил пользователя создать новый репозиторий, а затем сделал снимок разрешений.Затем я зарегистрировал файл в том же репо и сделал еще один снимок изменений.

Оказывается, что в результате этого обновляются несколько разрешений для файлов репо: undo.bookmarks, undo.branch, undo.desc, undo.dirstate, branchheads, 00changelog.i, 00manifest.i, отменить и единственный файл хранилища.Все эти файлы имеют разрешения, аналогичные следующим:

C:\Projects\Mercurial\hgtest4\.hg\store\undo BUILTIN\Administrators:F 
                                         NT AUTHORITY\SYSTEM:F 
                                         DOMAINxxxx\USERIDxxxx:F 
                                         BUILTIN\Users:R 

(фактические значения DOMAINxxxx и USERIDxxxx были изменены). До моей регистрации DOMAINxxxx & USERIDxxxx отражал домен пользователя и идентификатор пользователя. После моей регистрации они были обновлены до моего (мы находимся в одном домене, но идентификатор пользователя, очевидно, отличается.) Я смог проверить и проверить, даже если мой идентификатор пользователя не был в списке, потому что я являюсь членом группы BUILTIN \ Администраторы. Пользователь с проблемой не является. Итак, я предполагаю, что после того, как я что-то зарегистрировал, система больше не видела в нем пользователя с правами доступа с правами на запись (BUILTIN \ User: R указывает на доступ только для чтения) и поэтому вызвала отказ в доступе.

У меня сейчас ужасное исправление Q & D (пользователь теперь входит в группу администраторов ...). Реальное исправление будет состоять в том, чтобы получить репо от общего доступа Windows и перейти к правильной конфигурации сервера .

Answer 1

Он смог сделать еще несколько толчков, и он продолжал работать, как и ожидалось.Затем я клонировал репо на свою машину, обновил файл и вытолкнул его обратно.После того, как пользователь извлек мои изменения и попытался вернуться на сервер, он снова столкнулся с ужасным сообщением «Доступ запрещен».

Звучит так, как будто вы нажимаете, создает или изменяет файлы вПапка .hg таким образом, что они (или становятся) недоступны для другого пользователя.

Я не эксперт по разрешениям файлов NTFS, но я думаю, что вы можете исправить такие ситуации, заставив все содержимое папки наследовать ее разрешения.Попробуйте выбрать « Заменить все разрешения дочернего объекта на унаследованные разрешения для этого объекта » в настройках расширенной безопасности папки.

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

См. Публикация Mercurial Repositories на вики Mercurial для получения дополнительной информации о других опциях.

Answer 2

У меня просто была такая же проблема abort: Access is denied.Причиной был мой firewall (Privatefirewall), который молча блокировал некоторые действия hg.

Answer 3

При попытке зафиксировать в моем локально клонированном репозитории репозитория кода в сетевой папке я получаю то же сообщение об ошибке:

00manifest.i Access is denied

Вероятно, чрезмерно упрощенно, но удаление некоторых разрешений только для чтения для оскорбительных файлов заставило мою hg commit работать нормально.

Answer 4

Я получал точно такое же сообщение об ошибке при попытке hg push в командной строке Windows. Недавно я получил новый профиль пользователя после того, как старый был поврежден. Затем я столкнулся с этой «Отказано в доступе» ошибка. В TortoiseHg я получил похожее сообщение «Прервано: Ошибка 255» .

Я попробовал совет, данный здесь Вимом Коененом , как мне показалось; учитывая мои новые учетные данные пользователя. В итоге я отследил ошибку до плохо установленного Windows Git. Сбой только когда я использовал репозитории с git sub-repos.

В случае, если у других возникла подобная проблема с Git-репо:

• Убедитесь, что Git установлен правильно. Я удалил и переустановил его полностью. (См .: https://code.google.com/p/msysgit/downloads/list для последней версии).
• Убедитесь, что путь к Git указан в переменной окружения path. ( Щелкните правой кнопкой мыши Мой компьютер -> вкладка Дополнительно -> Переменные среды ). Не забывайте, что некоторым приложениям не нравятся пути Windows с пробелами, поэтому вам может потребоваться заменить «Program Files» на «PROGRA ~ 1» (возможно, «PROGRA ~ 2» в 64-битных системах).
• Если вы используете прокси-сервер, убедитесь, что HTTP_PROXY и HTTPS_PROXY в переменных среды также установлены правильно.