Existem vários motivos possíveis, dependendo dos detalhes do seu ambiente.
Se sua instalação do Windows 10 for originalmente a "Atualização de criadores de outono" ou mais recente, ela terá o SMBv1 do lado do cliente desabilitado por padrão. Isso foi motivado pela epidemia de ransomware WannaCry, que usou uma vulnerabilidade crítica no protocolo SMBv1.
Se o seu servidor de arquivos Linux (de distribuição e versão não especificadas?) não tiver sido atualizado com patches ou tiver uma configuração não padrão que não tenha sido revisada por um longo tempo, talvez ainda tenha o server max protocol de configuração em seu arquivo smb.conf sendo padronizado / definido como NT1 , o que significa SMBv1. Por causa da vulnerabilidade mencionada acima, você deve se livrar do SMBv1 em algum momento do ano passado.
Todas as distribuições Linux de nível corporativo há muito tempo publicam atualizações que permitem o uso de SMBv2 e / ou SMBv3 em qualquer versão suportada das distribuições. Portanto, se o servidor estiver atualizado, é apenas uma questão de verificar se o arquivo smb.conf não tem uma configuração estúpida de server max protocol e alterar a configuração para server max protocol = SMB3_02 ou melhor se tiver.
O SMBv1 estava há muito tempo programado para ser removido, e a descoberta dessa vulnerabilidade acelerou a programação de remoção.
Se o ambiente de rede do seu escritório usa o Active Directory, a descoberta de locais de rede provavelmente usa o AD, e o problema pode ser que o servidor de arquivos Linux não está conseguindo registrar os registros DNS apropriados no domínio do AD.
Se não houver o Active Directory, a descoberta dos locais de rede retornará ao antigo estilo NetBIOS, que pode usar um servidor WINS (é apenas uma função adicional em um ou mais hosts do servidor) ou pode depender apenas transmissões de cada servidor. Nesse caso, você precisará verificar se as portas 137 / UDP e 138 / UDP não estão bloqueadas, tanto no lado do cliente quanto no lado do servidor.