Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Op deze pagina worden veelvoorkomende fouten en onverwacht gedrag beschreven bij het gebruik van Azure Databricks Git-mappen met een externe Git-provider, gegroepeerd op categorie, zodat u de oorzaak sneller kunt identificeren. Als geen van de richtlijnen hier uw probleem oplost, raadpleegt u Hulp vragen.
Verificatiefouten
Deze fouten treden op wanneer Azure Databricks uw identiteit niet kan verifiëren bij de externe Git-provider.
Invalid credentials
Probeer het volgende:
Controleer of de Git-integratie-instellingen (>Gekoppelde instellingen-accounts) juist zijn. U moet zowel de gebruikersnaam als het token van uw Git-provider invoeren.
Controleer of u de juiste Git-provider hebt geselecteerd in Instellingen>Gekoppelde accounts.
Controleer of uw persoonlijke toegangstoken of app-wachtwoord de juiste toegang tot de opslagplaats heeft.
Als SSO is ingeschakeld voor uw Git-provider, autoriseer dan uw tokens voor SSO.
Test uw token met de Git-opdrachtregel. Vervang de tekenreeksen tussen punthaken:
git clone https://<username>:<personal-access-token>@github.com/<org>/<repo-name>.git
SSL-verbindingsfouten
<link>: Secure connection to <link> could not be established because of SSL problems
Deze fout treedt op wanneer Azure Databricks uw Git-server niet kan bereiken via HTTPS. Dit duidt meestal op een probleem met de netwerkverbinding of een TLS-certificaatprobleem in de Git-infrastructuur van uw organisatie.
Voordat u contact op neemt met uw Azure Databricks-accountteam, moet u de volgende informatie gereed hebben:
- De URL van uw Git-server
- Of de server gebruikmaakt van een zelfondertekend of privé-CA-certificaat
- Of andere gebruikers in dezelfde werkruimte dezelfde fout zien
Fout in Microsoft Entra ID-aanmeldingsgegevens
Encountered an error with your :re[ms-entra-id] credentials. Try logging out of :re[ms-entra-id] and logging back in.
Deze fout kan optreden wanneer uw organisatie onlangs een MFA-beleid (Multi-Factor Authentication) heeft ingeschakeld. Wanneer het afdwingen van MFA van kracht wordt, voldoen bestaande Microsoft Entra ID sessies mogelijk niet aan de nieuwe verificatievereisten en mislukt de verbinding.
Los deze fout als volgt op:
- Ga naar
portal.azure.comen meld u af bij Microsoft Entra ID. - Meld u weer aan. U ziet nu een prompt om MFA te voltooien.
Als dat niet werkt, meldt u zich af bij alle Azure services voordat u zich opnieuw aanmeldt.
Fouten met de status van de opslagplaats
Deze fouten treden op wanneer de lokale Git-map een status bereikt die normale bewerkingen voorkomt.
Losgekoppelde hoofdstatus
In Git verwijst de "head" naar de huidige positie in de commitgeschiedenis en verwijst deze normaal gesproken naar een branch. Wanneer HEAD rechtstreeks naar een specifieke commit verwijst in plaats van naar een branch, bevindt de repository zich in een 'detached HEAD'-status. Git houdt wijzigingen die in deze staat zijn aangebracht op welke branch dan ook niet bij. Als u weg navigeert zonder eerst een nieuwe vertakking te maken, gaan deze wijzigingen mogelijk verloren.
Een Git-map kan de losgekoppelde hoofdstatus invoeren wanneer:
- Iemand verwijdert de remote branch. Azure Databricks probeert niet-doorgevoerde lokale wijzigingen te herstellen door ze toe te passen op de standaardbranch. Als er conflicterende wijzigingen zijn, Azure Databricks deze toepast op een momentopname van de standaardvertakking, wat resulteert in een losgekoppelde kop.
- Een gebruiker of service-principal controleert een tag met behulp van de
update repoAPI.
Om van deze toestand te herstellen:
- Klik op Vertakking maken om een vertakking te maken op basis van de huidige doorvoering of Selecteer een vertakking om een bestaande vertakking te bekijken.
- Doorvoeren en pushen om uw wijzigingen te behouden. Om wijzigingen te negeren, klikt u op het
onder Wijzigingen.
Inconsistente opslagplaatsstatus
There was a problem with deleting folders. The repo could be in an inconsistent state and re-cloning is recommended.
Deze fout geeft aan dat er een probleem is opgetreden tijdens het verwijderen van mappen. De opslagplaats heeft nu een inconsistente status. Verwijder en kloon de opslagplaats opnieuw om de status ervan opnieuw in te stellen.
Conflicten tussen naam van notitieblok
Notebooks met identieke of vergelijkbare bestandsnamen kunnen fouten veroorzaken wanneer u een opslagplaats of pull-aanvraag maakt:
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).
Naamconflicten kunnen zelfs voorkomen bij verschillende bestandsextensies. Deze twee bestanden conflicteren bijvoorbeeld:
notebook.ipynbnotebook.py
Als u het conflict wilt oplossen, wijzigt u de naam van het notitieblok, het bestand of de map die bijdraagt aan de foutstatus. Als de fout optreedt wanneer u de opslagplaats kloont, wijzigt u de naam van de notebooks, bestanden of mappen in de externe Git-opslagplaats.
Onverwacht gedrag
Deze problemen produceren geen duidelijk foutbericht, maar ze zijn tekenen van een probleem dat moet worden onderzocht.
Time-outfouten
Bewerkingen zoals het klonen van een grote opslagplaats of het uitchecken van een grote vertakking kunnen leiden tot time-outfouten. De bewerking kan na de time-out nog steeds op de achtergrond worden voltooid.
Als er een time-outfout optreedt:
- Wacht enkele minuten en vernieuw vervolgens de Git-map. Als de verwachte bestanden of vertakkingen aanwezig zijn, is de bewerking voltooid.
- Als de werkruimte zwaar is belast, voert u de bewerking opnieuw uit nadat de belasting is gedaald.
Gebruik sparse checkout om time-outs bij grote repositories te voorkomen, zodat u alleen werkt met de bestanden die u nodig hebt.
404-fouten
Als er een 404-fout optreedt wanneer u een niet-notebookbestand opent, wacht u enkele minuten en probeert u het opnieuw. Er is een korte vertraging tussen wanneer het systeem de werkruimte inschakelt en wanneer de web-app de configuratie ophaalt.
Notebooks lijken te zijn gewijzigd zonder wijzigingen van de gebruiker
Als elke regel van een notitieblok wordt gewijzigd zonder wijzigingen door gebruikers, worden de wijzigingen waarschijnlijk veroorzaakt door verschillen in het einde van de regel. Azure Databricks maakt gebruik van lijneinden (LF) in Linux-stijl, die kunnen verschillen van bestanden die zijn vastgelegd op Windows systemen (CRLF).
Als u dit probleem wilt vaststellen, controleert u of u een .gitattributes bestand hebt:
- Het mag niet bevatten
* text eol=crlf. - Als u Windows niet gebruikt, verwijdert u deze instelling. Zowel uw ontwikkelomgeving als Azure Databricks maken gebruik van Linux-regeleinden.
- Als u Windows gebruikt, wijzigt u de instelling in
* text=auto. Git slaat bestanden vervolgens intern op met regelafbrekingen in Linux-stijl, maar checkt ze automatisch uit met platformspecifieke regelafbrekingen.
Als u al bestanden met Windows-regeleindetekens in Git hebt vastgelegd:
- Alle openstaande wijzigingen wissen.
- Werk het
.gitattributesbestand bij zoals hierboven beschreven voor uw omgeving. - Voer de wijziging door.
- Voer
git add --renormalizeuit. Alle wijzigingen doorvoeren en pushen.
Verwijderde bestanden herstellen
De herstelbaarheid van bestanden varieert per actie. Voor sommige acties is herstel mogelijk via de map Prullenbak, terwijl dat voor andere niet het geval is. Als u bestanden wilt herstellen die eerder zijn vastgelegd en naar een externe vertakking zijn gepusht, gebruikt u de Git-doorvoergeschiedenis van de externe opslagplaats:
| Action | Kan het bestand worden hersteld? |
|---|---|
| Bestand verwijderen met werkruimtebrowser | Ja, uit de map Prullenbak |
| Een nieuw bestand verwijderen via het Git-map dialoogvenster | Ja, uit de map Prullenbak |
| Een gewijzigd bestand verwijderen met het Git-dialoogvenster | Nee, het bestand is verdwenen |
reset (moeilijk) voor niet-doorgevoerde bestandswijzigingen |
Nee, bestandswijzigingen zijn verdwenen |
reset (moeilijk) voor niet-verzonden, nieuw gemaakte bestanden |
Nee, bestandswijzigingen zijn verdwenen |
| Gebruik het dialoogvenster Git-map om tussen vertakkingen te schakelen | Ja, vanuit de externe Git-opslagplaats |
| Andere Git-bewerkingen, zoals committen of pushen, vanuit het Git-map-dialoogvenster | Ja, vanuit de externe Git-opslagplaats |
PATCH bewerkingen die /repos/id bijwerken vanuit de Repos-API |
Ja, vanuit de externe Git-opslagplaats |
Hulp krijgen
Als geen van de richtlijnen op deze pagina uw probleem oplost, neemt u contact op met Azure Databricks ondersteuning. Wanneer u contact opneemt met de ondersteuning, neemt u het volgende op:
- Het exacte foutbericht
- De naam van uw Git-provider en of de opslagplaats openbaar of privé is
- Of het probleem van invloed is op alle gebruikers of alleen op sommige gebruikers in uw werkruimte
- De stappen die u al hebt geprobeerd