Databricks Git フォルダーのエラーのトラブルシューティング

このページでは、リモート Git プロバイダーで Azure Databricks Git フォルダーを使用する場合の一般的なエラーと予期しない動作について説明します。これは、原因をより迅速に特定できるようにカテゴリ別にグループ化されています。 ここでのガイダンスで問題が解決しない場合は、「 ヘルプを表示する」を参照してください。

認証エラー

これらのエラーは、Azure Databricksがリモート Git プロバイダーで ID を確認できない場合に発生します。

Invalid credentials

次の操作を試してみてください。

  • Git 統合設定 ([設定]>[リンクされたアカウント]) が正しいことを確認します。 Git プロバイダーのユーザー名とトークンの両方を入力する必要があります。

  • 設定>リンクされたアカウントで正しい Git プロバイダーを選択したことを確認します。

  • 個人用アクセス トークンまたはアプリ パスワードが正しいリポジトリ アクセス権を持っていることを確認します。

  • Git プロバイダーで SSO が有効になっている場合は、SSO のトークンを承認します。

  • Git コマンド ラインを使用してトークンをテストします。 山かっこで囲まれたテキスト文字列を置き換えます。

    git clone https://<username>:<personal-access-token>@github.com/<org>/<repo-name>.git

SSL 接続エラー

<link>: Secure connection to <link> could not be established because of SSL problems

このエラーは、Azure Databricksが HTTPS 経由で Git サーバーに到達できない場合に発生します。 通常は、組織の Git インフラストラクチャでのネットワーク接続の問題または TLS 証明書の問題を示します。

Azure Databricks アカウント チームに連絡する前に、次の情報を準備します。

  • Git サーバーの URL
  • サーバーが自己署名 CA 証明書とプライベート CA 証明書のどちらを使用しているか
  • 同じワークスペース内の他のユーザーに同じエラーが表示されるかどうか

Microsoft Entra ID 資格情報エラー

Encountered an error with your :re[ms-entra-id] credentials. Try logging out of :re[ms-entra-id] and logging back in.

このエラーは、組織が最近多要素認証 (MFA) ポリシーを有効にした場合に発生する可能性があります。 MFA の適用が有効になると、既存のMicrosoft Entra ID セッションが新しい認証要件を満たせず、接続が失敗する可能性があります。

このエラーを解決するには:

  1. portal.azure.com に移動し、Microsoft Entra IDからログアウトします。
  2. もう一度ログインします。 MFA を完了するためのプロンプトが表示されます。

それでも問題が解決しない場合は、再度ログインする前に、すべてのAzureサービスからログアウトしてください。

リポジトリの状態エラー

これらのエラーは、ローカル Git フォルダーが通常の操作を妨げる状態に達したときに発生します。

ヘッド分離状態

Git では、"head" はコミット履歴内の現在の位置を指し、通常は分岐を指します。 ヘッドがブランチではなく特定のコミットを直接指している場合、リポジトリは "デタッチされたヘッド" 状態になります。 Git では、どのブランチでもこの状態で行われた変更は追跡されません。 最初に新しいブランチを作成せずに移動すると、それらの変更が失われる可能性があります。

Git フォルダーは、次の場合にデタッチされたヘッド状態に入ることができます。

  • だれかがリモート ブランチを削除します。 Azure Databricksは、コミットされていないローカル変更を既定のブランチに適用して回復しようとします。 競合する変更がある場合、Azure Databricksは既定のブランチのスナップショットに適用され、その結果、ヘッドがデタッチされます。
  • ユーザーまたはサービス プリンシパルは、 update repo API を使用してタグをチェックアウトします。

この状態から復旧するには、次の手順を行います。

  1. [ ブランチの作成 ] をクリックして現在のコミットからブランチを作成するか、ブランチを 選択 して既存のブランチをチェックアウトします。
  2. コミットしてプッシュし、変更を保存します。 変更を破棄するには、 Kebab メニュー アイコン をクリックします。 [変更] の下の [Kebab] メニューをクリックします。

一貫性のないリポジトリの状態

There was a problem with deleting folders. The repo could be in an inconsistent state and re-cloning is recommended.

このエラーは、フォルダーの削除中に問題が発生したことを示します。 リポジトリが不整合な状態になりました。 リポジトリを削除して再複製し、その状態をリセットします。

ノートブック名の競合

同一または類似のファイル名を持つノートブックでは、リポジトリまたは pull request を作成するときにエラーが発生する可能性があります。

