【対処法】svn e170013 エラーが発生したら

By /

【徹底解説】Subversion (SVN) E170013 エラー：原因、詳細な対処法、そして予防策

Subversion (SVN) は、長年にわたり多くのプロジェクトで利用されてきた分散型ではない集中型バージョン管理システムです。コード、ドキュメント、その他のデジタル資産の変更履歴を管理し、複数の開発者が同時に作業を進めることを可能にします。しかし、SVNを使用していると、様々なエラーに遭遇することがあります。その中でも比較的よく発生し、特に初めて遭遇するユーザーを困惑させやすいエラーの一つが、E170013 エラーです。

このエラーコードは、通常、SVNクライアントがリポジトリにアクセスしようとした際に発生し、ネットワークやリポジトリの状態に関連する問題を指し示しています。プロジェクトの進行を妨げる可能性のあるこのエラーに迅速かつ適切に対処するためには、その原因を深く理解し、系統立てたトラブルシューティングを行うことが不可欠です。

本記事では、SVNのE170013エラーについて、そのエラーコードが何を意味するのかから始まり、具体的な原因、そしてそれぞれの原因に応じた詳細な対処法、さらには将来このエラーの発生を防ぐための予防策まで、徹底的に解説します。約5000語を費やし、読者がこのエラーに遭遇した際に困ることなく、問題を解決できるようになることを目指します。

1. はじめに：SVNとエラーコード E170013 の概要

まず、Subversion (SVN) とは何か、そしてE170013というエラーコードがSVNシステムの中でどのような位置づけにあるのかを理解することから始めましょう。

1.1. Subversion (SVN) とは

SVNは、ファイルやディレクトリの変更を追跡し、過去の任意の時点の状態に戻したり、異なる変更をマージしたりするためのバージョン管理システムです。中央集権型モデルを採用しており、一つの集中管理されたリポジトリに全てのバージョン履歴が保存されます。ユーザーはクライアントソフトウェア（例: TortoiseSVN, コマンドラインクライアント svn）を使って、このリポジトリからファイルの最新版を取得（チェックアウト）、変更をコミット、更新、ブランチ作成、マージなどの操作を行います。

SVNは、HTTP/HTTPS (mod_dav_svn経由) や独自の svn プロトコル (svnserve 経由)、または svn+ssh などの様々な方法でリポジトリにアクセスできます。エラーE170013は、まさにこのクライアントとリポジトリ間のアクセスに関連する問題が発生した際に報告されることが多いエラーです。

1.2. エラーコード E170013 の意味するところ

SVNのエラーコードは、通常、エラーの種類や発生したモジュールを示す数値のプレフィックスと、具体的なエラーの内容を示す数値のサフィックスで構成されています。

  • E170000シリーズ: SVNのエラーコードで E170000 から始まるものは、一般的に「ネットワーク関連のエラー」や「リポジトリへのアクセス関連のエラー」を示します。これは、クライアントがリポジトリと通信しようとした際に発生する問題、リポジトリのURLが無効である、認証に失敗した、サーバーが見つからない、ネットワーク接続が確立できない、などの状況で報告されます。
  • E170013: E170000シリーズの中の13という具体的なコードは、多くの場合、リポジトリのパスが見つからない、無効なリポジトリURL、またはリポジトリが存在しない/アクセスできないといった状況を示唆します。これは単にネットワークがダウンしているだけでなく、指定した場所にリポジトリがない、あるいはSVNが期待する形式でリポジトリが存在しない可能性が高いことを意味します。例えば、以下のような操作で発生することがあります。
    • svn checkout <リポジトリURL> <ローカルパス>
    • svn update (作業コピーのURLが間違っているか、リポジトリが移動/削除された)
    • svn info <リポジトリURL>
    • svn log <リポジトリURL>

つまり、E170013エラーは、「指定されたリポジトリの場所（URL）にアクセスできなかった、または、そこに有効なSubversionリポジトリが見つからなかった」という問題を報告していると理解するのが最も適切です。これは、ネットワークの問題に起因することもあれば、サーバー側の設定ミスやリポジトリ自体の状態に起因することもあります。

2. エラー E170013 の潜在的な原因の深掘り

エラーE170013がリポジトリへのアクセス問題を示すことは理解できましたが、具体的にどのような状況でこの問題が発生するのでしょうか？考えられる原因は多岐にわたります。ここでは、最も一般的な原因から、少し特定が難しい原因までを深掘りして解説します。

2.1. リポジトリURLの誤りまたは無効な指定

