Dela via


Felsöka problem i AzCopy v10

Den här artikeln beskriver vanliga problem som kan uppstå när du använder AzCopy. Den här artikeln hjälper dig också att identifiera orsakerna till problemen och föreslår hur du löser dem.

Identifiera problem

Du kan avgöra om ett jobb lyckas genom att titta på slutkoden.

Om slutkoden är 0-successslutförs jobbet.

Om slutkoden är 1-errorundersöker du loggfilen. När du förstår det exakta felmeddelandet kan du enklare söka efter rätt nyckelord och fastställa lösningen. Mer information finns i Hitta fel och återuppta jobb med hjälp av logg- och planfiler i AzCopy.

Om slutkoden är 2-panickontrollerar du om loggfilen finns. Om filen inte finns kan du skicka en bugg eller kontakta supporten.

All annan slutkod som inte är noll (till exempel OOMKilled) kan genereras av systemet. I dokumentationen för operativsystemet finns särskilda slutkoder.

"403"-fel

"403"-fel är vanliga. Ibland är de godartade och orsakar inte en misslyckad överföring. I AzCopy-loggar kan du till exempel se att en HEAD begäran har tagit emot "403"-fel. Dessa fel visas när AzCopy kontrollerar om en resurs är offentlig. I de flesta fall kan du ignorera dessa instanser.

I vissa fall kan "403"-fel orsaka en misslyckad överföring. Om det här problemet uppstår misslyckas troligen andra försök att överföra filer tills du löser problemet. "403"-fel kan orsakas av autentiserings- och auktoriseringsproblem. De kan också inträffa om begäranden blockeras av brandväggskonfigurationen för lagringskontot.

Problem med autentisering och auktorisering

"403"-fel som förhindrar dataöverföring uppstår på grund av problem som rör SAS-token, rollbaserade åtkomstkontrollroller (Azure RBAC) och konfigurationer av åtkomstkontrollistor (ACL).

SAS-token

Om du använder en SAS-token (signatur för delad åtkomst) kontrollerar du att följande instruktioner är sanna:

  • Förfallo- och starttiderna för SAS-token är lämpliga.

  • Du har valt alla nödvändiga behörigheter för token.

  • Du genererade token med hjälp av ett officiellt SDK eller verktyg. Prova Storage Explorer om du inte redan har gjort det.

Azure RBAC

Om du använder Azure RBAC-roller via azcopy login kommandot kontrollerar du att du har rätt Azure-roller tilldelade till din identitet (till exempel rollen Storage Blob Data Contributor).

Mer information om Azure-roller finns i Tilldela en Azure-roll för åtkomst till blobdata.

Åtkomstkontrollistor

Om du använder åtkomstkontrollistor kontrollerar du att din identitet visas i en ACL-post för varje fil eller katalog som du tänker komma åt. Kontrollera också att varje ACL-post återspeglar lämplig behörighetsnivå.

Mer information om ACL:er och ACL-poster finns i Åtkomstkontrollistor (ACL: er) i Azure Data Lake Storage Gen2.

Mer information om hur du införlivar Azure-roller tillsammans med ACL:er och hur systemet utvärderar dem för att fatta auktoriseringsbeslut finns i Åtkomstkontrollmodell i Azure Data Lake Storage Gen2.

Problem med brandvägg och privat slutpunkt

Om konfigurationen av lagringsbrandväggen inte tillåter åtkomst från den värdkomponent som AzCopy körs på returnerar AzCopy-åtgärder en HTTP-felkod "403".

Obs!

I den här artikeln refererar termen värdkomponent till en fysisk dator, en virtuell dator (VM) eller en container.

Tillåtet omfång för kopieringsåtgärder

Egenskapen AllowedCopyScope för ett lagringskonto används för att ange de miljöer som du kan kopiera data från till målkontot. Den här egenskapen visas i Azure Portal som konfigurationsinställningen Tillåtna omfång för kopieringsåtgärder (förhandsversion). Som standard ges inte egenskapen något värde. Egenskapen returnerar inte ett värde förrän du uttryckligen anger det. Egenskapen AllowedCopyScope har tre möjliga värden, som du ser i följande tabell.