Cannot perform Git operation due to conflicting names

A folder cannot contain a notebook with the same name as a notebook, file, or folder (excluding file extensions).

名前付けの競合は、異なるファイル拡張子でも発生する可能性があります。 たとえば、次の 2 つのファイルは競合します。

  • notebook.ipynb
  • notebook.py

図: ノートブック、ファイル、またはフォルダーの名前の競合。

競合を解決するには、エラー状態の原因となるノートブック、ファイル、またはフォルダーの名前を変更します。 リポジトリを複製するときにエラーが発生した場合は、リモート Git リポジトリ内のノートブック、ファイル、またはフォルダーの名前を変更します。

予期しない動作

これらの問題は明確なエラー メッセージを生成しませんが、調査が必要な問題の兆候です。

タイムアウトエラー

大規模なリポジトリの複製や大規模なブランチのチェックアウトなどの操作では、タイムアウト エラーが発生する可能性があります。 タイムアウト後も、バックグラウンドで操作が完了する可能性があります。

タイムアウト エラーが表示された場合:

  1. 数分待ってから、Git フォルダーを更新します。 予想されるファイルまたはブランチが存在する場合、操作は正常に完了しました。
  2. ワークスペースの負荷が高い場合は、負荷が減少した後に操作を再試行してください。

大規模なリポジトリでのタイムアウトを回避するには、 スパース チェックアウト を使用して、必要なファイルのみを操作します。

404 エラー

ノートブック以外のファイルを開いたときに 404 エラーが発生した場合は、数分待ってからやり直してください。 システムがワークスペースを有効にしてから、Web アプリが構成を取得するまでの間に、少しの遅延があります。

ユーザーの編集なしでノートブックが変更された状態で表示される

ユーザーが編集せずにノートブックのすべての行が変更された場合は、行末の違いが原因である可能性があります。 Azure Databricksでは Linux スタイルの行末 (LF) が使用されます。これは、Windows システム (CRLF) でコミットされたファイルとは異なる場合があります。

この問題を診断するには、 .gitattributes ファイルがあるかどうかを確認します。

  • * text eol=crlfを含めることはできません。
  • Windows を使用していない場合は、この設定を削除します。 開発環境と Azure Databricks はどちらも Linux の改行コードを使用します。
  • Windows を使用している場合は、設定を * text=auto に変更します。 その後、Git は Linux スタイルの行末を含むファイルを内部的に格納しますが、プラットフォーム固有の行の末尾で自動的にチェックアウトします。

Windows行末文字を含むファイルを既に Git にコミットしている場合:

  1. 未処理の変更をすべてクリアします。
  2. 上記の説明に従って、 .gitattributes ファイルを環境に合わせて更新します。
  3. 変更をコミットします。
  4. git add --renormalize を実行します。 すべての変更をコミットしてプッシュします。

削除されたファイルを回復する

ファイルの回復可能性は、アクションによって異なります。 一部のアクションでは ごみ箱 フォルダーを通じて回復が許可されますが、そうでないアクションもあります。 以前にコミットされ、リモート ブランチにプッシュされたファイルを復元するには、リモート リポジトリの Git コミット履歴を使用します。

アクション ファイルは回復可能ですか?
ワークスペース ブラウザーでファイルを削除する はい。 Trash フォルダーから
[Git フォルダー] ダイアログで新しいファイルを破棄する はい。 Trash フォルダーから
[Git フォルダー] ダイアログで変更したファイルを破棄する いいえ、ファイルは削除されています
reset (ハード) コミットされていないファイル変更の場合 いいえ、ファイルの変更は行われません
reset (ハード) コミットされていない新しく作成されたファイルの場合 いいえ、ファイルの変更は行われません
Git フォルダー ダイアログでブランチを切り替える はい(リモート Git リポジトリから)
Git フォルダー ダイアログからのその他の Git 操作 (コミットやプッシュなど) はい(リモート Git リポジトリから)
PATCH Repos API から /repos/id を更新する操作 はい(リモート Git リポジトリから)

ヘルプを取得する

このページのガイダンスで問題が解決しない場合は、Azure Databricksサポートにお問い合わせください。 サポートに問い合わせる場合は、次の情報を含めます。

  • 正確なエラー メッセージ
  • Git プロバイダーの名前と、リポジトリがパブリックかプライベートか
  • 問題がすべてのユーザーに影響するか、ワークスペース内の一部のユーザーにのみ影響するか
  • 既に試した手順
  • Last updated on