これは最も単純かつ最も頻繁に発生する原因の一つです。

  • スペルミス: リポジトリURLのホスト名、パス、またはプロトコル（http、https、svn、svn+sshなど）にスペルミスがある。
  • プロトコルの間違い: httpsでアクセスすべきところをhttpで指定している、またはその逆。svnserveで運用されているリポジトリにhttpでアクセスしようとしている、など。
  • ホスト名/IPアドレスの誤り: 存在しないホスト名や間違ったIPアドレスを指定している。
  • パスの誤り: リポジトリルートへのパスが間違っている、存在しないサブディレクトリを指定している。例えば、http://svn.example.com/repos/myproject であるべきところを http://svn.example.com/myproject や http://svn.example.com/repos/myproject/trunk などと指定している。
  • 大文字・小文字の間違い: ファイルシステムによっては大文字・小文字を区別しない場合がありますが、リポジトリのURLやパスは通常大文字・小文字を厳密に区別します。
  • 末尾のスラッシュの有無: プロトコルやサーバー設定によっては、URLの末尾にスラッシュが必要な場合と不要な場合があります。多くの場合、リポジトリのルートURLには末尾にスラッシュがない形が一般的ですが、サーバー設定によってはその逆や特定のルールが必要になることもあります。

2.2. ネットワーク接続の問題

クライアントからSVNサーバーへのネットワーク経路に問題がある場合、クライアントはリポジトリに到達できません。

  • サーバーが停止している: SVNサーバーをホストしているマシンがダウンしている、またはSVNサービス（Apache, svnserve）が停止している。
  • ネットワークケーブルの切断/Wi-Fiの問題: クライアントマシンの基本的なネットワーク接続に問題がある。
  • ファイアウォールによるブロック:
    • クライアント側のファイアウォール: OSやセキュリティソフトのファイアウォールが、SVNクライアントの特定のポート（例: http/httpsの80/443、svnの3690）への発信接続をブロックしている。
    • サーバー側のファイアウォール: サーバーOSやネットワーク機器のファイアウォールが、クライアントのIPアドレスまたはネットワークからの接続要求をブロックしている。
    • 中間にあるファイアウォール: 企業ネットワーク、VPN、ルーターなどが、SVNが使用するポートやプロトコルをブロックしている。
  • DNS解決の失敗: 指定したホスト名に対応するIPアドレスを解決できない。DNSサーバーがダウンしている、DNS設定が間違っている、ネットワークがDNSサーバーに到達できないなど。
  • ルーティングの問題: クライアントからサーバーまでのネットワーク経路に問題があり、パケットが正常に到達しない。
  • プロキシ設定の問題:
    • SVNクライアント、OS、またはブラウザ（TortoiseSVNなどが参照することがある）のプロキシ設定が間違っている。
    • プロキシサーバー自体がダウンしている、または認証が必要だが正しく設定されていない。
    • プロキシサーバーがSVN通信をブロックしている。
  • MTU (Maximum Transmission Unit) の問題: ネットワーク経路上のどこかでMTU値の不一致があり、パケットの断片化やドロップが発生している（比較的稀だが可能性としてあり得る）。

2.3. SVNサーバー側の設定または状態の問題

SVNサーバー自体に問題がある場合、クライアントからのアクセスに応答できません。

  • SVNサービスが実行されていない: Apache (mod_dav_svnを使用する場合) または svnserve サービスが起動していない、またはクラッシュしている。
  • SVNサーバー設定の誤り:
    • Apacheの設定 (httpd.conf, extra/subversion.confなど): Locationディレクティブのパスの誤り、SVNPathやSVNParentPathの指定ミス、LoadModuleの不足、仮想ホスト設定の誤りなど。
    • svnserveの設定 (svnserve.conf): ポートの Listen 設定の誤り、リポジトリパスの誤り、認証設定の誤りなど。
  • リポジトリパスの誤り: サーバー側の設定ファイルで指定されているリポジトリの物理的なパスが間違っている、またはリポジトリディレクトリが存在しない。
  • リポジトリ自体の破損: リポジトリのデータが何らかの原因で破損しており、SVNサーバーがリポジトリとして認識できない状態になっている（この場合、他のエラーが先に報告されることも多いが、E170013で報告される可能性もゼロではない）。
  • サーバーの過負荷: サーバーがCPU、メモリ、ネットワーク帯域などのリソース枯渇により、SVNリクエストに応答できない状態になっている。
  • SELinuxやAppArmorなどセキュリティ機能による制限: サーバーOSのセキュリティ機能が、Apacheやsvnserveプロセスによるリポジトリディレクトリへのアクセスを制限している。

2.4. 認証または認可 (AuthN/AuthZ) の問題

リポジトリは存在するが、アクセス権限がない場合も、エラーE170013として報告されることがあります（ただし、認証失敗の場合はE170001など別のエラーが報告されることが多いですが、サーバー側の設定によってはE170013になることもあります）。

  • 認証情報の誤り: クライアントが間違ったユーザー名やパスワードで認証しようとしている。
  • 認証設定の誤り (サーバー側):
    • AuthConfig ディレクティブが有効になっていない (Apache)。
    • password-db, authz-db などの設定が間違っている (svnserve, Apache)。
    • 認証に使用するファイル (passwd, authz) が存在しないか、パスが間違っている。
  • 認可設定の誤り (サーバー側): authz ファイルで、指定されたユーザーまたはグループにリポジトリへのアクセス権限が与えられていない。特に、指定されたリポジトリのパスに対して読み取り権限 (r) や書き込み権限 (w) がない場合。E170013は、アクセス拒否というよりは「そこにリポジトリがあること自体を知らされない」という状況で発生しやすいです。例えば、親パス (SVNParentPath) の下に複数のリポジトリがあり、ユーザーがアクセスを許可されていないリポジトリを指定した場合などです。
  • SSLクライアント証明書の問題: HTTPSでアクセスする場合、クライアント証明書による認証が失敗している。