Värde Beskrivning
(null) (Standardvärde) Tillåter kopiering från valfritt lagringskonto till målkontot.
Microsoft Entra ID Tillåter kopiering från endast konton som finns inom samma Microsoft Entra klientorganisation som målkontot.
PrivateLink Tillåter kopiering från endast lagringskonton som har privata länkar till samma virtuella nätverk som målkontot.

Mer information om den här egenskapen och dess associerade konfigurationsinställning finns i Begränsa källan för kopieringsåtgärder till ett lagringskonto.

Överföra data från eller till en lokal värdkomponent

Om du laddar upp eller laddar ned data mellan ett lagringskonto och en lokal värdkomponent kontrollerar du att värdkomponenten som kör AzCopy kan komma åt antingen käll- eller mållagringskontot. Du kan behöva använda IP-nätverksregler i brandväggsinställningarna för antingen käll- eller målkontona för att tillåta åtkomst från värdkomponentens offentliga IP-adress.

Överföra data mellan lagringskonton

"403"-auktoriseringsfel kan hindra dig från att överföra data mellan konton med hjälp av klientvärdkomponenten som AzCopy körs på.

Om du kopierar data mellan lagringskonton kontrollerar du att värdkomponenten som kör AzCopy kan komma åt både käll- och målkontot. Du kan behöva använda IP-nätverksregler i brandväggsinställningarna för både käll- och målkontona för att tillåta åtkomst från värdkomponentens offentliga IP-adress. Tjänsten använder IP-adressen för AzCopy-klientvärdkomponenten för att auktorisera källan till måltrafiken. Information om hur du lägger till en offentlig IP-adress i brandväggsinställningarna för ett lagringskonto finns i Bevilja åtkomst från ett INTERNET-IP-intervall.

Om den virtuella datorn inte har eller inte kan ha en offentlig IP-adress bör du överväga att använda en privat slutpunkt. Se Använda privata slutpunkter för Azure Storage.

Private Link är på nivån för virtuellt nätverk/undernät. Om du vill att AzCopy-begäranden ska gå igenom Private Link måste AzCopy göra dessa begäranden från en virtuell dator som körs i det virtuella nätverket/undernätet. Anta till exempel att du konfigurerar Private Link i VNet1/Subnet1, men den virtuella dator där AzCopy körs finns i VNet1/Subnet2. I det här scenariot använder AzCopy-begäranden inte Private Link och begärandena förväntas misslyckas.

Om du stöter på TCP-fel som "dial tcp: lookup proxy.x.x: no such host" innebär det att din miljö inte är konfigurerad att använda rätt proxy eller att du använder en avancerad proxy som AzCopy inte känner igen.

Du måste uppdatera proxyinställningarna för att återspegla rätt konfigurationer. Se Konfigurera proxyinställningar.

Du kan också kringgå proxyn genom att ange miljövariabeln NO_PROXY="*".

Här är de slutpunkter som AzCopy kräver:

Inloggningsslutpunkter Azure Storage-slutpunkter
login.microsoftonline.com (global Azure) (blob | file | dfs).core.windows.net (global Azure)
login.chinacloudapi.cn (Azure Kina) (blob | file | dfs).core.chinacloudapi.cn (Azure Kina)
login.microsoftonline.de (Azure Tyskland) (blob | file | dfs).core.cloudapi.de (Azure Tyskland)
login.microsoftonline.us (Azure US Government) (blob | file | dfs).core.usgovcloudapi.net (Azure US Government)

x509: certifikat signerat av okänd utfärdare

Det här felet är ofta relaterat till användningen av en proxy som använder ett SSL-certifikat (Secure Sockets Layer) som inte är betrott av operativsystemet. Kontrollera inställningarna och kontrollera att certifikatet är betrott på operativsystemnivå.

Vi rekommenderar att du lägger till certifikatet i värdkomponentens rotcertifikatarkiv eftersom det är där de betrodda myndigheterna förvaras.

Okända parametrar

Om du får ett felmeddelande om att parametrarna inte känns igen kontrollerar du att du använder rätt version av AzCopy. AzCopy v8 och tidigare versioner är inaktuella. AzCopy v10 är den aktuella versionen och det är en fullständig omskrivning som inte delar någon syntax med de tidigare versionerna. Se AzCopy Migration Guide för v8 till v10.

