Сбой фиксации SVN с ошибкой «Авторизация не удалась»

Question

Я новый пользователь с SVN, и у меня возникла проблема с командой SVN commit.

Я использую TortoiseSVN 1.6.6 и образ Ubuntu Subversion с WMware в качестве сервера.

Я создал репозиторий на сервере SVN, и я могу легко извлекать файлы из репозитория, но фиксировать.

Когда я делаю коммит, это всегда показывает проблему.

Command: Commit  
Error: Commit failed (details follow):  
Error: Authorization failed  
Finished!:   

Эта проблема отображается только на локальном клиенте с хранилищем сервера SVN на ВМ. Я попытался создать репозиторий на локальной машине с TortoiseSVN, и это не проблема для Commit. Я также попробовал рабочую копию на серверном компьютере, это не проблема для Commit также.

Кто-нибудь сталкивался с этой проблемой? Это не проблема при извлечении с сервера SVN VM, но это показывает проблемы при фиксации локального клиента на сервере VM.

Нужно ли что-то настраивать, я пропустил это?

Answer 1

Авторизация не удалась. Это означает, что на первом этапе аутентификация прошла успешно.

Итак: имя пользователя / пароль верны и были приняты вашим сервером. Но тогда этому пользователю не разрешили получить доступ к пути / ресурсу.

проверьте свой файл авторизации на основе пути (conf / authz) и убедитесь, что у пользователя есть права.

Answer 2

Для меня это было из-за миграции сервера. В svnserve.conf я забыл раскомментировать:

auth-access = write
password-db = passwd

Answer 3

Если сервер использует svnserve для обслуживания хранилища (что означает, что вы используете svn:// URL), то вам следует проверить файл conf/svnserve.conf в хранилище. Конфигурация по умолчанию разрешает анонимное чтение, но только аутентифицированный доступ к записи IIRC.

Answer 4

Мой опыт был похож на Bluebrother Я правильно создал новый репозиторий, но не настроил пользователей должным образом. Это позволяет мне оформить заказ, но не совершать

Редактировать repoLocation / conf / svnserve.conf и раскомментировать строку

password-db = passwd

Изменить repoLocation / conf / passwd и добавить имя пользователя и пароль для passwd, например

tim = пароль

Answer 5

У меня была точно такая же проблема с RapidSVN (или при использовании svn commit из CLI). Выяснилось, что я проверял репозиторий с помощью Anonymous Subversion Access (ссылка svn://):

svn checkout svn://svn.r-forge.r-project.org/svnroot/rsitesearch/

Но при использовании этой ссылки для репо вы не можете зафиксировать изменения. Таким образом, решение состояло в том, чтобы использовать ссылку svn+ssh://, позволяющую Developer Subversion Access через SSH:

svn checkout svn+ssh://developername@svn.r-forge.r-project.org/svnroot/rsitesearch/

Для других служб SVN правильная ссылка для фиксации может быть https://. На самом деле у меня есть лучший опыт с проверкой https://, поэтому попробуйте сначала.

Теперь svn commit должен работать как положено.

(Это то же решение, которое было предложено Вугом в комментарии к ОП.)

Answer 6

Если вы используете svnserve для предоставления доступа к SVN (т. Е. URL-адрес вашего хранилища выглядит как svn://server/repo), убедитесь, что ваш сервер разрешает доступ для записи. В некоторых случаях по умолчанию сервер запускается с доступом только для чтения:

# The -R option enforces read-only access, i.e. write operations to the
# repository (such as commits) will not be allowed.
SVNSERVE_OPTIONS="-d -R -r /srv/svn/repos"

Answer 7

Прежде всего, вы можете просмотреть хранилище от черепахи? Если вы можете, то учетная запись пользователя, к которому вы обращаетесь к репозиторию, не имеет прав на запись (= принятие).

Если вы не можете ни просматривать, ни фиксировать: возможно, Tortoise сохранила неверные данные аутентификации на вашем клиенте. Я думаю, что должен снова запросить учетные данные в этом случае, но, возможно, это не так. Попробуйте это:

1. Откройте меню Пуск, перейдите в группу TortoiseSVN

2. Нажмите «Настройки TortoiseSVN»

3. Перейти к «Сохраненные данные»

4. Нажмите «Очистить» в «Аутентификационных данных»

Черепаха затем забудет все сохраненные пароли и попросит вас снова в следующий раз, когда вы попытаетесь получить доступ к ВМ.

Answer 8

Проверьте ваши файлы, используя протокол http вместо протокола svn. У меня была та же проблема, что и при проверке файлов по протоколу svn: //. Позже я изменил протокол на http: // и все стало работать нормально.

Answer 9

примечание: я использую sasl, и я выяснил сложный способ, что он чувствителен к регистру и ожидает имена пользователей в нижнем регистре; Т.е. «username123» не будет совпадать с «USERNAME123» в вашем файле authz, хотя они написаны одинаково, поэтому, возможно, проверьте, чтобы убедиться, что ваши имена пользователей строчные (в вашем файле authz)

Answer 10

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