2.5. SSL/TLS 証明書の問題 (HTTPSアクセスの場合)

HTTPSプロトコルでアクセスする場合、SSL/TLS証明書に関連する問題が発生することがあります。

  • サーバー証明書が無効: 証明書の有効期限が切れている、発行元が不明、ホスト名と証明書に記載された名前が一致しない（Common Name mismatch）など。
  • 自己署名証明書: 信頼されていない自己署名証明書を使用しており、クライアントがそれを信頼しない設定になっている。
  • 中間証明書の不足: サーバーが中間証明書チェーンを正しく提供しておらず、クライアントがルート証明書まで辿れない。
  • SSL/TLSプロトコルまたは暗号スイートの不一致: クライアントとサーバーが共通のSSL/TLSプロトコルバージョンや暗号スイートでネゴシエートできない。
  • サーバー証明書のキャッシュ問題 (クライアント側): 以前接続した際の情報がキャッシュされており、それが現在のサーバー証明書と一致しない。

2.6. クライアント側の環境問題

比較的稀ですが、クライアント側のローカル環境に問題がある場合も、エラー発生の原因となり得ます。

  • SVNクライアントのバージョンが古い/互換性がない: 非常に古いクライアントバージョンを使用している場合、新しいサーバーやリポジトリ形式との互換性の問題が発生する可能性があります。
  • クライアントの構成ファイル破損: SVNクライアントのローカル構成ファイル（例: ~/.subversion/config や %APPDATA%\Subversion\config）が破損している。
  • WindowsのCredential Managerの問題: WindowsのCredential Managerに保存されている認証情報が古くなっている、または間違っている。
  • VPNクライアントの干渉: 使用しているVPNクライアントソフトウェアがネットワーク通信に干渉している。

3. エラー E170013 の詳細な対処法

原因を特定したら、次はその原因に応じた具体的な対処を行います。ここでは、先ほど挙げた潜在的な原因に対応する形で、段階的かつ詳細なトラブルシューティングステップを解説します。

重要: トラブルシューティングを行う際は、まず最も単純で可能性の高い原因から調査を進めるのが効率的です。

ステップ1：リポジトリURLの徹底的な確認 (最も可能性が高い原因への対処)

エラーメッセージに表示されている、または操作に使用したリポジトリURLを注意深く確認します。

  1. スペルミスの確認: ホスト名、ドメイン名、パス、プロトコルの全てを一文字ずつ確認します。
  2. プロトコルの確認: http、https、svn、svn+ssh のどれを使用すべきか、正しいプロトコルが指定されているかを確認します。
  3. パスの確認: リポジトリのルートディレクトリまでのパスが正しいかを確認します。多くの場合、サーバー管理者に確認するのが最も確実です。
    • 例: http://svn.example.com/repos/myproject は正しいが、http://svn.example.com/myproject は誤り。
    • 作業コピーで svn update 時にエラーが出る場合は、その作業コピーがチェックアウトされたリポジトリURL (svn info で確認) が正しいか確認します。リポジトリがサーバー側で移動された可能性もあります。
  4. 大文字・小文字の区別: パスは大文字・小文字を区別して入力します。
  5. 末尾のスラッシュ: 必要に応じて末尾のスラッシュの有無を試します。通常、リポジトリルートURLにはスラッシュは不要ですが、サーバー設定によります。

確認方法:

  • エラーメッセージや使用したコマンドラインのURLを目視で確認。
  • 可能であれば、SVNサーバーの管理者から正しいURLを再度教えてもらう。
  • 作業コピーで発生した場合は、作業コピーのディレクトリで svn info コマンドを実行し、URL: フィールドに表示されるURLが正しいか確認する。
  • HTTP/HTTPSリポジトリの場合、ウェブブラウザでそのURLにアクセスしてみる。通常、mod_dav_svnが設定されていれば、リポジトリの内容がブラウザで参照できるはずです。ブラウザでアクセスできない場合、サーバー設定やネットワークに問題がある可能性が高まります。

ステップ2：基本的なネットワーク接続の確認

