Problema para acessar compartilhamento de rede após atualização 2004 do Windows

augustonovaesjr · 23 de junho de 2020

Boa noite a todos.

Na empresa em que trabalho, temos um NAS Dlink DNS-320L, com uma pasta compartilhada, em uma rede com 15 PCS, e pelo menos 4 destes PCs, usam essa unidade mapeada

Porém, 2 destes PCs foram atualizados para a Build 2004 do Windows, e começaram a ter problemas de acesso a este compartilhamento, sendo que os demais PCs continuam acessando normalmente. E pra piorar a coisa, nestes 2 PCs existem outras unidades mapeadas, porém para pastas compartilhadas de outros PCs com Windows.E estes compartilhamentos continuam funcionando.

Quando o windows inicia, ao tentar acessar a unidade mapeada, apresenta a seguinte mensagem:

Erro ao reconectar a Z: a \\10.1.1.250\tmp

Microsoft Windows Network: O nome do dispositivo já está em uso.

Essa conexão não foi restaurada.

E se eu tento ir pelo Executar, apresenta a seguinte mensagem:

O nome da rede especificado não está mais disponível.

Apesar disso, tenho resposta de ping no dispositivo, e consigo acessar a página de configuração dele, via browser.

Para que eu consiga acessar o compartilhamento novamente, tenho que remover o mapeamento e reiniciar o PC (logout não funciona).. Aí posso mapear novamente, porém se eu fizer um logout, ou reiniciar o PC, o problema volta, aí fico nesse loop.

Os outros PCs que não foram atualizados continuam funcionando perfeitamente.

Alguém tem alguma ideia de como solucionar isto? Já cogitei uma formatação, porém só farei em ultíssimo caso, pois são 15 PCs que poderão em algum momento ser atualizados, e a maioria deles tem muita coisa para instalar e configurar após a formatação.

1) todos os 10 PCs são windows original, com norton security instalado e atualizado

2) já tentei desativar o antivirus e firewall dos 2 PCs com problema

3) já dei umas pesquisadas na internet, e tentei algumas coisas, mas sem sucesso.

4) toda a rede é com ip fixo e cabeada. Só usamos DHCP para máquinas temporárias e smartphones

Desde já agradeço a atenção

Augusto

Sidney Oss Emer · 17 de julho de 2020

Estou com o mesmo problema. O NAS não é mapeado, porém outros diretórios, sim.
Já revirei os fóruns atrás de uma solução, mas ainda não encontrei.

Algo que me chamou a atenção, é que no meu caso, das 40 máquinas do domínio, apenas as que tiveram um SO instalado em SSD apresentam o problema.

O Serviço de Client SMB 1.0 (utilizado pelo storage) está habilitado. O Windows consegue mapear, mas somente depois dos passos elencados pelo @augustonovaesjr.

augustonovaesjr · 23 de julho de 2020

Em 17/07/2020 às 11:59, Sidney Oss Emer disse:

Estou com o mesmo problema. O NAS não é mapeado, porém outros diretórios, sim.
Já revirei os fóruns atrás de uma solução, mas ainda não encontrei.

Algo que me chamou a atenção, é que no meu caso, das 40 máquinas do domínio, apenas as que tiveram um SO instalado em SSD apresentam o problema.

O Serviço de Client SMB 1.0 (utilizado pelo storage) está habilitado. O Windows consegue mapear, mas somente depois dos passos elencados pelo @augustonovaesjr.

Aqui ainda sem solução, infelizmente..

Em relação ao que você mencionou sobre o SSD, aqui nem tenho como verificar, pois todas as maquinas são SSD.

Att

Odair Rubleski · 28 de julho de 2020

Bom dia, também estou enfrentando este problema. Iniciou após a atualização 2004 do windows 10. Realizo os mesmos procedimentos citados pelo @augustonovaesjr para restabelecer a conexão com as unidades de rede. O detalhe é que as unidades que não necessitam de autenticação continuam acessando normalmente, não são afetadas. Outra coisa que percebi: se na inicialização as unidades de rede que perderam o acesso estão mapeadas pelo ip (\\192.168.0.5\rh), eu consigo fazer o acesso e remapea-las pelo nome do servidor (\\Arquivos\rh) sem problemas e vice e versa.

@Sidney Oss Emer, em relação ao SSD, minhas máquinas estão apresentando o problema em ambos os casos.

Obrigado.

Odair Rubleski

Ftoffoli · 30 de julho de 2020

@augustonovaesjr @Odair Rubleski , estava enfrentando o mesmo problema e não achei uma solução. Para contornar a situação eu fiz o seguinte:
1 - Criei um arquivo .bat;

2 - Dentro desse arquivo:
net use letradocompartilhamento: /delete
net use letradocompartilhamento: \\nomedoservidor\compartilhamento

net use letradocompartilhamento: \\ipdoservidor\compartilhamento

3 - Coloquei esse .bat na inicialização do Windows na máquina que apresentou o problema e funcionou.

Fazendo isso você não tera mais problemas

adicionado 1 minuto depois

@Sidney Oss Emer

Odair Rubleski · 30 de julho de 2020

