Duas ou mais máquinas Windows no mesmo workgroup enxergam uma à outra na rede, mas ao tentar acessar os compartilhamentos retornam o erro **3227320323**. A causa é uma **divergência na negociação de segurança do SMB 3.1.1** (assinatura/criptografia) entre as máquinas. A solução é **alinhar as configurações de assinatura SMB no cliente e no servidor** das máquinas envolvidas, com quatro comandos PowerShell.

## 1. Sintomas - As máquinas **aparecem** na aba "Rede" do Explorador de Arquivos. - Ao abrir `\\NOME-DO-PC` ou `\\IP`, aparece erro de acesso. - O `net use` retorna o código de erro **3227320323**. - Um cliente Linux (via `smbclient`/`cifs`) **consegue** acessar os mesmos compartilhamentos, o que prova que rede, roteador e servidor SMB estão funcionando. ## 2. Causa raiz O código `3227320323` em decimal equivale a `0xC0590003`, que é o status **STATUS\_SMB\_NO\_PREAUTH\_INTEGRITY\_HASH\_OVERLAP**. Isto significa que cliente e servidor **não conseguiram concordar** sobre os parâmetros de integridade/assinatura exigidos pelo **SMB 3.1.1** (o dialeto padrão entre Windows 10/11 modernos). A conexão é abortada **antes da autenticação**, por isso o problema não é usuário, senha nem acesso de convidado (guest): é o *handshake* de segurança do protocolo.

Por que o Linux acessa e o Windows não?

Um cliente Linux costuma negociar SMB 3.0, que **não usa** o *pre-auth integrity* do 3.1.1, então conecta normalmente. Dois Windows modernos negociam SMB 3.1.1 entre si e é exatamente aí que o handshake falha quando as políticas de assinatura/criptografia estão divergentes. Essa divergência normalmente é introduzida por: - Atualizações do Windows que endurecem o SMB em uma das máquinas. - Políticas de *hardening* (GPO local, scripts de segurança). - Antivírus/EDR que alteram os *cipher suites* ou a exigência de assinatura. ## 3. Diagnóstico (opcional, mas recomendado) Antes de alterar, confirme a assimetria. Em **cada** máquina, abra o **PowerShell como Administrador** e rode: ```powershell Get-SmbServerConfiguration | fl EncryptData, RejectUnencryptedAccess, RequireSecuritySignature, EnableSMB2Protocol Get-SmbClientConfiguration | fl RequireSecuritySignature, EnableSecuritySignature ``` Compare a saída das máquinas. Valores diferentes de `RequireSecuritySignature` ou `EncryptData` entre elas confirmam o problema. Em um PC, tente acessar o outro por IP: `net use \\192.168.0.10\NomeDoShare`. Se o erro for `3227320323`, siga para a solução abaixo. A correção consiste em **alinhar a política de assinatura SMB** no cliente e no servidor. Execute **nas duas (ou todas) as máquinas** envolvidas. ### 4.1 Abra o PowerShell como Administrador Menu Iniciar → digite *PowerShell* → clique com o botão direito → **Executar como administrador**. ### 4.2 Aplique os quatro comandos ``` # --- Configuração do SERVIDOR SMB (lado que compartilha) --- Set-SmbServerConfiguration -RequireSecuritySignature $false -Force Set-SmbServerConfiguration -EnableSecuritySignature $false -Force # --- Configuração do CLIENTE SMB (lado que acessa) --- Set-SmbClientConfiguration -RequireSecuritySignature $false -Force Set-SmbClientConfiguration -EnableSecuritySignature $false -Force ```

Aplique os **mesmos valores em todas** as máquinas que precisam se comunicar. O problema é a *divergência* entre elas, manter a configuração idêntica é o que resolve. Rode os quatro comandos em cada PC.

### 4.3 Reinicie os serviços e valide ``` # Reinicia os serviços SMB para aplicar Restart-Service LanmanServer -Force Restart-Service LanmanWorkstation -Force # Teste o acesso (ajuste IP e nome do compartilhamento) net use \\192.168.0.10\NomeDoShare ```

O comando conecta sem erro e o compartilhamento passa a abrir normalmente pelo Explorador de Arquivos.

## 5. Tabela de referência de erros relacionados

Código (decimal)	Hex / Status	Significado	Ação
`3227320323`	`0xC0590003` — NO\_PREAUTH\_INTEGRITY\_HASH\_OVERLAP	Falha na negociação de segurança do SMB 3.1.1.	Alinhar assinatura SMB (este guia).
`1272`	ERROR\_NETWORK\_ACCESS\_DENIED (guest)	Acesso de convidado não autenticado bloqueado.	Habilitar `AllowInsecureGuestAuth` ou usar conta com senha.
`53`	ERROR\_BAD\_NETPATH	Caminho de rede não encontrado (nome/descoberta).	Testar por IP; revisar WSD/arquivo `hosts`.
`5`	ERROR\_ACCESS\_DENIED	Credenciais ou permissões insuficientes.	Revisar conta/senha e permissões NTFS + compartilhamento.

## 6. Notas de segurança

Desabilitar a assinatura SMB (`RequireSecuritySignature $false`) reduz a proteção contra ataques de interceptação (man-in-the-middle). É **aceitável em uma rede local confiável e isolada**, mas **não é recomendado** em redes expostas ou corporativas sensíveis.

Alternativa mais segura: em vez de desabilitar, mantenha a assinatura/criptografia **habilitada e idêntica em todas as máquinas** (por exemplo `Set-SmbServerConfiguration -EncryptData $true` em todos). Assim elas voltam a concordar no SMB 3.1.1 sem abrir mão da proteção.

## 7. Perguntas frequentes ### Preciso reiniciar o computador? Não necessariamente. Reiniciar os serviços `LanmanServer` e `LanmanWorkstation` costuma ser suficiente. Em caso de dúvida, um reinício garante a aplicação. ### Funciona para mais de duas máquinas? Sim. Aplique os quatro comandos em todas as máquinas do workgroup que precisam se comunicar. ### E se depois disso aparecer "caminho de rede não encontrado"? Isso é um problema diferente, de *resolução de nome/descoberta*, não de SMB. Teste primeiro por IP (`\\192.168.0.10`). Se por IP funciona e por nome não, ajuste a descoberta de rede (serviços *Function Discovery* e *SSDP*) ou mapeie o nome no arquivo `C:\Windows\System32\drivers\etc\hosts`. ### Esse erro tem a ver com acesso de convidado (guest)? Não. O `0xC0590003` ocorre **antes** da autenticação. Guest é uma camada posterior. Se você também usa compartilhamento sem senha, pode precisar habilitar `AllowInsecureGuestAuth` separadamente, veja a tabela de erros.