URLが正しいように見える場合、次にクライアントマシンからSVNサーバーへの基本的なネットワーク接続を確認します。

  1. Pingコマンド: SVNサーバーのホスト名またはIPアドレスに対してpingを実行します。
    • コマンド例: ping svn.example.com または ping 192.168.1.100
    • 応答があるか、パケットロスがないかを確認します。pingが失敗する場合、ネットワーク経路上の問題（サーバー停止、ルーティング問題、基本ネットワーク接続の断絶）を示唆します。
  2. TelnetまたはNetcatコマンド (ポートの到達性確認): SVNが使用するポートに対してtelnetまたはncで接続を試みます。
    • HTTP: ポート80 – telnet svn.example.com 80
    • HTTPS: ポート443 – telnet svn.example.com 443
    • SVNプロトコル: ポート3690 – telnet svn.example.com 3690
    • 接続が成功すると、多くの場合、画面がクリアされるか、サーバーからの応答（HTTPの場合はヘッダー情報の一部など）が表示されます。すぐに「Connection refused」や「Connection timed out」となる場合、サーバーが指定ポートでリスニングしていない、またはファイアウォールによってブロックされている可能性が非常に高いです。(telnetやncがインストールされていない場合は、OSに付属の代替ツールやPowerShellのTest-NetConnectionなどを使用します。)
  3. DNS解決の確認: ホスト名を使用している場合、そのホスト名が正しくIPアドレスに解決されているか確認します。
    • コマンド例: nslookup svn.example.com (Windows/Linux) または dig svn.example.com (Linux/macOS)
    • 表示されるIPアドレスが正しいか確認します。間違っている場合、DNSサーバーの設定やキャッシュに問題がある可能性があります。
  4. traceroute/tracertコマンド (経路確認): クライアントからサーバーまでのネットワーク経路を確認します。
    • コマンド例: traceroute svn.example.com (Linux/macOS) または tracert svn.example.com (Windows)
    • パケットがどのルーターを経由しているか、どこで通信が途絶えているかを確認できます。特定のホップで応答がなくなる場合、その地点（またはその直後）のネットワーク機器やファイアウォールに問題がある可能性が考えられます。

ステップ3：ファイアウォールとプロキシの設定確認

ネットワーク接続の基本的な確認で問題が見つからない場合、ファイアウォールやプロキシが通信を妨げている可能性を検討します。

  1. クライアント側のファイアウォール:
    • Windows Firewall, macOS Firewall, Linux (iptables, firewalld), セキュリティソフトのファイアウォール設定を確認します。
    • SVNクライアント（svn.exeやTortoiseSVNなど）のネットワークアクセスが許可されているか、またはSVNが使用するポート（80, 443, 3690など）への発信接続が許可されているか確認します。
    • 一時的にファイアウォールを無効にして、問題が解決するかテストします（セキュリティ上のリスクを理解した上で、短時間のみ実行し、テスト後は必ず再度有効にすること）。
  2. サーバー側のファイアウォール: (サーバー管理者に確認が必要です)
    • サーバーOSのファイアウォール設定（iptables, firewalld, Windows Firewallなど）を確認し、クライアントのIPアドレスまたはネットワークレンジからのSVNポートへの受信接続が許可されているか確認します。
    • サーバーのネットワーク機器（ルーター、ファイアウォールアプライアンス）の設定を確認し、SVN通信がブロックされていないか確認します。
  3. 中間にあるネットワーク機器のファイアウォール: (ネットワーク管理者に確認が必要です)
    • 企業ネットワークの場合、部門間のファイアウォールやインターネット接続ゲートウェイのファイアウォールがSVN通信をブロックしている可能性があります。
  4. プロキシ設定:
    • SVNクライアント自体のプロキシ設定を確認します。TortoiseSVNでは設定画面、コマンドラインクライアントでは構成ファイル (~/.subversion/servers や %APPDATA%\Subversion\servers) の [global] セクションやプロトコル別セクション ([http-proxy], [svn-proxy]) を確認します。
    • OSのネットワークプロキシ設定を確認します。特にHTTP/HTTPSを使用している場合、SVNクライアントがOSのプロキシ設定を参照することがあります。
    • プロキシ経由でのアクセスが必須の場合、プロキシサーバーのアドレス、ポート、認証情報が正しいか確認します。
    • 可能であれば、一時的にプロキシ設定を無効にして、直接接続を試みます（直接接続が可能なネットワーク環境の場合）。

ステップ4：SVNサーバーの状態と設定の確認 (サーバー管理者の作業)