@Ftoffoli Fantástico, problema resolvido. No meu caso, não utilizei a linha que mapeia via ip do servidor apenas pelo nome. Gravei as informações de login do usuário salvas no gerenciador de credenciais e não fiz o mapeamento manual.

Muito obrigado.

Stevan.deorce · 5 de setembro de 2020

A ideia do arquivo .bat na inicialização foi muito boa e contornou o problema, mas como não achei uma solução que eliminasse a causa básica. Como a versão 2004 possui outros problemas eu reinstalei a versão 1909.
Achei essa proposta e o usuário disse que resolveu: https://answers.microsoft.com/en-us/windows/forum/all/win-10-may-upgrade-2004-brake-network-shares/3ab3eaf8-6332-4a09-a190-ad2b8e4334b1
Alguém mais tentou?

EduardoKosx · 11 de setembro de 2020

@augustonovaesjr Estou com esse mesmo problema. Porém puder confirmar que o problema está na versão 2004 do Windows 10. Digo isso porque na empresa temos 5 maquinas com o Win10, e somente uma delas não apresenta esse problema, e é justamente a que está com a versão 1909.

adicionado 21 minutos depois

@Stevan.deorce Segui as instruções do link, mas pra mim não deu certo. Espero que a MS agilize e libere logo uma correção para isso.

mcx.scyther · 15 de setembro de 2020

Prezados,

PROBLEMA:

O meu problema é exatamente como relatado pelo usuário: augustonovaesjr:

--------- augustonovaesjr -----
Quando o windows inicia, ao tentar acessar a unidade mapeada, apresenta a seguinte mensagem:

Erro ao reconectar a Z: a \\10.1.1.250\tmp

Microsoft Windows Network: O nome do dispositivo já está em uso.

Essa conexão não foi restaurada.
---------

SOLUÇÃO:
Solução que deu certo para mim foi a relatada pelo usuário: Ftoffoli

----- Ftoffoli ---------------

1 - Criei um arquivo .bat;

2 - Dentro desse arquivo:
net use letradocompartilhamento: /delete
net use letradocompartilhamento: \\nomedoservidor\compartilhamento

net use letradocompartilhamento: \\ipdoservidor\compartilhamento

3 - Coloquei esse .bat na inicialização do Windows na máquina que apresentou o problema e funcionou.
---------

Eu fiz algumas adaptações:
1) rodar o script em Background
2) coloquei um timer de 30s após o comando "flushdns". No meu caso após remover os mapeamentos tive que usar o comando "ipconfig /flushdns", e constatei que era preciso aguardar alguns segundos para surtir efeito, por isso o timer.

Segue os meus scripts:

** script vbs - backgrond.vbs

Apontamento: Deixem o script.bat na mesma pasta que o script.vbs ele só serve para executar o script.bat em modo background.

------ inicio script ---

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "script.bat", 0

------ fim script ---

** script.bat
------ inicio script ---

ipconfig /flushdns
timeout /T 30

net use * /delete /y

ipconfig /flushdns
timeout /T 30

NET USE Z: \\<repositorio>\<domínio> /USER:<domínio>\<nome usuário>

ipconfig /flushdns

------ fim script ---

Exemplo:
DOMÍNIO: MCX
NET USE Z: \\repositorio.rs.pas.edu.br\MCX /USER:mcx\juca.pipoca

Andre P. Ferreira · 17 de setembro de 2020

Estou com o mesmo problema, percebi que ao substiuir o ip do servidor pelo nome o acesso ao compartilhamento funcionou.

hbt86 · 22 de setembro de 2020

Bom dia,

Eu estava com a mesma dificuldade após atualização do windows 10 (2004), eu acesso de diversos PC´s um NAS na rede, ao tentar acessar ele exibia a mensagem:

"O nome da rede especificado não está mais disponível."

Ao desconectar e remapear o NAS, voltava a funcionar, mas bastava desligar a maquina que o erro voltava.

Aqui eu percebi que ao ligar o PC, ele exibia a mensagem que estava voltando de hibernação, ou seja, por algum motivo após a atualização o PC fica com a Opção de inicialização rápida ativa e isto gera algum conflito. Então a solução para o meu caso foi desativar a inicialização rápida. Fiz em 3 maquinas e funcionou. Aqui eu fiz da seguinte maneira:

Painel de controle
Opções de energia
Alterar o funcionamento dos botões de energia
Clicar em "Alterar configurações não disponíveis no momento"
Desmarcar a caixa da opção "Ligar inicialização rápida"
Salvar alterações

arfneto · 22 de setembro de 2020

Lembro que uma das opções de NET Use é /PERSISTENT que mantém o mapeamento ativo

Não é preciso ter um script de login para isso

Em 15/09/2020 às 17:23, mcx.scyther disse:

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "script.bat", 0

Se tem um script rodando porque não rodar os comandos aí mesmo ao invés de um script para rodar um batch em outro arquivo?

No Windows em compmgmt.msc pode vincular o acesso ao NAS no perfil do usuário

estabelecendo a pasta base para o usuário.

E usar o script de logon para verificar, se acaso um mapeamento persistente não está funcionando. Veja acima a opção.

Em 15/09/2020 às 17:23, mcx.scyther disse:

coloquei um timer de 30s após o comando "flushdns". No meu caso após remover os mapeamentos tive que usar o comando "ipconfig /flushdns", e constatei que era preciso aguardar alguns segundos para surtir efeito, por isso o timer

Se acessa o NAS pelo endereço IP e não pelo nome não precisa se preocupar com DNS. Apenas use o IP

Se precisa de flushDNS e faz diferença de fato pode ser porque deixou o endereço mudar e é um pouco ingênuo fazer isso com algo compartilhado, em especial um troço que foi feito com isso em mente como o NAS.

Se não tem DNS interno, apenas use um endereço fixo para o NAS, reservando um IP direto no servidor DHCP, seja um servidor de fato ou o roteador que provê isso. Assim sempre que o endereço for renovado vai ser o mesmo e nunca vai precisar de flushDNS.

Maico Tamanho · 2 de fevereiro de 2021

Olá pessoal.

Tive o mesmo problema após atualizar para a versão 2004 e 20H2. O estranho é que apenas um mapeamento que utiliza um servidor Lixux é que dava erro e não mapeava ao reiniciar o computador.

Encontrei uma solução que funcionou para mim. Adicionei a seguinte chave no registro do Windows para a unidade mapeada, que no meu caso era a X:

[HKEY_CURRENT_USER\Network\X]

"ProviderFlags"=dword:00000001

Espero ter ajudado.

Grande abraço.

Hanniel Gondim · 23 de fevereiro de 2021

Problema persiste aqui pra mim. é um servidor linux/oracle, tem um script de mapeamento no logon para cada usuário no AD, tem horas que reinicio a maquina do usuário e o mapeamento volta, aí reinicio de novo e ele some, antes tava dando o mesmo erro* dito acima porém agora o mapeamento some.

*"Microsoft Windows Network: O nome do dispositivo já está em uso.

Essa conexão não foi restaurada."

Quando tento acessar o servidor que é o \\192.168.1.2 aparece a mensagem:

Aí tenho que esperar um tempo para conseguir acessar novamente:

é como se na inicialização do windows ele não conseguisse ter uma comunicação com o servidor linux/oracle.

Aí tenho que ou reiniciar ou então mapear a unidade novamente.

Tenho já no script uma opção de desmapear uma unidade e mapear novamente.

Já pesquei vários fóruns porém sem sucesso, alguma luz?

Maico Tamanho · 25 de fevereiro de 2021

Olá,

Primeiro, se você estiver com a versão 2004, recomendo atualizar para a 20H2. Isso não resolve o problema mas torna a solução abaixo mais "estável".

Em seguida, remova as chaves de registro referente ao seu mapeamento. No caso do exemplo estou utilizando a letra X.
HKEY_CURRENT_USER\Network\X (Remover a letra X)

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU remova a entrada referente a seu drive mapeado(a, b, etc).

Crie o mapeamento novamente e adicione o registro abaixo para a unidade em questão (d-word 32bits).
[HKEY_CURRENT_USER\Network\X]
"ProviderFlags"=dword:00000001

Adicione também o seguinte parâmetro
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"AllowInsecureGuestAuth"=dword:1

Outra recomendação é ativar o protocolo SMB1 através dos comandos (executar no CMD como Administrador):

C:\Windows\system32\dism /online /enable-feature /all /featurename:SMB1Protocol
C:\Windows\system32\dism /online /enable-feature /all /featurename:SMB1Protocol-Client
C:\Windows\system32\dism /online /enable-feature /all /featurename:SMB1Protocol-Server
C:\Windows\system32\dism /online /enable-feature /all /featurename:SMB1Protocol-Deprecation

Isso tudo parece ter resolvido meu problema.

Hanniel Gondim · 11 de março de 2021

Problema ainda persiste aqui pra mim, segue mais erro:

"O Local não está disponível"

"P:\ não está acessível

"O nome da rede especificado não está mais disponível"

"O windows não pode acessar \\192.168.1.2"

"Verifique a ortografia do nome. Caso contrário, pode ocorrer um problema na rede. Para tentar identificado e resolver problemas de rede clique em Diagnosticar."

"Código de erro: 0x80004005"
"Erro não especificado"

Lembrando que esse servidor de ip 192.168.1.2 é um servidor Oracle, um banco de dados como explicado um post acima.

Leandro Lodetti · 22 de outubro de 2021

Todos os problemas com as atualizações dos Windows 10 e linha server também onde você não consegue ver o mapeamento, podem ser resolvidos com os comandos abaixo.

A partição SMBv1 foi desabilitado nas atualizações por questões de segurança segundo a Microsoft.

Métodos do PowerShell

SMBv1 (cliente e servidor)

Detectar:

PowerShellCopiar

Get-WindowsOptionalFeature -Online -FeatureName smb1protocol

Desativar:

PowerShellCopiar

Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Habilitar:

PowerShellCopiar

Enable-WindowsOptionalFeature -Online -FeatureName smb1protocol