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

O Ficheiros do Azure oferece partilhas de ficheiros totalmente geridas na cloud, às quais pode aceder através do protocolo padrão da indústria Server Message Block (SMB) e do protocolo Network File System (NFS). Você pode montar compartilhamentos de arquivos do Azure simultaneamente em implantações na nuvem ou locais do Windows, Linux e macOS. Ao usar o Azure File Sync, pode armazenar em cache partilhas de ficheiros Azure em máquinas Windows Server para acesso rápido a dados próximos do local onde são usados.

Azure File Sync FAQ

  • 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.
    • Recrias a base de dados sincronizada devido à corrupção ou ao limite de conhecimento atingido. Depois de recriar a base de dados, a sincronização entra num modo chamado reconciliação. Se o tamanho do ficheiro e o tempo da última modificação forem diferentes entre o ficheiro no servidor e o Azure quando ocorre a reconciliação, é criado um ficheiro de conflito.

    Depois de concluído o carregamento inicial para a partilha de ficheiros do Azure, o Azure File Sync não sobrescreve nenhum ficheiro no teu 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 torna-se CompanyReport-CentralServer.docx se o CentralServer for onde ocorreu a escrita mais antiga. O segundo conflito chama-se CompanyReport-CentralServer-1.docx. O Azure File Sync suporta 100 ficheiros de conflito por ficheiro. Depois de atingir o número máximo de ficheiros de conflito, o ficheiro deixa de sincronizar até que o número de ficheiros de 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 REG_DWORD /d 1 /f

    2. Reinicie o serviço FileSyncSvc .

    Após a configuração:

    • 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 Azure File Sync agente versão 3, o Azure File Sync bloqueava a movimentação de ficheiros em camadas para fora do endpoint do servidor, mas no mesmo volume que o endpoint do servidor. As operações de cópia, as movimentações de ficheiros não escalonados e as transferências de ficheiros escalonados para outros volumes não eram 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. Esta suposição significa que os movimentos fazem com que o Explorador de Ficheiros ou outros métodos de movimento (como linha de comandos ou PowerShell) pareçam não responsivos, enquanto o Azure File Sync recupera os dados da cloud. A partir do Azure File Sync agent versão 3.0.12.0, o Azure File Sync permite mover um ficheiro em níveis para fora do endpoint do servidor. Os efeitos negativos mencionados anteriormente são evitados permitindo que o ficheiro em camadas exista como um ficheiro em camadas fora do endpoint do servidor e depois recuperando o ficheiro em segundo plano. Esta abordagem significa que os movimentos no mesmo volume são instantâneos, e o Azure File Sync recupera o ficheiro para o disco após a conclusão da mudança.

  • 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 a Microsoft. StorageSync ou Hybrid File Sync Service não aparecem na lista, siga estes passos:

      • 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. Depois de criado o ponto final na cloud, pode mover o serviço de sincronização de armazenamento e a conta de armazenamento 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 Ficheiros do Azure 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 é instalado, o espaço disponível pode aumentar mais do que o esperado após o acionamento da recolha de lixo do Dedup. Por exemplo, digamos que a política de espaço livre para hierarquização na nuvem esteja definida como 20%. Azure File Sync é notificado quando há pouco espaço livre (por exemplo, quando o espaço livre é de 19%). A definição por escalões determina que é necessário libertar mais 1% de espaço, mas, como margem, existe um adicional de 5%, pelo que sobe para 25% (por exemplo, 30 GiB). Os ficheiros são armazenados por escalões até perfazerem 30 GiB. Como parte da interoperabilidade com o Dedup, o Azure File Sync inicia a recolha de lixo no final da sessão de escalonamento.

  • Porque é que o software antivírus do servidor Azure File Sync está a recuperar ficheiros em camadas?
    Quando os utilizadores acedem a ficheiros em níveis, algum software antivírus (AV) pode causar recolhas de ficheiros não intencionais. Este problema ocorre se o software antivírus não estiver configurado para ignorar ficheiros em níveis (aqueles com o RECALL_ON_DATA_ACCESS atributo). 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. O software antivírus realiza então a sua própria leitura para analisar o ficheiro à procura de vírus.

    Este processo pode parecer que o software antivírus está a recuperar os ficheiros em níveis, mas na verdade é ativado pela tentativa de acesso do utilizador. Para evitar este problema, certifique-se de que o fornecedor da sua solução antivírus configure o respetivo software para ignorar a análise de ficheiros hierarquizados com o atributo RECALL_ON_DATA_ACCESS.

  • O software de inspeção SSL pode bloquear o acesso aos servidores Azure File Sync? Certifique-se de que o seu software de inspeção SSL (como Zscaler ou FortiGate) permite que os endpoints do servidor Azure File Sync 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 testnet comando para determinar se o seu servidor Azure File Sync está a ter este problema.