クライアント側やネットワークの基本的な問題が見つからない場合、SVNサーバー自体に問題がある可能性が高まります。これ以降のステップは、通常、SVNサーバーの管理者が行う必要があります。

  1. SVNサービスの状態確認:
    • Apache (httpd) または svnserve プロセスがサーバー上で実行されているか確認します。OSのサービス管理ツール (systemctl status httpd, service svnserve status, Windows Services Managerなど) やプロセスリスト (ps aux | grep svn, tasklist | findstr httpd) で確認します。
    • サービスが停止している場合は、起動を試みます。起動に失敗する場合は、サーバーのシステムログやSVNサービスのログを確認し、原因を特定します。
  2. SVNサーバー設定ファイルの確認:
    • Apacheを使用している場合: httpd.conf およびSVN関連の設定ファイル（extra/subversion.confなど）を開き、
      • LoadModule dav_svn_module modules/mod_dav_svn.so および LoadModule authz_svn_module modules/mod_authz_svn.so がコメントアウトされずにロードされているか。
      • リポジトリへのLocationディレクティブの設定が正しいか。特にSVNPathまたはSVNParentPathの指定が、サーバー上の実際のリポジトリディレクトリのパスと一致しているかを確認します。
      • 例: <Location /repos/myproject> … SVNPath /path/to/your/repos/myproject … </Location>
      • 必要に応じて、Apacheの設定ファイルを再読み込みまたはApacheサービスを再起動します。
    • svnserveを使用している場合: svnserveの起動オプションで指定されているリポジトリパスが正しいか確認します。また、リポジトリディレクトリ内のconf/svnserve.confファイルを開き、anon-access, auth-access, authz-db, password-dbなどの設定が適切か確認します。特に、anon-access = none となっていて、認証なしでアクセスしようとしている場合は当然アクセスできません。
  3. リポジトリディレクトリの存在確認と権限:
    • サーバー上のファイルシステムで、設定ファイルに記述されているリポジトリディレクトリ（SVNPathやSVNParentPathで指定された場所）が実際に存在するか確認します。
    • SVNサービスを実行しているユーザー（Apacheの場合は通常apacheやwww-data、svnserveの場合は起動ユーザー）が、そのリポジトリディレクトリおよびその配下のファイル/ディレクトリに対して適切な読み書き権限を持っているか確認します。ファイルシステムの権限設定（chown, chmod）を確認・修正します。
  4. サーバーリソースの確認:
    • サーバーのCPU使用率、メモリ使用量、ディスクI/O、ネットワーク帯域などが限界に達していないか確認します。リソース不足は、SVNリクエストに応答できなくなる原因となります。
  5. サーバーログの確認:
    • Apacheのエラーログ (error_log) やアクセスログ (access_log) を確認します。SVNクライアントからの接続試行に関するエラーや、サーバー内部で発生したエラーメッセージが記録されている可能性があります。
    • svnserveを使用している場合は、svnserveの起動時に指定したログファイルや、システムのログ (/var/log/syslog など) を確認します。

ステップ5：認証・認可設定の確認 (サーバー管理者の作業)

リポジトリが存在し、サーバーも正常に稼働しているにも関わらずエラーが発生する場合、認証や認可の設定が原因の可能性があります。

  1. 認証情報の確認:
    • クライアントが使用しているユーザー名とパスワードが正しいか確認します。特にパスワードは有効期限が切れていないか、またはCapsLockがオンになっていないかなども確認します。
    • TortoiseSVNなどのGUIクライアントを使用している場合、保存されている認証情報が古くなっている可能性があります。設定から保存された認証情報をクリアして、再度入力し直してみます。コマンドラインクライアントでも、--username オプションを付けてユーザー名を明示的に指定したり、キャッシュされた認証情報ファイルを削除したりできます (~/.subversion/auth/svn.simple/ や %APPDATA%\Subversion\auth\svn.simple\)。
    • Windows Credential Managerに保存されている該当リポジトリの認証情報を削除して、再度入力を促してみます。
  2. サーバー側の認証設定:
    • Apacheの場合、<Location> ディレクティブ内で AuthType, AuthName, AuthUserFile/AuthDBMUserFile, Require valid-user などの設定が正しく行われているか確認します。認証ファイル (AuthUserFileで指定されたファイル) が存在し、ユーザー情報が含まれているか確認します。
    • svnserveの場合、conf/svnserve.conf の anon-access, auth-access, password-db の設定を確認します。password-dbで指定されたファイルが存在し、ユーザー情報が含まれているか確認します。
  3. サーバー側の認可設定 (authz):
    • Apacheまたはsvnserveの設定で指定されている認可ファイル (authz-dbで指定されたファイル) を確認します。
    • このファイルには、リポジトリ内の特定のパスに対するユーザーやグループのアクセス権限 (r=読み取り, w=書き込み, 空白=アクセスなし) が定義されています。
    • クライアントがアクセスしようとしているリポジトリのパスに対して、使用しているユーザーまたはそのユーザーが所属するグループに最低限の読み取り権限 (r) が付与されているか確認します。
    • E170013は、指定したリポジトリパス自体に対するアクセスが許可されていない場合に発生しやすいです。例えば、/ に対する権限がなく、特定のリポジトリのパス (/repos/myproject) にのみ権限がある場合でも、サーバー側の設定によっては、SVNParentPath を使っている場合に問題が発生することがあります。authz ファイルの設定を細部まで確認します。

ステップ6：SSL/TLS 証明書の問題 (HTTPSアクセスの場合)

