{"meta":{"title":"Problemlösung bei der Migration mit GitHub Enterprise Importer","intro":"Wenn bei der Migration ein Fehler auftritt oder unerwartete Ergebnisse auftreten, kannst du die üblichen Schritte zur Problembehandlung ausprobieren.","product":"Migrationen","breadcrumbs":[{"href":"/de/migrations","title":"Migrationen"},{"href":"/de/migrations/troubleshooting","title":"Problembehandlung bei Migrationen"},{"href":"/de/migrations/troubleshooting/troubleshooting-your-migration-with-github-enterprise-importer","title":"Problembehandlung bei Migrationen"}],"documentType":"article"},"body":"# Problemlösung bei der Migration mit GitHub Enterprise Importer\n\nWenn bei der Migration ein Fehler auftritt oder unerwartete Ergebnisse auftreten, kannst du die üblichen Schritte zur Problembehandlung ausprobieren.\n\n## Informationen zu den Schritten zur Problembehandlung für GitHub Enterprise Importer\n\nWenn bei der Migration ein Fehler auftritt oder unerwartete Ergebnisse erzielt werden, führe die unten aufgeführten ersten Schritte zur Problembehandlung aus, mit denen in der Regel viele Probleme behoben werden können. Wenn diese ersten Schritte dein Problem nicht beheben, suche in den Protokollen für deine Migration nach Fehlermeldungen. Suche dann in diesem Artikel nach der Fehlermeldung, und probiere die Schritte zur Lösung aus.\n\nWenn Sie Ihr Problem nach dem Ausprobieren der Schritte zur Problembehandlung für die Fehlermeldung nicht beheben können, können Sie sich an wenden GitHub-Support.\n\n## Erste Schritte zur Problembehandlung\n\nBevor du weitere Untersuchungen durchführst, führe die folgenden Schritte zur Problembehandlung aus, mit denen in der Regel viele Problemen behoben werden können.\n\n1. Stellen Sie sicher, dass Sie die neueste Version der GitHub CLI Erweiterung verwenden, die Sie zum Migrieren verwenden. Wenn nicht, upgrade auf die neueste Version.\n\n2. Vergewissere dich, dass alle Zugriffsanforderungen erfüllt sind. Weitere Informationen findest du im entsprechenden Artikel für deinen Migrationspfad.\n\n   * [Zugriff verwalten](/de/migrations/ado/manage-access)\n   * [Verwalten des Zugriffs für eine Migration von Bitbucket Server](/de/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/managing-access-for-a-migration-from-bitbucket-server)\n   * [Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten](/de/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products)\n\n3. Versuche, die Migration erneut auszuführen. Einige Migrationsprobleme sind nur vorübergehend, sodass ein zweiter Versuch Abhilfe schaffen kann.\n\n4. Versuche, eine Migration in einem anderen Repository mit ähnlichen Daten auszuführen. Auf diese Weise kannst du feststellen, ob das Problem nur dieses Repository betrifft oder ein umfassenderes Problem mit der Datenform vorliegt.\n\nWenn das Problem durch diese Schritte nicht behoben wird, überprüfe das Migrationsprotokoll auf Fehlermeldungen. Welches Protokoll du überprüfen musst, hängt davon ab, ob die Migration fehlerhaft oder erfolgreich war.\n\n## Problembehandlung bei fehlerhaften Migrationsvorgängen\n\nWenn Ihre Migration fehlschlägt, überprüfen Sie die ausführlichen Protokolleinträge, die von der GitHub CLI für jede Migration erstellt wurden. Die Protokolldatei wird im selben Verzeichnis gespeichert, in dem du die Migration ausgeführt hast.\n\nDas Protokoll enthält eine Aufzeichnung der einzelnen Befehle, die Sie ausgegeben haben, sowie aller API-Anforderungen, die GitHub CLI in Reaktion darauf gemacht hat. Fehler und Fehlermeldungen stehen normalerweise am Ende des Protokolls.\n\n* [Die Migration konnte nicht ausgeführt werden.](#unable-to-run-migrations)\n* [Die Ressource wird durch die SAML-Richtlinien der Organisation geschützt.](#resource-is-protected-by-organization-saml-enforcement)\n* [Antwort `401 Unauthorized`](#401-unauthorized-response)\n* [Antwort `404 Not Found`](#404-not-found-response)\n* [Antwort `Archive generation failed`](#archive-generation-failed-response)\n* [\n  `cipher name is not supported` Fehler](#cipher-name-is-not-supported-error)\n* [\n  `Subsystem 'sftp' could not be executed` Fehler](#subsystem-sftp-could-not-be-executed-error)\n* [\n  `Source export archive... does not exist` Fehler](#source-export-archive-does-not-exist-error)\n* [\n  `Repository rule violations found` Fehler](#repository-rule-violations-found-error)\n* [\n  `Your push would publish a private email address` Fehler](#your-push-would-publish-a-private-email-address-error)\n\n### Die Migration konnte nicht ausgeführt werden.\n\nWenn ein Fehler wie `No access to createMigrationMutation` oder `Missing permissions` angezeigt wird, verfügt dein persönliches Konto nicht über den erforderlichen Zugriff für die Migration. Stelle sicher, dass du entweder Besitzer\\*in der Organisation bist oder dir die Migrationsrolle zugewiesen wurde. Weitere Informationen zum Zuweisen der Migrationsrolle finden Sie unter [Informationen zu GitHub Enterprise Importer](/de/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/about-github-enterprise-importer).\n\n> \\[!NOTE]\n> Wenn Sie zwischen GitHub-Produkten migrieren, stellen Sie sicher, dass Sie ein Organisationsinhaber sind oder Ihnen die Migrator-Rolle sowohl für die Quell- als auch für die Zielorganisation gewährt wurde.\n\n### Die Ressource wird durch die Durchsetzung von SAML seitens der Organisation geschützt.\n\nDieser Fehler weist darauf hin, dass ein personal access token-Element, das von Ihnen für die GitHub CLI bereitgestellt wurde, für die Verwendung mit SAML‑Single‑Sign‑On autorisiert werden muss. Weitere Informationen findest du unter [Autorisieren eines persönlichen Zugriffstokens für die Verwendung mit Single Sign-On](/de/enterprise-cloud@latest/authentication/authenticating-with-single-sign-on/authorizing-a-personal-access-token-for-use-with-single-sign-on).\n\n### `401 Unauthorized` Antwort\n\nFehler, die einen `401`-Statuscode enthalten, deuten in der Regel darauf hin, dass das personal access token-Element, das von Ihnen für die GitHub CLI bereitgestellt wurde, nicht die erforderlichen Berechtigungen hat. Überprüfen Sie die Bereiche der von Ihnen bereitgestellten personal access token. Weitere Informationen zu erforderlichen Bereichen findest du im entsprechenden Artikel für deinen Migrationspfad.\n\n* [Zugriff verwalten](/de/migrations/ado/manage-access)\n* [Verwalten des Zugriffs für eine Migration von Bitbucket Server](/de/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/managing-access-for-a-migration-from-bitbucket-server#required-scopes-for-personal-access-tokens)\n* [Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten](/de/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#required-scopes-for-personal-access-tokens)\n\n### `404 Not Found` Antwort\n\nFehler, die den Statuscode `404` enthalten, weisen meist auf einen Tippfehler in einem deiner Befehle hin. Überprüfe das Migrationsprotokoll auf den genauen Befehl, den du eingegeben hast, und suche im Quellrepository, in der Organisation oder im Projekt nach Tippfehlern.\n\n### `Archive generation failed` Antwort\n\nWenn Sie eine `Archive generation failed...`-Antwort erhalten, wenn Sie von GitHub Enterprise Server migrieren, ist Ihr Repository wahrscheinlich zu groß. Weitere Informationen zu Grenzwerten für die Repositorygröße findest du unter [Informationen zu Migrationen zwischen den GitHub-Produkten mit GitHub Enterprise Importer](/de/migrations/using-github-enterprise-importer/migrating-between-github-products/about-migrations-between-github-products#data-that-is-migrated-from-github-enterprise-server).\n\nVersuche zunächst, Releases von der Migration auszuschließen, indem du das Flag `--skip-releases` mit dem Befehl `migrate-repo` verwendest.\n\nWenn dies nicht funktioniert, empfehlen wir ein Upgrade auf GitHub Enterprise Server 3.8.0 oder höher. Wenn du kein Upgrade durchführen kannst, besteht eine andere Möglichkeit darin, deine Repositoryarchive mit `ghe-migrator` manuell zu generieren:\n\n1. Generiere ein Migrationsarchiv für dein Repository. Du solltest nur jeweils ein Repository gleichzeitig exportieren. Anweisungen finden Sie unter [Exportieren von Migrationsdaten aus Ihrem Unternehmen](/de/enterprise-server@3.22/migrations/using-ghe-migrator/exporting-migration-data-from-github-enterprise-server) in der GitHub Enterprise Server Dokumentation.\n2. Lade dein Migrationsarchiv in den Blobspeicheranbieter deiner Wahl hoch.\n3. Generieren Sie eine kurzlebige URL für Ihr Migrationsarchiv, auf das GitHub zugreifen kann, z. B. eine vorsignierte AWS S3-URL oder Azure Blob Storage SAS-URL.\n4. Rufe den Befehl `migrate-repo` mit den Flags `--git-archive-url` und `--metadata-archive-url` auf, die auf die URL deines Archivs aus dem vorherigen Schritt festgelegt sind.\n\n### `cipher name is not supported` Fehler\n\nWenn du bei einer Migration von Bitbucket Server eine Fehlermeldung wie `cipher name aes256-ctr for openssh key file is not supported` erhältst, verwendet dein privater SSH-Schlüssel ein nicht unterstütztes Verschlüsselungsverfahren. Weitere Informationen zu unterstützten Verschlüsselungsverfahren findest du unter [Verwalten des Zugriffs für eine Migration von Bitbucket Server](/de/migrations/using-github-enterprise-importer/migrating-from-bitbucket-server-to-github-enterprise-cloud/managing-access-for-a-migration-from-bitbucket-server#required-permissions-for-bitbucket-server).\n\nFühre den folgenden Befehl aus, um ein neues kompatibles SSH-Schlüsselpaar zu generieren:\n\n```shell copy\nssh-keygen -t ed25519 -Z aes256-cbc -C \"your_email@example.com\"\n```\n\nNachdem du ein neues SSH-Schlüsselpaar generiert hast, musst du den öffentlichen Schlüssel den `authorized_keys` der Bitbucket Server-Instanz hinzufügen, bevor du den Schlüssel verwenden kannst.\n\n### `Subsystem 'sftp' could not be executed` Fehler\n\nWenn du bei einer Migration von Bitbucket Server eine Fehlermeldung wie `Subsystem 'sftp' could not be executed` erhältst, ist SFTP auf deinem Server nicht aktiviert, oder dein Benutzerkonto verfügt nicht über SFTP-Zugriff.\n\nBitte kontaktieren Sie Ihren Serveradministrator oder Ihre Serveradministratorin und bitten Sie sie, den SFTP-Zugriff für Ihr Benutzerkonto zu aktivieren.\n\n### `Source export archive... does not exist` Fehler\n\nWenn Sie von Bitbucket Server migrieren und eine Fehlermeldung wie `Source export archive (/var/atlassian/application-data/bitbucket/shared/migration/export/Bitbucket_export_1.tar) does not exist` erhalten, sucht GitHub CLI das Migrationsarchiv an der falschen Stelle auf Ihrer Bitbucket Server-Instanz.\n\nUm dieses Problem zu beheben, lege das `--bbs-shared-home`-Argument für `gh bbs2gh migrate-repo` für deine Bitbucket Server-Instanz oder das freigegebene Basisverzeichnis des Rechenzentrums fest. Das standardmäßig freigegebene Basisverzeichnis ist `/var/atlassian/application-data/bitbucket/shared`, aber deine Konfiguration kann anders sein.\n\nDu kannst das gemeinsam genutzte Home-Verzeichnis in Bitbucket Server identifizieren.\n\n1. Navigiere zum Verwaltungsbereich deiner Bitbucket Server-Instanz oder deines Rechenzentrums.\n2. Klicken Sie in der Randleiste unter „System“ auf **Storage**.\n3. Zeige unter „Freigegebenes Verzeichnis“ den Speicherort des freigegebenen Basisverzeichnisses deines Servers an.\n\nWenn du das Bitbucket-Rechenzentrum im Clustermodus mit mehreren Knoten ausführst, wird dein freigegebenes Verzeichnis von Clusterknoten geteilt und sollte auf jedem Knoten an demselben Speicherort eingebunden werden.\n\n### `Repository rule violations found` Fehler\n\nWenn dir eine `Repository rule violations found`-Fehlermeldung wie z. B. `GH013: Repository rule violations found for refs/heads/main` angezeigt wird, liegt ein Konflikt zwischen den Daten im Ursprungsrepository und den Daten in den Regelsätzen vor, die in der Zielorganisation konfiguriert sind. Weitere Informationen findest du unter [Informationen zu Regelsätzen](/de/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets).\n\nDu kannst deine Regelsätze während der Migration vorübergehend deaktivieren oder den Umgehungsmodus oder die Umgehungsliste verwenden, um deine konfigurierten Regeln von der Migration auszuschließen. Weitere Informationen findest du unter [Verwalten von Regelsätzen für Repositorys in deiner Organisation](/de/enterprise-cloud@latest/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization).\n\n### `Your push would publish a private email address` Fehler\n\nWenn Sie den Fehler `Git source migration failed` mit `GH007: Your push would publish a private email address` erhalten, enthält die Git-Quelle, die Sie migrieren möchten, Commits, die von einer E-Mail-Adresse erstellt wurden, deren Push auf GitHub blockiert wurde. Weitere Informationen finden Sie unter [Pushes über die Befehlszeile blockieren, die Deine private E-Mail-Adresse offenlegen](/de/account-and-profile/how-tos/email-preferences/blocking-command-line-pushes-that-expose-your-personal-email-address).\n\nUm diesen Fehler zu beheben, kannst du entweder den Git-Verlauf neu schreiben, um die E-Mail-Adresse zu entfernen, oder die Einstellung „Befehlszeilen-Pushvorgänge blockieren, die meine E-Mail-Adresse verfügbar machen“ deaktivieren.\n\n## Verständnis von Warnungen im Migrationsprotokoll\n\nAuch wenn deine Migration erfolgreich ist, solltest du das Migrationsprotokoll weiterhin auf Warnungen überprüfen.\n\nWarnungen im Migrationsprotokoll verweisen auf bestimmte Elemente innerhalb des Repositorys, die nicht migriert werden konnten. Weitere Informationen findest du unter [Zugriff auf die Migrationsprotokolle von GitHub Enterprise Importer](/de/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/accessing-your-migration-logs-for-github-enterprise-importer).\n\n> \\[!NOTE]\n> Wenn das Issue „Migrationsprotokoll“ unten „Migration abgeschlossen“ enthält, wurde das Repository migriert. Warnungen weisen nur darauf hin, dass bestimmte Elemente innerhalb des Repositorys, z. B. ein Kommentar zu einem Pull Request, möglicherweise nicht ordnungsgemäß migriert wurden.\n\n* [Warnung: „Zu große Repositorymetadaten für die Migration“](#warning-repository-metadata-too-big-to-migrate)\n* [Warnung: „Kommentar nicht im Diff“](#warning-comment-not-in-diff)\n* [Warnung: „Überprüfung des Pull-Request-Reviews... konnte aufgrund des Fehlers REVIEW\\_THREAD\\_MISSING\\_END\\_COMMIT\\_OID nicht importiert werden“](#warning-pull-request-reviewcould-not-be-imported-due-to-review_thread_missing_end_commit_oid-error)\n* [Team-Referenzen sind nach einer Organisationsmigration defekt](#team-references-are-broken-after-an-organization-migration)\n\n### Warnung: „Zu große Repositorymetadaten für die Migration“\n\nWenn im Issue „Migrationsprotokoll“ oder in der GitHub CLI als Fehler zu große Repositorymetadaten angezeigt werden, überschreitet dein Repository die maximale Archivgröße von 10 GB. Dies wird häufig durch große Release-Assets verursacht. Versuche, Releases mit dem Flag `--skip-releases` für den Befehl `migrate-repo` von der Migration auszuschließen.\n\n### Warnung: „Kommentar nicht im Diff“\n\nWenn Sie von Azure DevOps migrieren, können Pullanforderungskommentare in Zeilen, die in der Pullanforderung nie geändert wurden, nicht zu GitHub migriert werden. Diese Warnung wird für jeden Kommentar angezeigt, der aus diesem Grund nicht migriert werden kann.\n\n> \\[!NOTE]\n> Nur Kommentare zu Zeilen, die in einem Pull Request nicht geändert wurden, sind von dieser Einschränkung betroffen. Kommentare auf Zeilen, die in einem Pull Request geändert wurden, werden migriert.\n\nDie betroffenen Kommentare sind zwar nicht im migrierten Repository enthalten, aber diese Warnungen erfordern keine weiteren Aktionen.\n\n### Warnung: „Überprüfung des Pull-Request-Reviews... konnte aufgrund des Fehlers REVIEW\\_THREAD\\_MISSING\\_END\\_COMMIT\\_OID nicht importiert werden“\n\nDiese Warnung tritt auf, wenn ein Pull-Request-Review nicht migriert werden konnte, da der Commit, an den die Überprüfung angefügt ist, nicht mehr vorhanden ist.\n\nDies geschieht in der Regel, wenn Commits mit einem erzwungenen Push entfernt wurden oder eine Verzweigung gelöscht wurde.\n\nIn diesem Fall gehen die Kommentare nicht verloren, sondern werden als Inline-Pull-Request-Kommentare migriert, um den Verlauf beizubehalten, anstatt als ein Request, der an einen bestimmten Commit angehängt ist.\n\n### Die Überprüfung der Pullanforderung wird als Inline-Pullanforderungskommentar importiert.\n\nDiese Warnungen deuten darauf hin, dass eine Pull-Request-Überprüfung nicht in ihrer ursprünglichen Form migriert werden konnte, sondern stattdessen als Inline-Kommentare innerhalb des Pull Requests:\n\n* `INVALID_REVIEW_THREAD`\n* `LINE_NOT_FOUND_IN_DIFF`\n* `REVIEW_THREAD_MISSING_BODY`\n\n### Nach einer Migration der Organisation sind Teamreferenzen fehlerhaft.\n\nVerweise auf Teams, z. B. `@octo-org/octo-team`, werden im Rahmen einer Organisationsmigration **nicht** aktualisiert. Dies kann zu Problemen in der Zielorganisation führen, da z. B. `CODEOWNERS`-Dateien nicht wie erwartet funktionieren.\n\nDu kannst diese Verweise entweder nach der Migration aktualisieren, oder du kannst die Teamnamen beibehalten, indem du die Quellorganisation umbenennst und so den ursprünglichen Namen für deine Zielorganisation verwenden kannst.\n\nWenn deine Quellorganisation beispielsweise `@octo-org` heißt und deine `CODEOWNERS`-Datei einen Verweis auf das Team `@octo-org/octo-team` enthält, kannst du die Quellorganisation vor der Migration in `@octo-org-temp` umbenennen, sodass du `@octo-org` als Namen der neuen Organisation verwenden kannst. Das migrierte Team heißt dann `@octo-org/octo-team`, und die `CODEOWNERS`-Datei im migrierten Repository funktioniert wie erwartet.\n\n## Gesperrte Repositorys\n\nNach einer Migration stellst du möglicherweise fest, dass deine Quell- oder Zielrepositorys gesperrt sind, wodurch der Zugriff auf den Code des Repositorys und alle zugehörigen Ressourcen wie Issues und Pull Requests deaktiviert wird. Weitere Informationen zu gesperrten Repositorys findest du unter [Informationen zu gesperrten Repositorys](/de/migrations/overview/about-locked-repositories).\n\nDer Prozess zum Entsperren eines Repositorys hängt vom Produkt ab GitHub , in dem das Repository gespeichert ist.\n\n* Wenn sich das gesperrte Repository auf GitHub Enterprise Server befindet, kann ein Websiteadministrator das Repository über das Dashboard des Websiteadministrators entsperren. Weitere Informationen finden Sie unter [Sperren eines Repositorys](/de/enterprise-server@3.22/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/locking-a-repository) in der GitHub Enterprise Server Dokumentation.\n* Wenn das gesperrte Repository auf GitHub.com ist, können Sie uns über das [GitHub Supportportal](https://support.github.com) kontaktieren, um das Repository zu entsperren.\n\n> \\[!NOTE]\n> Wenn deine Migration nicht erfolgreich war, wurden nicht alle Daten migriert. Wenn du das Repository entsperren und verwenden möchtest, kommt es zu Datenverlusten. Das Löschen des gesperrten Repositorys und das Wiederholen der Migration ist möglicherweise eine bessere Option.\n\n## Kontaktieren GitHub-Support\n\nWenn Sie Ihr Problem nach den oben genannten Schritten zur Fehlerbehebung weiterhin nicht lösen können, können Sie den GitHub-Support über das [GitHub-Supportportal](https://support.github.com) kontaktieren."}