Se också till att använda inbyggda hjälpmeddelanden med hjälp av växeln -h tillsammans med alla kommandon (till exempel azcopy copy -h). Se Hämta kommandohjälp. Information om hur du visar samma information online finns i azcopy copy.

För att hjälpa dig att förstå kommandon tillhandahåller vi ett utbildningsverktyg som finns i AzCopy-kommandoguiden. Det här verktyget visar de mest populära AzCopy-kommandona tillsammans med de mest populära kommandoflaggorna. Exempelkommandon finns i Överföra data. Om du har en fråga kan du prova att söka igenom befintliga GitHub-problem först för att se om den redan har besvarats.

Principfel för villkorsstyrd åtkomst

Du kan få följande fel när du anropar azcopy login kommandot:

Det gick inte att utföra inloggningskommandot: det gick inte att logga in med tenantID "common", Azure-katalogslutpunkten "https://login.microsoftonline.com", autorest/adal/devicetoken: -REDACTED– AADSTS50005: Användaren försökte logga in på en enhet från en plattform (okänd) som för närvarande inte stöds via principen för villkorsstyrd åtkomst. Enhetsplattformar som stöds är: iOS-, Android-, Mac- och Windows-varianter. Spårnings-ID: -REDACTED- Korrelations-ID: -REDACTED- Tidsstämpel: 2021-01-05 01:58:28Z

Det här felet innebär att administratören har konfigurerat en princip för villkorlig åtkomst som anger vilken typ av enhet du kan logga in från. AzCopy använder enhetskodflödet. Enhetskodflödet kan inte garantera att värdkomponenten som du använder AzCopy-verktyget på också är den plats där du loggar in.

Om enheten finns med i listan över plattformar som stöds kanske du kan använda Storage Explorer. Storage Explorer integrerar AzCopy för alla dataöverföringar (det skickar token till AzCopy via det hemliga arkivet) men tillhandahåller ett inloggningsarbetsflöde som stöder överföring av enhetsinformation. Själva AzCopy stöder även hanterade identiteter och tjänstens huvudnamn som ett inloggningsalternativ.

Om enheten inte finns med i listan över plattformar som stöds kontaktar du administratören för att få hjälp.

Servern är upptagen, nätverksfel eller tidsgränser

Om du ser ett stort antal misslyckade begäranden med statusen "503 Servern är upptagen" begränsar lagringstjänsten dina begäranden. Om du ser nätverksfel eller tidsgränser kanske du försöker skicka för mycket data för din infrastruktur att hantera. I samtliga fall är lösningen liknande.

Om du ser att en stor fil upprepade gånger inte kan kopieras eftersom vissa segment misslyckas varje gång kan du försöka begränsa de samtidiga nätverksanslutningarna eller dataflödesgränsen beroende på ditt specifika fall. Vi föreslår att du sänker prestanda drastiskt till en början, observerar om den här åtgärden löste det första problemet och sedan ökar prestandan igen tills du uppnår en övergripande balans.

Mer information finns i Optimera prestanda för AzCopy med Azure Storage.

Om du kopierar data mellan konton med hjälp av AzCopy kan kvaliteten och tillförlitligheten i nätverket där du kör AzCopy påverka den övergripande prestandan. Även om dataöverföringar från server till server initierar AzCopy anrop för varje fil som ska kopieras mellan tjänstslutpunkter.

Kända begränsningar i AzCopy

  • Kopiering av data från myndighetsmoln till kommersiella moln stöds inte. Kopiering av data från kommersiella moln till myndighetsmoln stöds dock.

  • Asynkron kopiering på tjänstsidan stöds inte. AzCopy utför endast synkron kopiering. När jobbet är klart har data med andra ord flyttats.

  • Om du har glömt att ange --preserve-smb-permissions flaggan och inte vill överföra data igen när du kopierar till en Azure-filresurs bör du överväga att använda Robocopy för att överföra behörigheterna.

  • Azure Functions har en annan slutpunkt för MSI-autentisering. AzCopy stöder ännu inte MSI-autentisering.

Se även

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.