HTTPSでアクセスしていて、特にブラウザではアクセスできるのにSVNクライアントでエラーが出る場合や、最近証明書を更新した後に発生した場合は、SSL/TLS証明書関連の問題を疑います。

  1. サーバー証明書の有効性確認: ウェブブラウザでリポジトリURLにアクセスし、証明書が有効であるか（鍵マークが緑色かなど）、有効期限が切れていないか、発行元が信頼できるか、証明書に記載されたホスト名（Common NameやSubject Alternative Names）がアクセスしているURLのホスト名と一致しているかを確認します。
  2. 中間証明書チェーンの確認: SSLチェッカーツール（例: SSL Shopper’s SSL Checker）を使って、サーバー証明書の中間証明書チェーンが正しく設定されているか確認します。中間証明書が不足していると、一部のクライアントやOSでは証明書を信頼できません。
  3. 自己署名証明書の扱い: 自己署名証明書を使用している場合、SVNクライアントがデフォルトでそれを信頼しないためエラーになります。
    • コマンドラインクライアントの場合、初めて接続する際に証明書情報が表示され、信頼するかどうか尋ねられます。そこで t (一時的に信頼) または p (永続的に信頼) を選択する必要があります。E170013が出る前に、証明書に関する別のエラーや警告が出ていないか確認してください。
    • TortoiseSVNの場合も同様にダイアログが表示されます。永続的に受け入れたはずなのに問題が再発する場合、クライアント側の証明書キャッシュが壊れている可能性があります。
  4. クライアント側の証明書キャッシュのクリア: コマンドラインクライアントの場合、~/.subversion/auth/svn.ssl.server/ や %APPDATA%\Subversion\auth\svn.ssl.server\ ディレクトリ内のファイルを削除してみます。これにより、次回接続時に改めて証明書を受け入れるか尋ねられます。TortoiseSVNでも設定画面からキャッシュをクリアできる場合があります。
  5. SSL/TLSプロトコルバージョンの確認: サーバー側で古いTLSバージョン（TLSv1.0, TLSv1.1）が無効化され、新しいバージョン（TLSv1.2, TLSv1.3）のみが有効になっている場合、古いSVNクライアントやOSでは接続できないことがあります。サーバー側またはクライアント側で有効なTLSバージョンを確認します。
  6. SSLクライアント証明書 (双方向認証の場合): サーバーがクライアント証明書を要求する設定になっている場合、正しいクライアント証明書がクライアントマシンにインストールされており、SVNクライアントがそれを提示できているか確認します。

ステップ7：クライアント側の環境問題への対処

上記のステップで問題が解決しない場合、クライアント側のSVN環境自体に目を向けます。

  1. SVNクライアントのアップデート: 使用しているSVNクライアント（コマンドラインツールやGUIツール）が最新版であるか確認します。古いバージョンには既知のバグがあったり、新しいサーバー機能やプロトコルに対応していなかったりする可能性があります。最新版にアップデートすることで問題が解決することがあります。
  2. SVNクライアント設定のリセット: SVNクライアントのローカル設定ファイル（~/.subversion/config, %APPDATA%\Subversion\config など）が破損している可能性があります。これらのファイルを一時的に別の場所に移動またはリネームして、SVNクライアントがデフォルト設定で起動するか試します。設定ファイルに記述ミスがある場合も同様です。
  3. Windows Credential Managerの確認: Windowsを使用している場合、Credential Managerに保存されたSVN関連のエントリを確認し、必要に応じて削除します。
  4. VPN接続の確認: VPN経由でSVNリポジトリにアクセスしている場合、VPNクライアントが正しく動作しているか、VPNの設定がSVN通信を許可しているか確認します。VPNを切断した状態で、社内ネットワークなどからのアクセスが可能であれば、VPN自体に問題がある可能性が高いです。
  5. 一時的なファイルやキャッシュのクリア: SVNクライアントによっては、一時ファイルやキャッシュを保持しています。これらをクリアすることで、状態がリセットされて問題が解消されることがあります。

ステップ8：SVN管理者またはネットワーク管理者への連携

上記の全てのステップを試しても問題が解決しない場合、問題はSVNサーバー自体、サーバー側のネットワーク設定、または組織全体のネットワークインフラストラクチャにある可能性が非常に高いため、SVNサーバー管理者やネットワーク管理者に協力を依頼します。

  • これまでに試したトラブルシューティングステップと、それによって得られた情報（pingの結果、telnetの結果、ブラウザでのアクセス可否、エラーメッセージの全文など）を正確に伝えます。
  • 管理者側で、サーバーのログの詳細な分析、ネットワークトラフィックのキャプチャと解析、サーバー設定の再確認など、より高度な調査を行ってもらう必要があります。

4. エラー E170013 の予防策