Fornecedores de recursos e partilhas clássicas de ficheiros

  • Qual é a diferença entre os fornecedores de recursos Microsoft.Storage e Microsoft.FileShares? O que é uma partilha de ficheiros Azure versus uma partilha de ficheiros Azure classic?

    Os fornecedores de recursos são serviços de gestão que fornecem tipos específicos de recursos no Azure. Implementa partilhas de ficheiros clássicas do Azure numa conta de armazenamento, que é um recurso de nível superior que utiliza o fornecedor de recursos Microsoft.Storage. Todos os recursos de armazenamento numa conta partilham os limites que se aplicam a essa conta. Partilhas de ficheiros oferecidas pela Microsoft. O fornecedor de recursos FileShares é um novo recurso de topo que simplifica a implementação de partilha de ficheiros ao eliminar a necessidade de uma conta de armazenamento. Atualmente, o Microsoft.FileShares suporta apenas o protocolo de partilha de ficheiros NFS. As partilhas de ficheiros clássicas suportam tanto SMB como NFS.

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 Ficheiros do Azure não suporta a utilização de ABE, mas pode utilizar o DFS-N com partilhas de ficheiros do Azure via 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.º Ficheiros do Azure 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 Ficheiros do Azure 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 em criar uma conta de computador ou de login de serviço para representar a minha conta de armazenamento no Active Directory?

    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 posso remover credenciais em cache usando a chave da conta de armazenamento e apagar ligações SMB existentes antes de inicializar uma nova ligação com credenciais Microsoft Entra ID ou AD?

    Siga o processo em dois passos para remover a credencial guardada associada à chave da conta de armazenamento e remover a ligaçã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.

      Utilização <da rede 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)

Perguntas frequentes sobre como partilhar 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 eliminar partilha de ficheiros apaga automaticamente os snapshots quando apagas a partilha.

Ficheiros do Azure 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 do Ficheiros do Azure com outros serviços

  • Qual é a diferença entre Ficheiros do Azure e Azure NetApp Files?
    Ficheiros do Azure e Azure NetApp Files são serviços de armazenamento de ficheiros diferentes no Azure, e são concebidos para cargas de trabalho e requisitos de desempenho distintos. O Ficheiros do Azure disponibiliza partilhas de ficheiros SMB e NFS serverless, e oferece o Azure File Sync como opção para armazenar em cache partilhas de ficheiros SMB no Windows Server. Azure NetApp Files é um serviço de armazenamento de ficheiros de alto desempenho, bare metal, alimentado pela tecnologia NetApp, que suporta partilhas de ficheiros NFS, SMB e de protocolo duplo. Para mais informações, consulte Compare Ficheiros do Azure e Azure NetApp Files.

  • 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 para Ficheiros do Azure. Para saber como configurar esta configuração usando o armazenamento Azure Blob, consulte Deploy a Cloud Witness for a Failover Cluster.

Consulte também

  • Last updated on