Você encontrará o erro “O nome de rede especificado não está mais disponível“ao tentar acessar um recurso de rede, como Network Attached Storage, um dispositivo remoto ou o servidor/controlador de domínio (DC ) em si. Esse problema também pode ocorrer no lado do servidor se o controlador tentar acessar esses recursos, adicionar usuários ao domínio ou ao tentar promover o DC.
Normalmente, isso significa que o recurso é não está mais disponível ou o administrador impôs restrições ao seu dispositivo em relação a esse acesso. Eles também podem ter desativado o servidor. Mas o problema também pode ocorrer involuntariamente devido a vários outros motivos.
Se o recurso de rede for não está mais online ou disponível, não há nada que você possa fazer para acessá-lo, a menos que o administrador decida disponibilizá-lo novamente. No entanto, para o último caso, há muitas soluções possíveis que você pode experimentar no dispositivo cliente ou no servidor.
O que causa o erro”Nome de rede especificado não está mais disponível”
Além do administrador do servidor adulterando o recurso de rede, aqui estão algumas causas possíveis para o erro acima:
O protocolo necessário está desabilitado. As portas necessárias não estão abertas. Aplicativos de segurança cronometrando o acesso ao recurso de rede. Problemas com a pasta do usuário do aplicativo, como permissão, compactação ou criptografia incorreta. O controlador de domínio não atende às condições necessárias antes da promoção. Bugs no software de acesso à rede.
Como corrigir o nome de rede especificado não está mais disponível?
Algumas das possíveis soluções abaixo exigem que você tenha acesso ao servidor de rede ou controlador de domínio. Se você não tiver acesso, precisará entrar em contato com o administrador do sistema e solicitar que ele execute essas operações. Outras soluções exigem que você faça alterações em seu próprio computador, o que pode ser feito sem problemas.
Habilitar protocolo SMBv2/v3
Uma rede usa o protocolo SMB (Server Message Block) para fornecer acesso a recursos compartilhados conectados à mesma rede. Atualmente, apenas o SMB v2 ou v3 é usado e o SMB v1 já está obsoleto. Portanto, muitos dispositivos não têm o SMBv1 ativado por padrão e, em vez disso, optam por usar as versões posteriores.
No entanto, é possível que esses protocolos não estejam ativados no lado do cliente ou no servidor. Então, você precisa fazer isso manualmente para resolver seu problema. SMBv3 e v2 usam a mesma pilha, então você só precisa habilitar SMBv2 para usar qualquer um dos protocolos.
No lado do cliente
Abra Executar pressionando Win + R. Digite cmd e pressione Ctrl + Shift + Enter para abrir o Prompt de comando elevado. Digite os seguintes comandos: sc config lanmanworkstation depende=bowser/mrxsmb20/nsi sc config mrxsmb20 start=auto Reinicie seu PC
No lado do servidor
Pressione Win + R para abrir Executar. Digite powershell e pressione Ctrl + Shift + Enter para abrir o Windows PowerShell. Se o sistema operacional no servidor for Windows 8 e Windows Server 2012 ou superior, digite o comando abaixo:
Set-SmbServerConfiguration-EnableSMB2Protocol $true
Em seguida, digite Y e pressione Enter se solicitado.
Para versões anteriores versões, você precisa inserir o seguinte comando:
Set-ItemProperty-Path”HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters”SMB2-Type DWORD-Value 1-Force
Resto art o PC se você usou o comando Set-ItemProperty
Verificar status do protocolo SMBv1
Apenas ativar o SMBv2 pode não ser suficiente. Se você habilitou SMBv1 e v2/v3 em seu sistema, mas o servidor habilita apenas SMBv2/v3, seu dispositivo pode tentar erroneamente usar o canal SMBv1.
Portanto, você precisa desativá-lo em seu lado do cliente em tal cenário.
Abra o prompt de comando elevado. Digite o seguinte comando e pressione Enter após cada um: sc config lanmanworkstation depend=bowser/mrxsmb20/nsi sc config mrxsmb10 start=disabled
Reinicie o seu PC para aplicar a alteração.
Como alternativa, você pode inserir o seguinte comando no Windows PowerShell elevado para desativar o protocolo:
Disable-WindowsOptionalFeature-Online-FeatureName SMB1Protocol
Em casos raros, o servidor pode suportar apenas SMBv1, mas desative-o ao ativar SMBv2/v3. Portanto, se você não conseguir resolver o problemaapós executar todas as etapas anteriores e a solução anterior, talvez seja necessário habilitar o SMBv1 no servidor junto com o sistema cliente.
Para habilitá-lo no servidor,
Abra o Elevated PowerShell. Para Windows 8 e Windows Server 2012 ou SO mais antigo, digite Set-SmbServerConfiguration-EnableSMB1Protocol $true e pressione Enter. Em seguida, se solicitado, digite Y e pressione Enter.
Para versões anteriores do sistema operacional, use Set-ItemProperty-Path”HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters”SMB1-Type DWORD-Value 1-Force.
Para ativá-lo no cliente,
Abra o prompt de comando elevado. Digite os comandos abaixo: sc config lanmanworkstation depende=bowser/mrxsmb10/mrxsmb20/nsi sc config mrxsmb10 start=auto
Portas de firewall abertas
Você pode encontrar esse problema ao acessar o nome da rede por meio de qualquer protocolo. Cada protocolo precisa de portas diferentes para iniciar e continuar a conexão. Portanto, você precisa garantir que as portas correspondentes estejam abertas para evitar o erro acima.
Primeiro, procure as portas necessárias na Internet ou em fontes oficiais. Em seguida, siga as etapas abaixo para verificar essas portas:
Abra Executar. Digite wf.msc e pressione Enter para abrir o Windows Defender Firewall com Segurança Avançada. Selecione Regras de entrada ou Regras de saída dependendo da sua situação. Em seguida, clique em Nova regra.
Marque Porta e clique em Avançar. Marque UDP ou TCP dependendo do seu cenário e digite o número da porta em Portas remotas específicas. Você pode usar vários separando-os com vírgulas.
Em seguida, clique em Avançar. Marque Permitir a conexão e clique em Avançar. Selecione os tipos de rede onde esta regra se aplica e selecione Avançar. Em seguida, insira qualquer nome e descrição que desejar para a regra e clique em Concluir.
Desativar software de segurança de terceiros
Softwares de segurança de terceiros, como antivírus e verificadores de rede, também podem bloquear o acesso de ou para um recurso de rede. Você pode tentar desativar temporariamente a segurança no lado do cliente ou no lado do host para evitar esse problema.
No entanto, lembre-se de que o software existe para proteger seu sistema. Portanto, você precisa ter certeza de que o recurso não é realmente perigoso antes de desativar a segurança em tempo real ou de rede.
Por outro lado, você também pode adicionar o recurso de rede ou usuário à lista de exclusão para resolva o erro sem desativar esse software. Se você não tiver acesso ao servidor, pode perguntar ao administrador do sistema se o servidor precisa criar uma exceção.
Redefinir permissões da pasta AppData
Se você estiver sofrendo de esse problema ao usar um aplicativo, como o Windows Subsystem para Linux, pode ser devido a alguns problemas com a pasta de usuário do aplicativo dentro do AppData. Uma das possíveis causas são configurações de permissão incorretas. Isso impede que o aplicativo acesse a pasta do usuário e impede o acesso a um recurso de rede.
Você pode resolver esse problema redefinindo as permissões da pasta AppData.
Abra Executar. Digite cmd e pressione Ctrl + Shift + Enter para abrir o Prompt de Comando Elevado. Digite o comando icacls %USERPROFILE%\AppData/q/c/t/reset
Descompactar ou descriptografar a pasta do usuário do aplicativo
Outro possível problema com a pasta do usuário do aplicativo envolve a compactação ou criptografia da pasta pelo sistema. Embora alguns aplicativos funcionem em tal cenário, há muitos outros que não funcionam.
Portanto, você precisa desativar a compactação ou criptografia NTFS da pasta. Para fazer isso,
Abra Executar. Digite %localappdata% e pressione Enter para entrar na pasta AppData\Local.
Procure a pasta do usuário do aplicativo dentro desta pasta. Se for um aplicativo fornecido pela Microsoft, você precisa procurar dentro de AppData\Local\Packages. Por exemplo, se você encontrar esse erro ao usar o Windows Subsystem for Linux, o nome da pasta dentro de Packages será o das distribuições do Linux. Clique com o botão direito na pasta e selecione Propriedades. Clique em Avançado na guia Geral. Desmarque Compactar conteúdo para economizar espaço em disco e Criptografar conteúdo para proteger os dados.
Clique em OK > OK para fechar as propriedades enquanto aplica as alterações.
Reinstalar completamente o aplicativo
Você também pode tentar desinstalar completamente os aplicativos de acesso à rede onde encontrar esse erro e reinstalar a versão mais recente para resolver o problema. Fazer isso também leva em conta quaisquer possíveis bugs presentes no próprio aplicativo.
Abra Executar. Digite appwiz.cpl e pressione Enter para abrir Programas e recursos. Procure seu aplicativo e selecione-o. Clique em Desinstalar e confirme se solicitado.
Siga as instruções no desinstalador. Em seguida, abra Executar novamente. Digite %localappdata% e pressione Enter para entrar na pasta AppData\Local. Procure a pasta do usuário do aplicativo dentro desta pasta. Se for um aplicativo fornecido pela Microsoft, você precisa procurar dentro de AppData\Local\Packages.
Exclua a pasta do usuário.
Agora, reinstale o aplicativo e veja se ainda encontra o erro.
Migre de FSR para DFSR
Se você encontrou este erro ao tentar promover o controlador de domínio nos servidores mais antigo que o Windows Server versão 1709, é porque o Serviço de Replicação de Arquivos (FRS) mais antigo não é mais suportado. Você precisa migrar de FSR para DFSR, e o nível funcional do domínio precisa ser 2008 ou superior para resolver esse problema.
Não é possível incluir todas as etapas necessárias neste artigo. Portanto, recomendamos seguir o guia de migração dedicado fornecido pela Microsoft ou um guia simplificado do usuário da Microsoft Tech Community para migrar para DFSR.
Revise seu código
Se você encontrou este erro ao executar um programa criado por você mesmo que acessa um recurso de rede, é provável que haja um problema com sua codificação.
Como há muitos lugares possíveis onde esses erros podem ocorrer, os mais comuns são os seguintes:
Tentando escrever em um fluxo que já está fechado pelo ponto remoto causará esse problema. Portanto, você precisa se certificar de não fechar o fluxo ou não permitir que o par feche o fluxo, a menos que a transferência de dados ou a comunicação esteja concluída. Outro motivo é o período de tempo limite definido ou padrão ser muito baixo em relação ao tempo necessário para concluir a consulta ou comunicação. Você simplesmente precisa estender esse período para resolver o problema.
Também pode haver outros erros em seu código. Recomendamos que você o envie para fóruns como o StackOverflow e procure a ajuda de outros usuários.