一度エラーが発生すると、原因特定と解決に時間がかかることがあります。将来的にE170013エラーの発生リスクを低減するためには、いくつかの予防策を講じることが有効です。

  1. リポジトリURLの正確な管理と共有:
    • プロジェクトで使用するリポジトリURLは、ドキュメントなどに正確に記載し、開発者間で共有します。コピペ可能な形で提供することで、手入力によるスペルミスを防ぎます。
    • リポジトリのURLが変更される場合は、関係者全員に速やかに通知し、必要に応じて作業コピーのURLを切り替える手順（svn switch --relocate）を共有します。
  2. SVNサーバーの状態監視:
    • SVNサーバーが常に稼働しているか（Apache/svnserveプロセスの監視）、サーバーのリソース（CPU, メモリ, ディスク容量, ネットワーク）に余裕があるかなどを監視するシステムを導入します。異常が発生したら早期に検知し対処することで、サービス停止によるアクセスエラーを防ぎます。
  3. ネットワーク構成の明確化:
    • SVNサーバーへのアクセス経路（使用するポート、経由するファイアウォール、プロキシの有無など）を明確にし、開発者や管理者がネットワークの問題を切り分けやすいようにします。ファイアウォールルールの変更などを行う際は、SVN通信への影響を考慮します。
  4. ファイアウォールルールの適切な管理:
    • SVNサーバーへのアクセスに必要なポートが開いていることを、サーバー側、クライアント側、および中間ネットワーク機器の全てで確認・維持します。セキュリティポリシーの変更があった際も、SVN通信への影響を確認します。
  5. 認証・認可設定の定期的な見直し:
    • ユーザーの追加・削除、プロジェクトの変更などに合わせて、認証ファイル (passwd) や認可ファイル (authz) の設定を適切に更新・管理します。不要なユーザーアカウントを削除したり、アクセス権限を最小限にしたりすることはセキュリティ上も重要です。
  6. SSL証明書の適切な管理 (HTTPS使用時):
    • サーバー証明書の有効期限を管理し、期限切れ前に更新します。信頼された認証局から発行された証明書を使用し、中間証明書チェーンも正しく設定します。
  7. SVNクライアントとサーバーのバージョン管理:
    • サーバーおよびクライアントのSVNソフトウェアを、セキュリティパッチやバグ修正が適用された最新の安定版にアップデートすることを検討します。ただし、大規模なバージョンアップは互換性の問題を引き起こす可能性もあるため、計画的に行い、事前にテストすることが重要です。
  8. ドキュメントの整備:
    • SVNリポジトリへのアクセス方法、必要な認証情報、推奨されるクライアントソフトウェアと設定、よくある問題とその対処法などをドキュメント化し、チームメンバーが参照できるようにしておきます。

これらの予防策を実施することで、E170013のようなリポジトリアクセスエラーが発生するリスクを低減し、万が一発生した場合でも迅速に原因を特定し対処できるようになります。

5. よくある疑問と補足情報

5.1. エラーメッセージに他の情報が含まれている場合

