Problemas com a movimentação de arquivos no compartilhamento - cliente Windows 7, Ubuntu 14 Server

Question

Nós temos uma configuração onde os arquivos são compartilhados de um servidor Ubuntu 14.04 para clientes Win 7.

Estamos lutando com um problema ao mover arquivos algumas vezes. É algo assim:

• Crie uma nova subpasta em compartilhamento e dê um nome a ela
• Tentativa de mover o arquivo existente no compartilhamento para a nova subpasta, provavelmente apenas alguns segundos depois de criar e renomear a nova pasta
• Erro causado "Há um problema ao acessar [nome do arquivo] .pdf - Verifique se você está conectado à rede e tente novamente"
• A caixa de erro tentou novamente, pule e cancele as opções. Tente novamente não fez nada, pule o erro fechado sem alteração visual no diretório (arquivo de destino ainda apareceu lá).
• Entrou na subpasta recém-criada e o arquivo foi movido com sucesso. No retorno ao diretório pai, não havia sinal no arquivo de destino, ou seja, ele foi movido para o local correto.

Não tenha conhecimento de mais ninguém acessando a pasta do projeto no momento

Resumo: movido corretamente, mas com mensagem de erro.

Alguém sabe o que pode causar isso ou como podemos resolver isso? Não parece haver nada óbvio nos registros do samba.

Samba Versão 4.1.6-Ubuntu

Este servidor específico está configurado como um BDC. O domínio é samba / ldap todo o caminho (sem controladores de domínio do Windows)

    

Answer 1

Tente adicionar isso ao seu registro de máquina Windows usando regedit:

Localização: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ LanmanWorkstation \ Parâmetros

Chave: "DirectoryCacheLifetime" = dword: 00000000

Isso corrigiu um problema especificamente para máquinas com Windows 7 (não com Windows 8 / 8.1) que encontrei com arquivos sendo salvos em um compartilhamento Samba por impressoras / scanners. Um novo arquivo pode levar muito tempo (10 minutos ou mais) para aparecer em uma listagem de diretórios do compartilhamento Samba por um cliente Windows 7, mesmo que ele esteja presente localmente. O novo arquivo pode ser visto imediatamente no Windows 7, criando um novo link para o compartilhamento por um diferente unc (por exemplo, \\ mysambaserver \ ourshare em vez de \\ 192.168.110.104 \ ourshare).

Parece provável que tenha sido causado por uma falha no SMB2, particularmente ou talvez apenas quando o arquivo foi carregado pelo SMB1 (como usado por impressoras / scanners com software interno comparativamente antigo para 'digitalizar para local de rede').

Um "hotfix" da Microsoft para um problema de som semelhante não ajudou, mas essa correção do registro resolveu o problema.

Embora seu problema tenha se manifestado de forma ligeiramente diferente, pode ser resolvido pela mesma correção, vale a pena tentar de qualquer maneira.