File Storage NAS:Solução de problemas de acesso de leitura e gravação de arquivos

Servidor sem resposta durante o acesso simultâneo a arquivos

Causa: um bug no driver do kernel SMB do Linux causa esse problema. Ao montar um sistema de arquivos com SMB 2.1 ou 3.0, os clientes podem falhar ao enviar os pacotes SMB BreakAck esperados em alguns cenários de acesso simultâneo, fazendo com que o servidor pare de responder por 35 segundos.

Solução 1: monte o sistema de arquivos usando SMB 2.0.

Solução 2: siga estas etapas.

1. execute o comando a seguir para desativar os oplocks ao carregar o módulo CIFS:

   # modprobe cifs enable_oplocks=0

2. execute o comando a seguir para desativar os oplocks após o carregamento do módulo CIFS:

   # echo 0 > /sys/module/cifs/parameters/enable_oplocks

3. execute o comando a seguir para verificar o status dos oplocks:

   # cat /sys/module/cifs/parameters/enable_oplocks

   Na saída, Y indica ativado, e N indica desativado.

   Nota

   • Para aplicar as alterações, desmonte e remonte o sistema de arquivos SMB.

   • Para tornar as alterações permanentes, crie o arquivo /etc/modprobe.d/cifs.conf e adicione a linha options cifs enable_oplocks=0.

Não é possível criar links simbólicos

Causa

O sistema de arquivos SMB foi montado no Linux sem a opção mfsymlinks ou com a versão 2.0 do protocolo.

Solução

Ao montar um sistema de arquivos SMB no Linux, use a versão 2.1 ou 3.0 do protocolo e adicione a opção mfsymlinks. Veja a seguir um exemplo do comando de montagem. Para obter as descrições dos parâmetros no exemplo, consulte SMB (Linux) mount command parameter descriptions.

sudo mount -t cifs //file-system-id.region.nas.aliyuncs.com/myshare /mnt -o vers=2.1,guest,uid=0,gid=0,dir_mode=0755,file_mode=0755,mfsymlinks,cache=strict,rsize=1048576,wsize=1048576

Ponto de montagem SMB sem resposta

Causa

Em distribuições Linux com kernel anterior a 3.10.0-514, o driver do kernel SMB pode falhar em cenários de acesso simultâneo, tornando o ponto de montagem inacessível. O log do kernel contém mensagens semelhantes às seguintes:

...
[<ffffffffc03c9bc1>] cifs_oplock_break+0x1f1/0x270 [cifs]
[<ffffffff810a881a>] process_one_work+0x17a/0x440
[<ffffffff810a8d74>] rescuer_thread+0x294/0x3c0
...

Solução

• Remonte o sistema de arquivos com a opção cache=none. Isso pode afetar o desempenho.

• Atualize o sistema operacional da instância ECS que executa Linux.

Erro "Bad file descriptor" ao copiar arquivos grandes

Causa

Esse problema ocorre devido a uma falha temporária de rede ou de backend. Os clientes SMB em algumas distribuições Linux, como o SUSE, têm suporte limitado para esse tipo de failover.

Solução

A tabela a seguir lista as versões recomendadas do sistema operacional Linux para o NAS SMB.

Caracteres chineses ilegíveis nos clientes

Sintoma

Ao gravar caracteres chineses (por exemplo, em nomes de arquivos ou no conteúdo do arquivo) de um cliente Linux para um sistema de arquivos NAS, eles podem aparecer ilegíveis em um cliente Windows, e vice-versa.

Causa

Por padrão, os clientes Windows usam o conjunto de caracteres GBK para codificação e decodificação de chinês, enquanto os clientes Linux usam o conjunto de caracteres UTF-8. Cada plataforma codifica dados usando seu próprio conjunto de caracteres. Quando os dados gravados por uma plataforma são lidos pela outra, a incompatibilidade entre os conjuntos de caracteres causa uma falha de decodificação, e o conteúdo aparece ilegível.

Solução

Para evitar problemas de incompatibilidade entre plataformas, recomendamos montar sistemas de arquivos NAS via SMB em clientes Windows e via NFS em clientes Linux.

Operações de arquivo lentas no Windows com NFS

Causa

No Windows, o NFS apresenta problemas de compatibilidade entre semânticas sensíveis e insensíveis a maiúsculas e minúsculas. O desempenho da criação de arquivos em um diretório degrada significativamente à medida que o tamanho do diretório aumenta. Isso ocorre porque o diretório precisa ser percorrido a cada criação de arquivo. Quando o diretório contém cerca de 100.000 entradas, uma única varredura pode levar mais de 10 segundos.

Solução

modifique os parâmetros de montagem adicionando a opção -o casesensitive=yes para evitar a varredura do diretório. Veja um exemplo de comando:

mount -o nolock -o mtype=hard -o timeout=60 -o casesensitive=yes \\file-system-id.region.nas.aliyuncs.com\! Z:

Substitua a letra da unidade Z: e o endereço do ponto de montagem file-system-id.region.nas.aliyuncs.com de acordo com o seu ambiente.

Como resolver o erro invalid device ao renomear um arquivo em um sistema de arquivos NFS a partir de um cliente Windows?

Renomear um arquivo retorna o erro invalid device se você montou um subdiretório do sistema de arquivos NFS. Para resolver isso, monte o diretório raiz do sistema de arquivos. Para obter mais informações, consulte Step 2: Mount a general-purpose NAS file system that uses NFS.

Latência na criação de arquivos no NFS

• Sintoma:

  A ECS-1 criou o arquivo abc, mas há um atraso até que a ECS-2 possa ver o arquivo abc. O atraso às vezes é de 1 segundo e pode chegar a 1 minuto. Por que isso acontece?

• Causa:

  Isso é causado pelo Lookup Cache e é um comportamento esperado para um período de tempo T. Por exemplo, a ECS-2 acessa o caminho do arquivo antes de a ECS-1 criar o arquivo abc. Isso faz com que a ECS-2 receba uma resposta de 'arquivo não encontrado' e, em seguida, um registro é armazenado em cache indicando que o arquivo abc não existe. Dentro do período de tempo T, como o FileAttr ainda não expirou, quando a ECS-2 acessa o caminho do arquivo novamente, ela ainda recupera o registro em cache indicando que o arquivo abc não existe.

• Solução:

  Para garantir que a ECS-2 possa ver o arquivo imediatamente após a ECS-1 criá-lo, use uma das seguintes soluções:

  • Solução 1: desative o cache de pesquisa negativa na ECS-2 para evitar o armazenamento em cache de arquivos inexistentes. Esta solução tem a menor sobrecarga.

    Ao montar o sistema de arquivos, adicione a opção lookupcache=positive. O valor padrão é lookupcache=all. Veja um exemplo de comando:

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,lookupcache=positive file-system-id.region.nas.aliyuncs.com:/ /mnt

  • Solução 2: desative todos os caches na ECS-2. Esta solução pode degradar severamente o desempenho. Escolha esta solução apenas se a sua carga de trabalho exigir.

    Ao montar o sistema de arquivos, adicione a opção actimeo=0. Veja um exemplo de comando:

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

Latência de gravação de dados no NFS

• Sintoma:

  A ECS-1 atualiza um arquivo chamado abc. No entanto, quando a ECS-2 lê o arquivo imediatamente, ela ainda lê o conteúdo antigo. Por que isso acontece?

• Causa:

  Este problema tem as duas causas a seguir:

  • Após a ECS-1 gravar dados no arquivo abc, os dados não são liberados imediatamente para o servidor. Em vez disso, o cliente primeiro armazena os dados em seu page cache. Os dados são liberados apenas quando o aplicativo chama fsync ou close.

  • A ECS-2 possui um cache de arquivos e pode não recuperar imediatamente o conteúdo mais recente do servidor. Por exemplo, se a ECS-2 armazenou os dados em cache quando a ECS-1 atualizou o arquivo abc, a ECS-2 ainda usa o conteúdo em cache ao ler o arquivo novamente.

• Solução:

  Para garantir que a ECS-2 possa ler imediatamente os dados mais recentes após a ECS-1 atualizar um arquivo, use uma das seguintes soluções:

  • Solução 1: use a consistência close-to-open (CTO). Para garantir o CTO, após a ECS-1 atualizar o arquivo, ela deve chamar close ou fsync. Antes de a ECS-2 ler o arquivo, ela deve reabri-lo e então lê-lo.

  • Solução 2: desative todos os caches na ECS-1 e na ECS-2. Esta solução pode degradar severamente o desempenho. Escolha esta solução apenas se a sua carga de trabalho exigir.

    • Desative o cache na ECS-1. Ao montar o sistema de arquivos, adicione a opção noac para garantir que todos os dados gravados sejam persistidos imediatamente. Veja um exemplo de comando:

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,noac file-system-id.region.nas.aliyuncs.com:/ /mnt

      Nota

      • Se a chamada fsync for feita após a conclusão da operação de gravação na ECS-1, ou se você usar gravações síncronas, poderá substituir noac por actimeo=0 para um desempenho ligeiramente melhor.

      • A opção noac equivale a especificar actimeo=0 e forçar todas as gravações a serem síncronas.

    • Desative o cache na ECS-2. Ao montar o sistema de arquivos, adicione a opção actimeo=0 para ignorar todos os caches. Veja um exemplo de comando:

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

Proprietários de arquivos diferentes em instâncias ECS diferentes

Em um sistema de arquivos, a identidade do usuário é identificada por um UID ou GID, e não por um nome de usuário. O nome de usuário exibido como proprietário em uma instância ECS é derivado desse UID.

Por exemplo, na instância ECS 1, o usuário admin cria um arquivo chamado admin_on_machine1. Na instância ECS 2, o usuário admin cria um arquivo chamado admin_on_machine2.

Ao executar o comando ll na instância ECS 1 para visualize os arquivos, a saída é a seguinte:

$ ll
total 0
-rw-rw-r-- 1 admin    admin 0 Apr  6 17:10 admin_on_machine1
-rw-rw-r-- 1 terminal 19062 0 Apr  6 17:12 admin_on_machine2

Ao executar o comando ll na instância ECS 2, a saída é a seguinte:

$ ll
total 0
-rw-rw-r-- 1    505    505 0 Apr  6 17:10 admin_on_machine1
-rw-rw-r-- 1 admin  admin 0 Apr  6 17:12 admin_on_machine2

Os resultados da consulta nas duas instâncias ECS mostram que o mesmo arquivo tem nomes de usuário proprietários diferentes.

Em seguida, execute o comando id em cada instância para consultar as informações do usuário admin.

Na instância ECS 1, o UID do usuário admin é 505, conforme mostrado na saída a seguir:

$ id
uid=505(admin) gid=505(admin) groups=505(admin)

Na instância ECS 2, o UID do usuário admin é 2915, conforme mostrado na saída a seguir:

$ id
uid=2915(admin) gid=19062(admin) groups=19062(admin)

Execute o comando stat admin_on_machine1 admin_on_machine2 para verificar os detalhes de ambos os arquivos. A saída mostra que admin_on_machine1 tem um UID de 505/UNKNOWN e um GID de 505/UNKNOWN, enquanto admin_on_machine2 tem um UID de 2915/admin e um GID de 19062/admin. Isso confirma que o usuário admin tem UIDs e GIDs diferentes nas duas instâncias ECS.

$ stat admin_on_machine1 admin_on_machine2
  File: 'admin_on_machine1'
  Size: 0          Blocks: 0          IO Block: 1048576 regular empty file
Device: 25h/37d Inode: 6447105    links: 1
Access: (0664/-rw-rw-r--)  Uid: (  505/ UNKNOWN)   Gid: (  505/ UNKNOWN)
Access: 2021-04-06 17:10:56.423782205 +0800
Modify: 2021-04-06 17:10:56.423782290 +0800
Change: 2021-04-06 17:10:56.423874225 +0800
 Birth: -
  File: 'admin_on_machine2'
  Size: 0          Blocks: 0          IO Block: 1048576 regular empty file
Device: 25h/37d Inode: 6447106    links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 2915/   admin)   Gid: (19062/   admin)
Access: 2021-04-06 17:12:42.267027897 +0800
Modify: 2021-04-06 17:12:42.267027984 +0800
Change: 2021-04-06 17:12:42.267106855 +0800
 Birth: -

Exceções em gravações simultâneas em arquivos de log

Sintoma

O Apsara File Storage NAS fornece acesso compartilhado a arquivos com um namespace unificado para vários clientes. No entanto, quando vários processos ou clientes gravam simultaneamente no mesmo arquivo, por exemplo, um arquivo de log, cada processo mantém seu próprio descritor de arquivo e contexto de deslocamento de gravação. O protocolo NFS não possui semântica de anexação atômica, o que pode levar a problemas de corrupção de dados, como sobrescritas e intercalações.

Solução

• (Recomendado) faça com que diferentes processos ou clientes gravem em arquivos diferentes dentro do mesmo sistema de arquivos e, em seguida, mescle os arquivos para análise posterior. Essa abordagem evita problemas de simultaneidade e não requer bloqueios de arquivo, portanto, não afeta o desempenho.

• Para cenários que envolvem anexações simultâneas ao mesmo arquivo, como um arquivo de log, você pode usar um bloqueio de arquivo e o mecanismo de busca (seek) para garantir a atomicidade e a consistência da gravação. No entanto, esse método pode degradar significativamente o desempenho. A seção a seguir fornece uma breve visão geral para sua referência.

Como usar flock e seek

Como o protocolo NFS não fornece semântica de anexação atômica, gravações simultâneas no final do mesmo arquivo, como um arquivo de log, podem facilmente sobrescrever umas às outras. No Linux, você pode usar os mecanismos flock e seek para simular anexações atômicas em um sistema de arquivos NFS e proteger gravações de anexação simultâneas.

Siga estas etapas:

1. Chame fd=open(filename, O_WRONLY | O_APPEND | O_DIRECT) para abrir o arquivo no modo de anexação e especifique O_DIRECT para ignorar o page cache. Isso retorna o descritor de arquivo fd.

2. Chame flock(fd, LOCK_EX|LOCK_NB) para tentar adquirir um bloqueio de arquivo. Se a chamada falhar (por exemplo, porque o bloqueio já está mantido), ela retornará um erro. Você pode então tentar novamente ou tratar o erro.

3. Após adquirir o bloqueio, chame lseek(fd, 0, SEEK_END) para mover o deslocamento de gravação atual de fd para o final do arquivo.

4. Execute uma operação de gravação normal. Os dados são gravados no final do arquivo e o bloqueio de arquivo impede que gravações simultâneas se sobrescrevam.

5. Após a conclusão da operação de gravação, chame flock(fd, LOCK_UN) para liberar o bloqueio de arquivo.

Por que o comando ls retorna um erro 523 quando executado em um sistema de arquivos NFS em um sistema operacional Linux?

Sintoma

Ao executar o comando ls em um sistema de arquivos NFS a partir de um cliente Linux, a seguinte mensagem de erro é retornada.

ls: reading directory '.': Unknown error 523

Causa

Se você executar o comando ls em um diretório do sistema de arquivos enquanto operações rename simultâneas estão sendo executadas nele, um erro 523 será retornado.

Solução

Aguarde um momento e tente a operação novamente. Se o erro persistir, envie um ticket.

Falhas na montagem do sistema de arquivos SMB

Sintoma

Se você usar sistemas de arquivos NFS e SMB e falhar ao montar um sistema de arquivos NFS usando o comando net use, também poderá encontrar problemas ao tentar montar o sistema de arquivos SMB correto.

Solução

verifique se você está montando o sistema de arquivos correto, interrompa temporariamente a operação de montagem e tente novamente após 5 minutos. Se a operação ainda falhar, envie um ticket.

Diretório montado visível apenas para o Administrador

Esse problema ocorre devido ao mecanismo de isolamento de usuário no Windows. Um diretório montado por um usuário não fica visível na sessão de outro usuário.

Para ative o compartilhamento entre vários usuários, crie um link de diretório. Por exemplo, execute o comando a seguir para crie um diretório chamado myshare na unidade C:

mklink /D C:\myshare \\xxxxxxx-xxxx.cn-beijing.nas.aliyuncs.com\myshare\

Baixo desempenho do SMB em clientes Linux

Se um sistema de arquivos SMB apresentar baixo desempenho, você poderá solucionar o problema com base nas seguintes causas potenciais.

• Causa 1: o throughput máximo de um sistema de arquivos SMB escala linearmente com sua capacidade de armazenamento.

  Solução: use a ferramenta fio para testar o desempenho do sistema de arquivos SMB. Para obter mais informações, consulte Test the performance of a NAS file system.

• Causa 2: a largura de banda de rede de uma única instância ECS que executa Linux é baixa.

  Solução: use várias instâncias ECS que executam Linux para alcançar o desempenho geral desejado do sistema de arquivos.

• Causa 3: o cache no lado do cliente para o sistema de arquivos SMB está desativado.

  Solução: ao montar um sistema de arquivos SMB, cache=none indica que o cache está desativado. A opção padrão ou cache=strict indica que o cache está ativado. Você pode executar o comando sudo mount | grep cifs para verificar se a opção correta está sendo usada.

• Causa 4: o tamanho de I/O para o cliente SMB não está definido corretamente.

  Solução: defina os valores de rsize e wsize com base nos requisitos do seu negócio. O valor padrão é 1048576.

• Causa 5: as especificações de CPU ou memória da instância ECS que executa Linux são muito baixas, ou muitos recursos estão ocupados por outros serviços.

  Solução: selecione especificações adequadas para a instância ECS que executa Linux e verifique os recursos usados por outros aplicativos no sistema para garantir que os requisitos de CPU e memória sejam atendidos. Você pode executar o comando top para verificar o uso de CPU e memória.

• Causa 6: a opção atime é usada para montagem.

  Solução: se o seu negócio não for altamente sensível aos tempos de acesso a arquivos (atime), não use a opção atime ao montar o sistema de arquivos.

• Causa 7: o cenário de servidor web envolve leituras frequentes de um grande número de arquivos pequenos, gravações infrequentes e notificações de gravação.

  Solução: configure um mecanismo de cache específico para o servidor web, como o Apache, no cliente, ou entre em contato com a equipe do Alibaba Cloud NAS para ativar a aceleração para cenários de servidor web.

Como resolver o erro Permission denied ao acessar um sistema de arquivos SMB a partir do Linux?

Causa: esse erro pode ocorrer se valores incorretos para UID, GID, file_mode ou dir_mode forem usados no comando de montagem.

Solução: verifique se as opções de montagem, como UID, GID, file_mode e dir_mode, estão definidas corretamente. Para obter mais informações, consulte Mount an SMB file system.

Alteração de maiúsculas e minúsculas no nome do arquivo no SMB

Os sistemas de arquivos SMB não diferenciam maiúsculas de minúsculas, o que é consistente com os sistemas Windows. No entanto, você não pode renomear um arquivo alterando apenas a caixa das letras.

Como alternativa, você pode primeiro renomear o arquivo para um nome diferente e, em seguida, renomeá-lo para o nome desejado com a caixa correta.

Não é possível alterar o proprietário e o modo do arquivo

Você não pode alterar dinamicamente o proprietário ou o modo de arquivos e diretórios. Você só pode especificar esses atributos ao montar o sistema de arquivos. Para obter mais informações, consulte Mount an SMB file system.

O que gera arquivos com a extensão .nfs? Como eles podem ser exclua?

Ao excluir um arquivo que está aberto em um aplicativo, o sistema cria um arquivo temporário com o sufixo .nfs. O sistema exclui automaticamente esse arquivo quando o processo do aplicativo é fechado.

Como resolver o erro bind conn to session failed on NFSv4 server ao acessar arquivos em um diretório do sistema de arquivos NAS?

• Causa

  Esse erro ocorre porque o Apsara File Storage NAS não oferece suporte ao NFSv4.1. O sistema reporta esse erro se você tentar montar um sistema de arquivos usando o NFSv4.1.

• Solução

  Remonte o sistema de arquivos usando NFSv3 ou NFSv4.0 com base no seu cenário de negócios. Para obter mais informações, consulte Usage notes for mounting a file system.

Problemas de sincronização de dados com o NFS

Sintoma

Quando vários clientes montam o mesmo sistema de arquivos NAS, as alterações de dados feitas em um cliente podem não ficar imediatamente visíveis em outros clientes.

Causa

Por padrão, o kernel do sistema operacional mantém os atributos de arquivos e diretórios e cria um cache de metadados para reduzir a necessidade de chamadas de procedimento remoto NFSPROC_GETATTR.

Solução

execute o comando de montagem a seguir para desativar o cache de atributos de arquivos e diretórios.

mount -t nfs4 -o noac file-system-id.region.nas.aliyuncs.com:/ /mnt

Substitua file-system-id.region.nas.aliyuncs.com pelo endereço do ponto de montagem do sistema de arquivos e /mnt pelo caminho local no seu servidor onde você deseja montar o sistema de arquivos.

Contêiner grava no NAS antigo após remontagem

Causa

Se você montar um sistema de arquivos NAS em uma instância ECS e, em seguida, mapear o diretório de montagem para um contêiner usando um volume local (HostPath), as informações de montagem do contêiner ficarão independentes da instância ECS host. Consequentemente, se você desmontar o diretório NAS original no host ou montar um novo, o contêiner em execução continuará a usar o sistema de arquivos NAS antigo.

Solução

Após montar o novo sistema de arquivos NAS na instância ECS, reinicie o Pod do contêiner.