E170013エラーメッセージには、原因特定のヒントとなる追加情報が含まれていることがあります。例えば、

  • svn: E170013: Unable to connect to a repository at URL '...' (最も一般的)
  • svn: E170013: '...' is not a repository (URLは存在するが、そこにSVNリポジトリがない/認識されない)
  • svn: E170013: No repository found in '...' (SVNParentPath設定などで、指定パス以下にリポジトリが見つからない)
  • svn: E170013: OPTIONS of '...': could not connect to server (http://...) (HTTP/HTTPSアクセスで、基盤となるネットワーク接続に問題があることを示唆)

これらの追加情報を注意深く読むことで、ネットワーク接続の問題なのか、それともサーバー側の設定でリポジトリが正しく認識されていないのかなど、原因の絞り込みに役立ちます。特にcould not connect to serverというメッセージは、ステップ2やステップ3のネットワーク/ファイアウォール関連の問題を強く示唆します。

5.2. コマンドラインクライアントとGUIクライアントの違い

TortoiseSVNのようなGUIクライアントとコマンドラインクライアント (svn) では、エラーメッセージの表示方法や設定の場所が異なります。しかし、根本的なエラー原因や対処法は同じです。

  • コマンドライン: エラーメッセージがコンソールに直接表示され、詳細な情報が含まれていることが多いです。設定はテキストファイル (~/.subversion/ や %APPDATA%\Subversion\) で行います。
  • GUIクライアント (TortoiseSVNなど): エラーがダイアログボックスで表示されます。詳細なエラー情報は別途ログファイルやダイアログ内の詳細ボタンから確認できることがあります。設定は専用のGUI画面で行います。保存された認証情報もGUIから管理できます。

どちらのクライアントを使用している場合でも、本記事で解説した基本的なトラブルシューティング手順（URL確認、ping、telnet、ファイアウォール、サーバー状態など）は共通して適用可能です。可能であれば、コマンドラインクライアントを使ってアクセスを試みることで、より詳細なエラーメッセージやネットワーク関連のデバッグ情報を得やすい場合があります。svn --verbose --non-interactive <command>のように--verboseオプションを付けると、より多くのデバッグ情報が表示されることがあります。

5.3. 作業コピーのURL切り替え (svn switch --relocate)

作業コピーに対してE170013エラーが発生する場合、その作業コピーが参照しているリポジトリURLが間違っている、またはリポジトリの場所がサーバー側で変更された可能性があります。

このような場合、作業コピー全体を削除してチェックアウトし直すのではなく、svn switch --relocateコマンドを使って、作業コピーが参照するリポジトリURLを変更できます。

  • svn switch --relocate <現在のリポジトリURL> <新しいリポジトリURL>
  • 例: svn switch --relocate http://old.example.com/repos/myproject http://new.example.com/svn/myproject

ただし、--relocateはリポジトリ内のパス構造が変わっていない場合に使用します。リポジトリ名自体が変わった、親パスが変わったなどの場合に有効です。リポジトリ内のパス構造（例: /trunk以下の構成）自体が変わった場合は、単なるsvn switchや、場合によってはチェックアウトし直しが必要になります。

svn infoコマンドで現在の作業コピーのリポジトリURLを確認し、必要に応じてこのコマンドを検討してください。しかし、E170013エラーは、svn switch --relocateを実行しようとした際にも、新しいURLまたは古いURLにアクセスできない場合に発生する可能性があります。

5.4. サーバー側の構成例 (Apache + mod_dav_svn)

E170013エラーの原因としてサーバー側の設定誤りが多いため、Apache (mod_dav_svn) を使用する場合の典型的な設定例を理解しておくと、管理者との連携や設定ファイル確認の際に役立ちます。

Apacheの設定ファイル (httpd.conf や別途読み込まれるconfファイル) には、通常以下のような記述があります。

“`apache
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

リポジトリへのアクセス設定


DAV svn
# 単一のリポジトリを指定する場合
SVNPath /path/to/your/repos/myproject

# または、複数のリポジトリを管理する場合 (URLの最後の部分がリポジトリ名になる)
# SVNParentPath /path/to/your/repos/

# 認証設定
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /path/to/your/passwdfile # htpasswd で作成したユーザーファイル
Require valid-user # 有効なユーザーであること

# 認可設定 (オプション)
# AuthzSVNAccessFile /path/to/your/authzfile # authz ファイル

# その他の設定 (HTTPS化など)
# SSLRequireSSL # HTTPS接続を必須にする


“`

E170013が発生する場合、<Location> ディレクティブのパス (/svn/myproject) と、SVNPath または SVNParentPath で指定されたサーバー上の物理パスが一致しているか、LoadModule が正しく行われているか、Apacheがリポジトリディレクトリへのファイルシステム権限を持っているかなどを確認することが重要です。

6. まとめ

SubversionのE170013エラーは、主にクライアントが指定したリポジトリURLにアクセスできなかったり、その場所に有効なSVNリポジトリが見つからなかったりする場合に発生するネットワーク/リポジトリ関連のエラーです。その原因は、単純なURLの入力ミスから、複雑なネットワーク設定、ファイアウォールのブロック、プロキシの問題、サーバー側のSVNサービスや設定の誤り、認証・認可の問題、さらにはSSL証明書の問題まで、非常に多岐にわたります。

このエラーに効果的に対処するためには、以下のステップで系統的に調査を進めることが鍵となります。

  1. リポジトリURLの徹底的な確認: 最も可能性の高い原因です。一文字一句、プロトコルも含めて正しいか確認します。
  2. 基本的なネットワーク接続の確認: ping, telnet/nc, DNS lookupなどで、クライアントからサーバーへの到達性を確認します。
  3. ファイアウォールとプロキシの設定確認: クライアント側、サーバー側、中間ネットワーク機器のファイアウォールや、クライアント・OS・SVNクライアントのプロキシ設定を確認します。
  4. SVNサーバーの状態と設定の確認: SVNサービスが稼働しているか、サーバー側の設定ファイル（Apacheやsvnserve）が正しいか、リポジトリディレクトリが存在し権限が適切かなどをサーバー管理者と連携して確認します。
  5. 認証・認可設定の確認: 使用している認証情報が正しいか、サーバー側の認証・認可設定でアクセスが許可されているか確認します。
  6. SSL/TLS証明書の問題確認 (HTTPSの場合): 証明書が有効か、中間証明書が正しく設定されているか、クライアントが証明書を信頼しているかなどを確認します。
  7. クライアント側の環境問題への対処: SVNクライアントのバージョン、設定ファイル、キャッシュなどを確認します。

これらのステップを順に実施することで、問題の原因を特定し、適切な対処を行うことができます。多くの場合、エラーの原因は上記いずれかのカテゴリに分類されるはずです。

また、将来的なエラー発生を防ぐために、リポジトリURLの正確な管理、サーバー状態の監視、ネットワーク構成の明確化、適切なアクセス権限管理、SSL証明書の管理、そしてソフトウェアの適切なアップデートといった予防策を講じることが推奨されます。

E170013エラーは一見すると難解に感じられるかもしれませんが、その多くはネットワーク接続またはリポジトリへのパス指定に関する基本的な問題に起因しています。本記事で解説した詳細な原因と対処法を参考に、冷静に一つずつ確認していくことで、必ず問題を解決できるはずです。もし自分自身でサーバー側の確認ができない場合は、遠慮なくSVN管理者やネットワーク管理者に状況を説明し、協力を仰ぎましょう。円滑なバージョン管理のためにも、エラー発生時には原因を特定し、再発防止策を検討することが重要です。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール