Partilhar via

Perguntas frequentes sobre os Arquivos do Azure e a Sincronização de Arquivos do Azure

O Azure Files oferece compartilhamentos de arquivos totalmente gerenciados na nuvem que podem ser acessados por meio do protocolo SMB (Server Message Block) padrão do setor e do protocolo NFS (Network File System). Você pode montar compartilhamentos de arquivos do Azure simultaneamente em implantações na nuvem ou locais do Windows, Linux e macOS. Você também pode armazenar em cache compartilhamentos de arquivos do Azure em máquinas Windows Server usando a Sincronização de Arquivos do Azure para acesso rápido perto de onde os dados são usados.

Azure File Sync

  • Posso ter servidores que estão ligados ao domínio e servidores que não estão no mesmo grupo de sincronização?
    Yes. Um grupo de sincronização pode conter pontos de extremidade de servidor com diferentes associações ao Active Directory, mesmo que não tenham adesão ao domínio. Embora essa configuração funcione tecnicamente, não recomendamos isso como uma configuração típica porque as listas de controle de acesso (ACLs) definidas para arquivos e pastas em um servidor podem não ser impostas por outros servidores no grupo de sincronização. Para obter melhores resultados, recomendamos a sincronização entre servidores que estão na mesma floresta do Ative Directory, entre servidores que estão em florestas diferentes do Ative Directory, mas estabeleceram relações de confiança, ou entre servidores que não estão em um domínio. Recomendamos que você evite usar uma combinação dessas configurações.

  • Criei um arquivo diretamente no meu compartilhamento de arquivos do Azure usando o SMB ou no portal. Quanto tempo leva para o arquivo ser sincronizado com os servidores do grupo de sincronização?

    As alterações efetuadas à partilha de ficheiros do Azure no portal do Azure ou SMB não são imediatamente detetadas e replicadas como alterações ao ponto final do servidor. Os Ficheiros do Azure ainda não têm notificações de alteração ou diário, pelo que não é possível iniciar automaticamente uma sessão de sincronização quando os ficheiros são alterados. No Windows Server, o Azure File Sync utiliza o diário USN do Windows para iniciar automaticamente uma sessão de sincronização quando os ficheiros são alterados.

    Para detetar alterações à partilha de ficheiros do Azure, o Azure File Sync tem um trabalho agendado denominado trabalho de deteção de alterações. Um trabalho de deteção de alterações enumera todos os ficheiros na partilha de ficheiros e, em seguida, compara-os com a versão de sincronização desses ficheiros. Quando o trabalho de deteção de alterações determina que ficheiros foram alterados, o Azure File Sync inicia uma sessão de sincronização. O trabalho de deteção de alterações é iniciado a cada 24 horas. Uma vez que o trabalho de deteção de alterações funciona ao enumerar todos os ficheiros na partilha de ficheiros do Azure, a deteção de alterações demora mais tempo em espaços de nomes maiores do que em espaços de nomes mais pequenos. Para namespaces grandes, pode levar mais de uma vez a cada 24 horas para determinar quais arquivos foram alterados.

    Para sincronizar imediatamente os ficheiros que são alterados na partilha de ficheiros do Azure, o cmdlet Invoke-AzStorageSyncChangeDetection do PowerShell pode ser utilizado para iniciar manualmente a deteção de alterações na partilha de ficheiros do Azure. Este cmdlet destina-se a cenários em que algum tipo de processo automatizado está fazendo alterações no compartilhamento de arquivos do Azure ou as alterações são feitas por um administrador (como mover arquivos e diretórios para o compartilhamento). Para alterações de usuário final, a recomendação é instalar o agente do Azure File Sync em uma VM IaaS e fazer com que os usuários finais acessem o compartilhamento de arquivos por meio da VM IaaS. Dessa forma, todas as alterações serão sincronizadas rapidamente com outros agentes sem a necessidade de usar o cmdlet Invoke-AzStorageSyncChangeDetection. Para saber mais, consulte a documentação Invoke-AzStorageSyncChangeDetection.

    Estamos a explorar a adição de deteção de mudanças para uma partilha de ficheiros do Azure, semelhante à funcionalidade USN para volumes no Windows Server. Ajude-nos a priorizar esse recurso para desenvolvimento futuro votando nele em Comentários da Comunidade do Azure.

  • O que acontece se o mesmo ficheiro for alterado em dois servidores aproximadamente ao mesmo tempo?
    Os conflitos de ficheiros são criados quando o ficheiro na partilha de ficheiros do Azure não corresponde ao ficheiro na localização do ponto final do servidor (o tamanho e/ou a hora da última modificação é diferente).

    Os cenários a seguir podem causar conflitos de arquivo:

    • Um ficheiro é criado ou modificado num ponto final (por exemplo, Servidor A). Se o mesmo ficheiro for modificado num ponto final diferente antes de a alteração no Servidor A ser sincronizada com esse ponto final, é criado um ficheiro de conflito.
    • O ficheiro já existia na partilha de ficheiros do Azure e na localização do ponto final do servidor antes da sua criação. Se o tamanho do ficheiro e/ou a hora da última modificação for diferente entre o ficheiro no servidor e a partilha de ficheiros do Azure quando é criado o ponto final do servidor, é criado um ficheiro de conflito.
    • O banco de dados de sincronização foi recriado devido a dados corrompidos ou limite de capacidade atingido. Assim que a base de dados for recriada, a sincronização entra num modo chamado reconciliação. Se o tamanho do ficheiro e/ou a hora da última modificação for diferente entre o ficheiro no servidor e a partilha de ficheiros do Azure quando ocorre a reconciliação, é criado um ficheiro de conflito.

    Quando o carregamento inicial para o compartilhamento de arquivos do Azure estiver concluído, a Sincronização de Arquivos do Azure não substituirá nenhum arquivo em seu grupo de sincronização. Em vez disso, ele usa uma estratégia simples de resolução de conflitos: mantém ambas as alterações em arquivos alterados em dois endpoints ao mesmo tempo. A alteração escrita mais recentemente mantém o nome de ficheiro original. O ficheiro mais antigo (determinado por LastWriteTime) tem o nome do endpoint e o número de conflito anexados ao nome do ficheiro. Para pontos finais do servidor, o nome do ponto final é o nome do servidor. Para endpoints de cloud, o nome do endpoint é Cloud. O nome segue esta taxonomia:

    <FileNameWithoutExtension>-<endpointName>[-#].<ext>

    Por exemplo, o primeiro conflito de CompanyReport.docx passaria a ser CompanyReport-CentralServer.docx se CentralServer for onde a gravação mais antiga ocorreu. O segundo conflito seria denominado CompanyReport-CentralServer-1.docx. O Azure File Sync suporta 100 ficheiros de conflito por ficheiro. Assim que o número máximo de ficheiros em conflito for atingido, o ficheiro não será sincronizado até que o número de ficheiros em conflito seja inferior a 100.

  • Tenho a hierarquização na nuvem desativada, por que há arquivos em camadas no local do ponto de extremidade do servidor?
    Há duas razões pelas quais os arquivos hierárquicos podem existir no local do ponto de extremidade do servidor:

    • Ao adicionar um novo ponto de extremidade de servidor a um grupo de sincronização existente, se escolheres a opção recuperar namespace primeiro ou somente recuperar namespace para o modo de download inicial, os arquivos aparecerão por camadas até serem baixados localmente. Para evitar isso, selecione a opção evitar arquivos hierárquicos para o modo de download inicial. Para recuperar arquivos manualmente, use o Invoke-StorageSyncFileRecall cmdlet.

    • Se a hierarquização na nuvem tiver sido ativada no ponto de extremidade do servidor e, em seguida, desativada, os arquivos permanecerão hierarquizados até serem acessados.

  • Porque é que os meus ficheiros hierárquicos não mostram miniaturas ou pré-visualizações no Explorador de Ficheiros do Windows?
    Para arquivos em camadas, miniaturas e visualizações não serão visíveis no ponto de acesso do servidor. Esse comportamento é esperado porque o recurso de cache de miniaturas no Windows ignora intencionalmente a leitura de arquivos com o atributo offline. Com o Cloud Tiering ativado, a leitura de ficheiros em camadas provocaria a sua transferência (recuperação). No entanto, você pode configurar a Sincronização de Arquivos do Azure para ignorar a configuração do atributo offline.

    Esse comportamento não é específico do Azure File Sync. O Explorador de Ficheiros do Windows apresenta um "X cinzento" para todos os ficheiros que tenham o atributo offline definido. Você verá o ícone X ao acessar arquivos pelo SMB. Para obter uma explicação detalhada desse comportamento, consulte Por que não obtenho miniaturas para arquivos marcados como offline?

    Para perguntas sobre como gerenciar arquivos hierárquicos, consulte Como gerenciar arquivos hierárquicos.

  • Existe uma opção para ignorar o atributo offline para arquivos em camadas?

    Se preferir tornar as miniaturas e visualizações visíveis para arquivos em camadas, você pode configurar a Sincronização de Arquivos do Azure para ignorar a configuração do atributo offline.

    1. Adicione a seguinte chave do Registro no servidor:

      reg ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure\StorageSync" /v SkipOfflineAttributeOnTieredFile /t RE

    2. Reinicie o serviço FileSyncSvc .

    Uma vez configurado:

    • Novos arquivos hierárquicos não terão mais o atributo offline.
    • Os arquivos hierárquicos existentes serão atualizados na próxima execução de manutenção (ocorre a cada 24 horas).

    Nota

    Essa configuração é aplicada globalmente em todos os arquivos, não em extensões específicas. Sem o atributo offline, o Explorador de Arquivos do Windows mostra um ícone diferente. Você pode adicionar a coluna Atributos no Explorador de Arquivos para identificar arquivos em camadas (atributos ALM). Com base nos padrões de uso, ignorar o atributo offline pode aumentar as recuperações de arquivos, portanto, você deve monitorar a atividade de recuperação e garantir que os custos de saída permaneçam dentro de um intervalo aceitável. Consulte Como gerenciar arquivos hierárquicos.

  • Por que os arquivos hierárquicos existem fora do namespace do ponto de extremidade do servidor?
    Antes do agente do Azure File Sync versão 3, o Azure File Sync bloqueava a movimentação de arquivos hierárquicos fora do ponto de extremidade do servidor, mas no mesmo volume que o ponto de extremidade do servidor. As operações de cópia, as movimentações de arquivos não hierárquicos e as movimentações de arquivos hierárquicos para outros volumes não foram afetadas. A razão para este comportamento foi a suposição implícita de que o Explorador de Ficheiros e outras APIs do Windows consideram que operações de mover no mesmo volume são operações de renomeação quase instantâneas. Isso significa que as movimentações farão com que o Explorador de Arquivos ou outros métodos de movimentação (como linha de comando ou PowerShell) pareçam não responder enquanto o Azure File Sync recupera os dados da nuvem. A partir da versão 3.0.12.0 do agente do Azure File Sync, o Azure File Sync permitirá que você mova um arquivo hierárquico para fora do ponto de extremidade do servidor. Evitamos os efeitos negativos mencionados anteriormente, permitindo que o arquivo em camadas exista como um arquivo em camadas fora do ponto de extremidade do servidor e, em seguida, recuperando o arquivo em segundo plano. Isso significa que as movimentações no mesmo volume são instantâneas e fazemos todo o trabalho para recuperar o arquivo para o disco após a conclusão da movimentação.

  • Estou a ter um problema com a Sincronização de Ficheiros do Azure no meu servidor (sincronização, hierarquização na nuvem, etc.). Devo remover e recriar meu ponto de extremidade do servidor?

    Não: remover um ponto de extremidade do servidor não é como reiniciar um servidor! Remover e recriar o ponto de extremidade do servidor quase nunca é uma solução apropriada para corrigir problemas com sincronização, hierarquização na nuvem ou outros aspetos da Sincronização de Arquivos do Azure. Remover um ponto de extremidade do servidor é uma operação destrutiva. Isso pode resultar em perda de dados no caso de existirem arquivos em camadas fora do namespace do ponto de extremidade do servidor. Para obter mais informações, consulte Por que os arquivos hierárquicos existem fora do namespace do ponto de extremidade do servidor para obter mais informações. Ou pode resultar em arquivos inacessíveis para arquivos hierárquicos que existem dentro do namespace do ponto de extremidade do servidor. Esses problemas não serão resolvidos ao recriar o endpoint do servidor. Ficheiros em camadas podem existir no namespace do ponto de extremidade do servidor, mesmo que nunca tenhas ativado a organização por camadas na nuvem. É por isso que recomendamos que você não remova o ponto de extremidade do servidor, a menos que deseje parar de usar o Azure File Sync com essa pasta específica ou tenha sido explicitamente instruído a fazê-lo por um engenheiro da Microsoft. Para obter mais informações sobre como remover pontos de extremidade do servidor, consulte Remover um ponto de extremidade do servidor.

  • Posso mover o serviço de sincronização de armazenamento e/ou a conta de armazenamento para um grupo de recursos diferente, uma assinatura ou um locatário do Microsoft Entra?
    Sim, você pode mover o serviço de sincronização de armazenamento e/ou a conta de armazenamento para um grupo de recursos diferente, assinatura ou locatário do Microsoft Entra. Depois de mover o serviço de sincronização de armazenamento ou a conta de armazenamento, você precisa conceder ao aplicativo Microsoft.StorageSync acesso à conta de armazenamento. Siga estes passos:

    1. Entre no portal do Azure e selecione Controle de acesso (IAM) no menu de serviço.

    2. Selecione o separador Atribuições de função para listar os utilizadores e aplicações (principais de serviço) que têm acesso à sua conta de armazenamento.

    3. Verifique se Microsoft.StorageSync ou Serviço de Sincronização de Ficheiros Híbridos (nome antigo da aplicação) aparece na lista com a função Acesso de Dados e Leitor.

      Se Microsoft.StorageSync ou Hybrid File Sync Service não aparecer na lista, execute as seguintes etapas:

      • Selecione Adicionar.
      • No campo Função, selecione Acesso de Dados e Leitor.
      • No campo Selecionar, digite Microsoft.StorageSync, selecione a função e selecione Salvar.

      Nota

      Ao criar o ponto de extremidade na nuvem, o serviço de sincronização de armazenamento e a conta de armazenamento devem estar no mesmo locatário do Microsoft Entra. Uma vez que o endpoint na nuvem é criado, o serviço de sincronização de armazenamento e a conta de armazenamento podem ser movidos para diferentes locatários do Microsoft Entra.

  • O Azure File Sync preserva as ACLs NTFS de nível de diretório/arquivo juntamente com os dados armazenados nos Arquivos do Azure?

    A partir de 24 de fevereiro de 2020, as ACLs novas e existentes hierarquizadas pela sincronização de arquivos do Azure serão mantidas no formato NTFS e as modificações de ACL feitas diretamente no compartilhamento de arquivos do Azure serão sincronizadas com todos os servidores no grupo de sincronização. Quaisquer alterações em ACLs feitas em compartilhamentos de arquivos do Azure serão sincronizadas por meio da Sincronização de Arquivos do Azure. Ao copiar dados para os Arquivos do Azure, certifique-se de usar uma ferramenta de cópia que ofereça suporte à "fidelidade" necessária para copiar atributos, carimbos de data/hora e ACLs em um compartilhamento de arquivos do Azure - via SMB ou REST. Ao usar ferramentas de cópia do Azure, como AzCopy, é importante usar a versão mais recente. Verifique a tabela de ferramentas de cópia de arquivo para obter uma visão geral das ferramentas de cópia do Azure para garantir que você possa copiar todos os metadados importantes de um arquivo.

    Se você habilitou o Backup do Azure em seus compartilhamentos de arquivos gerenciados do Azure File Sync, as ACLs de arquivo podem continuar a ser restauradas como parte do fluxo de trabalho de restauração de backup. Isso funciona para todo o compartilhamento ou arquivos/diretórios individuais.

    Se você estiver usando instantâneos como parte da solução de backup autogerenciado para compartilhamentos de arquivos gerenciados pelo Azure File Sync, suas ACLs podem não ser restauradas corretamente para ACLs NTFS se os instantâneos tiverem sido tirados antes de 24 de fevereiro de 2020. Se isso ocorrer, considere entrar em contato com o Suporte do Azure.

  • O Azure File Sync sincroniza o LastWriteTime para diretórios? Por que o carimbo de data/hora modificado em um diretório não é atualizado quando os arquivos dentro dele são alterados?
    Não, o Azure File Sync não sincroniza o LastWriteTime para diretórios. Além disso, o Azure Files não atualiza a data de modificação (LastWriteTime) para diretórios quando os ficheiros no diretório são alterados. Este comportamento está previsto.

  • Como funciona o espaço de volume para o Cloud Tiering como parte da interoperabilidade com o Dedup?
    Em alguns casos em que o Dedup está instalado, o espaço de volume disponível pode aumentar mais do que o esperado após a coleta de lixo do Dedup ser acionada. Por exemplo, digamos que a política de espaço livre para hierarquização na nuvem esteja definida como 20%. O Azure File Sync é notificado quando há pouco espaço livre (digamos quando o espaço livre é de 19%). A hierarquização determina que 1% mais espaço precisa ser liberado, mas como buffer teremos 5% extras, então hierarquizaremos até 25% (por exemplo, 30 GiB). Os arquivos ficam hierarquizados até atingir 30 GiB. Como parte da interoperabilidade com o Dedup, o Azure File Sync inicia a coleta de lixo no final da sessão de hierarquização.

  • Porque é que o software antivírus no servidor AFS está a recuperar ficheiros em camadas?
    Quando os utilizadores acedem a ficheiros em camadas, alguns softwares antivírus (AV) podem causar recuperações não intencionais de ficheiros. Isso ocorre se o software AV não estiver configurado para ignorar arquivos hierárquicos (aqueles com o atributo RECALL_ON_DATA_ACCESS). Veja o que acontece:

    1. Um usuário tenta acessar um arquivo em camadas.
    2. O software antivírus bloqueia o indicador de leitura.
    3. Em seguida, o aplicativo AV executa sua própria leitura para verificar o arquivo em busca de vírus.

    Esse processo pode parecer como se o software AV estivesse recuperando os arquivos em camadas, mas na verdade é acionado pela tentativa de acesso do usuário. Para evitar esse problema, certifique-se de que seu fornecedor de AV configure seu software para ignorar a verificação de arquivos hierárquicos com o atributo RECALL_ON_DATA_ACCESS.

  • O software de inspeção SSL pode bloquear o acesso aos servidores AFS? Certifique-se de que o seu software de inspeção SSL (como Zscaler ou FortiGate) permite que os pontos finais do servidor Azure File Sync (AFS) acedam ao Azure. Essas ferramentas de inspeção SSL podem substituir as configurações do firewall e permitir o tráfego seletivamente. Entre em contato com o administrador da rede para resolver esse problema. Use o comando "testnet" para determinar se o servidor AFS está enfrentando esse problema.

Segurança, autenticação e controle de acesso

  • Como posso auditar o acesso a arquivos e as alterações nos Arquivos do Azure?

    Há duas opções que fornecem funcionalidade de auditoria para Arquivos do Azure:

    • Se os usuários estiverem acessando o compartilhamento de arquivos do Azure diretamente, você poderá usar os logs do Armazenamento do Azure para controlar as alterações de arquivos e o acesso do usuário para fins de solução de problemas. As solicitações são registradas com base no melhor esforço.
    • Se os usuários estiverem acessando o compartilhamento de arquivos do Azure por meio de um Windows Server que tenha o agente de Sincronização de Arquivos do Azure instalado, use uma política de auditoria ou um produto de terceiros para controlar as alterações de arquivos e o acesso do usuário no Windows Server.

  • Os Arquivos do Azure dão suporte ao uso da Enumeração Baseada em Acesso (ABE) para controlar a visibilidade dos arquivos e pastas nos compartilhamentos de arquivos do Azure SMB?

    O uso do ABE com Arquivos do Azure não é suportado no momento, mas você pode usar o DFS-N com compartilhamentos de arquivos do Azure SMB.

  • Posso salvar em um compartilhamento de arquivos do Azure usando uma impressora ou scanner?

    Os Ficheiros do Azure suportam apenas Windows, Linux e macOS. Não há suporte para acessar um compartilhamento de arquivos do Azure diretamente de uma impressora ou scanner. No entanto, se já estiver a utilizar a Sincronização de Ficheiros do Azure, pode imprimir ou digitalizar para o servidor de ficheiros do Windows e, em seguida, sincronizar o ficheiro com uma partilha de ficheiros do Azure.

  • Os Arquivos do Azure dão suporte a fluxos de dados alternativos?

Os Arquivos do Azure não oferecem suporte a fluxos de dados alternativos. A transferência de dados via SMB apresentará uma mensagem de ficheiro já existente se um fluxo de dados alternativo for encontrado. Você pode verificar fluxos alternativos usando o seguinte comando do PowerShell:

get-item <file path+name> -Stream *

Se mais de um fluxo for mostrado, você poderá removê-los usando o seguinte comando do PowerShell:

remove-Item <file path+name> -Stream *

Os fluxos de dados alternativos são preservados no local quando a Sincronização de Arquivos do Azure é usada.

Autenticação baseada em identidade

  • Os Serviços de Domínio do Microsoft Entra suportam o acesso SMB usando credenciais do Microsoft Entra de dispositivos associados ou registrados com o ID do Microsoft Entra?

    Não, este cenário não é suportado.

  • Posso usar o nome canônico (CNAME) para montar um compartilhamento de arquivos do Azure enquanto uso a autenticação baseada em identidade?

    Sim, esse cenário agora é suportado em ambientes de floresta única e de várias florestas para compartilhamentos de arquivos do Azure SMB. No entanto, os Arquivos do Azure só dão suporte à configuração de CNAMEs usando o nome da conta de armazenamento como um prefixo de domínio. Se você não quiser usar o nome da conta de armazenamento como um prefixo, considere usar Namespaces DFS .

  • Posso acessar compartilhamentos de arquivos do Azure com credenciais do Microsoft Entra de uma VM em uma assinatura diferente?

    Se a subscrição sob a qual a partilha de ficheiros é implementada estiver associada ao mesmo inquilino do Microsoft Entra que a implementação dos Serviços de Domínio Microsoft Entra na qual a VM ingressou no domínio, poderá aceder às partilhas de ficheiros do Azure utilizando as mesmas credenciais do Microsoft Entra. A limitação não é imposta à assinatura, mas ao inquilino associado ao Microsoft Entra.

  • Posso habilitar os Serviços de Domínio do Microsoft Entra ou a autenticação do AD DS local para compartilhamentos de arquivos do Azure usando um locatário do Microsoft Entra diferente do locatário principal do compartilhamento de arquivos do Azure?

    N.º Azure Files dá suporte apenas aos Serviços de Domínio do Microsoft Entra ou à integração do AD DS local com um tenant do Microsoft Entra que reside na mesma assinatura que a partilha de ficheiros. Uma assinatura só pode ser associada a um locatário do Microsoft Entra. Ao usar o AD DS local para autenticação, a credencial do AD DS deve ser sincronizada com a ID do Microsoft Entra à qual a conta de armazenamento está associada.

  • A autenticação do AD DS local para partilhas de ficheiros do Azure suporta a integração com um ambiente do AD DS que utiliza várias florestas?

    A autenticação do AD DS local dos Arquivos do Azure só se integra à floresta do serviço de domínio no qual a conta de armazenamento está registrada. Para dar suporte à autenticação de outra floresta, seu ambiente deve ter uma relação de confiança de floresta configurada corretamente. Para obter instruções detalhadas, consulte Usar Azure Files com várias florestas do Active Directory.

    Nota

    Em uma configuração com várias florestas, não use o Explorador de Arquivos para configurar permissões de ACLs/NTFS do Windows no nível de raiz, diretório ou arquivo. Use icacls em vez disso.

  • Existe alguma diferença na criação de uma conta de computador ou de início de sessão de serviço para representar a minha conta de armazenamento no AD?

    Criar uma conta de computador (padrão) ou uma conta de logon de serviço não faz diferença na forma como a autenticação funciona com os Arquivos do Azure. Você pode fazer sua própria escolha sobre como representar uma conta de armazenamento como uma identidade em seu ambiente do AD. O DomainAccountType padrão definido no Join-AzStorageAccountForAuth cmdlet é conta de computador. No entanto, a idade de expiração da senha configurada em seu ambiente do AD pode ser diferente para contas de logon de computador ou serviço, e você precisa levar isso em consideração para Atualizar a senha da identidade da sua conta de armazenamento no AD.

  • Como remover credenciais armazenadas em cache com chave de conta de armazenamento e excluir conexões SMB existentes antes de inicializar nova conexão com credenciais do Microsoft Entra ID ou AD?

    Siga o processo de duas etapas abaixo para remover a credencial salva associada à chave da conta de armazenamento e remover a conexão SMB:

    1. Execute o seguinte comando a partir de um prompt de comando do Windows para remover a credencial. Se não conseguir encontrar uma, significa que não persistiu a credencial e pode ignorar este passo.

      cmdkey /delete:Domínio:target=storage-account-name.file.core.windows.net

    2. Elimine a ligação existente à partilha de ficheiros. Você pode especificar o caminho de montagem como a letra da unidade montada ou como o caminho storage-account-name.file.core.windows.net.

      net use <drive-letter/share-path> /delete

  • É possível visualizar o userPrincipalName (UPN) de um proprietário de arquivo/diretório no Explorador de Arquivos em vez do identificador de segurança (SID)?

    O Explorador de Arquivos chama uma API RPC diretamente para o servidor (Arquivos do Azure) para traduzir o SID para um UPN. Os Arquivos do Azure não dão suporte a essa API, portanto, no Explorador de Arquivos, o SID de um proprietário de arquivo/diretório é exibido em vez do UPN para arquivos e diretórios hospedados nos Arquivos do Azure. No entanto, a partir de um cliente ingressado no domínio, você pode usar o seguinte comando do PowerShell para exibir todos os itens em um diretório e seu proprietário, incluindo UPN:

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Sistema de arquivos de rede (NFS v4.1)

Compartilhar instantâneos

Criar instantâneos de partilha

  • Os meus snapshots de partilha são redundantes geograficamente?
    Os instantâneos de partilha têm a mesma redundância que a partilha de ficheiros do Azure a partir dos quais foram criados. Se você selecionou armazenamento com redundância geográfica para sua conta, seu instantâneo de compartilhamento também será armazenado de forma redundante na região emparelhada.

Limpar instantâneos de compartilhamento

  • Posso excluir meu compartilhamento, mas não excluir meus instantâneos de compartilhamento?
    N.º O fluxo de trabalho de compartilhamento de arquivos de exclusão excluirá automaticamente os instantâneos quando você excluir o compartilhamento.

Faturação e preços

  • O que são transações nos Arquivos do Azure e como elas são cobradas? As transações de protocolo ocorrem sempre que um usuário, aplicativo, script ou serviço interage com compartilhamentos de arquivos do Azure (gravação, leitura, listagem, exclusão de arquivos, etc.). É importante lembrar que algumas ações que você pode perceber como uma única operação podem, na verdade, envolver várias transações. Para partilhas de ficheiros pay-as-you-go, diferentes tipos de transações têm preços diferentes com base no seu impacto na partilha de ficheiros. As transações não afetam a cobrança de compartilhamentos de arquivos provisionados. Para obter mais informações, consulte Noções básicas sobre cobrança.

Interoperabilidade com outros serviços

  • Posso usar a minha partilha de ficheiros do Azure como uma Testemunha de Partilha de Ficheiros para o meu Windows Server Failover Cluster?
    Esta configuração não é suportada atualmente para os Arquivos do Azure. Para saber como configurar isso usando o armazenamento de Blob do Azure, consulte Implantar uma testemunha de nuvem para um cluster de failover.

Consulte também

  • Last updated on