Arquivos não visíveis após a reinicialização do servidor

Se o sistema de arquivos ainda existir, esse problema geralmente ocorre porque o servidor não está configurado para montar automaticamente o sistema de arquivos NAS na reinicialização.

Para montar manualmente o sistema de arquivos NAS novamente, consulte Usage notes for mounting a file system.

Para configurar a montagem automática do sistema de arquivos NAS após uma reinicialização, consulte os seguintes tópicos:

• Automatically mount an NFS file system on a Linux system

• Automatically mount an SMB file system on a Windows system

Migração e cópia de arquivos lentas com SMB no Linux

Se você descartou problemas de desempenho do sistema de arquivos, a lentidão pode ser devida à falta de simultaneidade no seu processo de migração ou cópia. Você pode usar as seguintes ferramentas de código aberto para migração ou cópia paralela.

• GNU Parallel

  selecione um número apropriado de threads com base nos recursos do sistema. Exemplo: find * -type f | parallel --will-cite -j 10 cp {} /mnt/smb/ &

• Fpart

• Fpsync

• multi

Erro "Disk quota exceeded"

• Causa

  O uso ou a contagem de arquivos do diretório de destino excedeu o limite de cota de usuário configurado. Como resultado, as operações de gravação (incluindo aumento do tamanho do arquivo, criação de arquivos, diretórios e movimentação de arquivos para diretórios) falham e uma mensagem de erro semelhante a Disk quota exceeded é retornada.

• Solução

  1. Recomendamos limpar dados para liberar espaço ou aumentar o limite de capacidade do diretório o mais rápido possível. Para obter mais informações, consulte edite a single user quota.

  2. Após a conclusão da limpeza, recomendamos executar primeiro operações de gravação de teste no diretório com a cota (por exemplo, crie e grave dados em um arquivo de teste) para acionar a atualização assíncrona do cache de cota. verifique se essas operações de gravação de teste foram bem-sucedidas antes de reiniciar seu negócio.

Erro "Permission denied" ao acessar o NFS

Siga estas etapas para configurar o AnonymousGid e o AnonymousUid para o seu sistema.

1. Faça login na instância ECS onde o sistema de arquivos está montado.

2. Abra o Prompt de Comando e execute o comando regedit para abrir o Editor do Registro.

3. acesse .

4. clique em uma área em branco com o botão direito, selecione e crie as duas entradas de registro a seguir.

   • AnonymousGid, com o valor 0.

   • AnonymousUid, com o valor 0.

     No Editor do Registro, verifique se o caminho HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default agora contém tanto AnonymousGid quanto AnonymousUid, cada um definido como 0.

5. Reinicie a instância ECS.

6. Remonte o sistema de arquivos NAS de uso geral que usa NFS.

   mount -o nolock -o mtype=hard -o timeout=60 \\file-system-id.region.nas.aliyuncs.com\! Z:

   Substitua a letra da unidade Z: e o nome de domínio do ponto de montagem file-system-id.region.nas.aliyuncs.com pelos seus valores reais.

7. execute o comando mount para verificar se o sistema de arquivos foi montado com êxito.

   Após a conclusão da montagem, a saída deve incluir mount=hard, locking=no e um valor de timeout de 10 ou superior. Caso contrário, a montagem falhou. Veja um exemplo da saída esperada:

   C:\Users\Administrator>mount
   Local    Remote                              Properties
   Z:       \\29xxx.nas~          UID=-2, GID=-2
                             rsize=1048576, vsize=1048576
                             mount=hard, timeout=10.0
                             retry=1, locking=no
                             fileaccess=755, lang=GB2312-80
                             casesensitive=no
                             sec=sys

Modificação de permissões do diretório raiz com chown

Você não pode modificar as permissões de um diretório raiz do NAS.

Para controlar as permissões em um diretório NAS montado localmente, você pode montar um subdiretório. Por exemplo, se você montar o diretório raiz do NAS em /data, não poderá usar chown para alterar o proprietário e o grupo do diretório /data. Se você montar um subdiretório do NAS, que deve ser criado com antecedência, no diretório local /data, poderá usar chown para alterar o proprietário e o grupo do diretório /data. Observe que, para criar um subdiretório no NAS, você deve primeiro montar o diretório raiz do NAS e, em seguida, criar o subdiretório. Para obter informações sobre como criar e montar um subdiretório, consulte How do I create and mount a NAS subdirectory on a Linux system?.