Como evitar que o samba mantenha um bloqueio de arquivo depois que um cliente se desconecta?

Question

Aqui eu tenho um servidor Samba (Debian 5.0) que está configurado para hospedar perfis do Windows XP.

Os clientes se conectam a este servidor e trabalham em seus perfis diretamente no compartilhamento de samba (o perfil não é copiado localmente).

De vez em quando, um cliente pode não ser desligado corretamente e, portanto, o Windows não libera os bloqueios de arquivo. Ao olhar para a tabela de bloqueio do samba, podemos ver que muitos arquivos ainda estão bloqueados, mesmo que o cliente não esteja mais conectado. No nosso caso, isso parece ocorrer com arquivos de bloqueio criados pelo Mozilla Thunderbird e Firefox. Aqui está um exemplo da tabela de bloqueio do samba:

# smbstatus -L | grep DENY_ALL | head -n5
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
15494        10345      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user1   app.profile/user1.thunderbird/parent.lock   Mon Nov 22 07:12:45 2010
18040        10454      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user2   app.profile/user2.thunderbird/parent.lock   Mon Nov 22 11:20:45 2010
26466        10056      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user3   app.profile/user3.firefox/parent.lock   Mon Nov 22 08:48:23 2010

Podemos ver que os arquivos foram abertos pelo Windows e impuseram um bloqueio DENY_ALL.

Agora, quando um cliente se reconecta a esse compartilhamento e tenta abrir esses arquivos, o samba diz que eles estão bloqueados e negam acesso.

Existe alguma maneira de contornar essa situação ou estou faltando alguma coisa?

Editar: Gostaríamos de evitar desabilitar os bloqueios de arquivos no servidor samba porque são bons motivos para ativá-los.

    

Answer 1

Os passos abaixo ajudaram-me a resolver este problema em diversas ocasiões:

1. Faça login no servidor do samba.
2. Execute um "smbstatus".
3. Encontre o pid do processo que tem o bloqueio no arquivo  na terceira seção da saída.
4. Verifique se corresponde ao usuário e ao nome do host esperados  na primeira e segunda seções da saída do smbstatus.
5. Execute "ps -ef" e veja quanto tempo o smbd com esse pid tem  foi executado.
6. Se estiver em execução desde antes do último computador  reiniciado, é uma sobra de smbd. Mate apenas aquele smbd.  (E certifique-se de pegar o caminho certo - deve ser um  que tem um pai pid diferente de 1.)

Answer 2

Dê uma olhada:

reset on zero vc = yes / no

e veja se isso resolverá seu problema ou não.

Na página smb.conf man:

This boolean option controls whether an incoming session setup should kill other connections coming from the same IP. This matches the default Windows 2003 behavior. Setting this parameter to yes becomes necessary when you have a flaky network and windows decides to reconnect while the old connection still has files with share modes open. These files become inaccessible over the new connection. The client sends a zero VC on the new connection, and Windows 2003 kills all other connections coming from the same IP. This way the locked files are accessible again. Please be aware that enabling this option will kill connections behind a masquerading router.

Editar :
Acabei de pensar em outra solução possível. Você poderia fazer algo assim no compartilhamento em questão.

veto oplock files = /*.lock/

Isso apenas evitaria oplocks em arquivos .lock.

    

Answer 3

Algumas pessoas muito inteligentes no Samba decidiram remover esta opção e não há substituto para ela.

Até agora, para compatibilidade com o SMB, já que esse é, de fato, o comportamento padrão do win.

A menos que um usuário seja versado na linha de comando do linux e saiba como matar arquivos / processos abertos, é necessário reiniciar o SMBD ou o próprio servidor para limpar isso.

Maravilhosamente feito, Samba.org.

    

Answer 4

Eu estava correndo em um problema semelhante, um cliente falhou ao copiar um arquivo grande e o arquivo foi bloqueado após a reinicialização. Felizmente isso não acontece com muita frequência, mas ainda é muito chato ter que matar o processo de samba. reset on zero vc pareceu ser apenas a solução, mas supostamente foi removida do Samba4, embora a Versão 4.7.6 no Fedora (27) ainda a tenha (possivelmente corrigida por RH). Não vai ajudar muito de qualquer maneira, como a página de manual agora diz, ele só funciona com o SMB1 (que não deve mais ser usado) e não faz nada em conexões SMB2 e SMB3, a única maneira de lidar com isso é mencionado no tópico vinculado por Micheal . Eu não sei a razão por trás da remoção e o que há de tão ruim em reset on zero vc , eu consideraria usar o tcp timeout para esse propósito mais como um hack. De qualquer forma, algo razoável poderia ser, por exemplo,

socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3

Isso matará a conexão em cerca de 40 segundos (30 + 3 * 3) após a última comunicação, o que geralmente é mais do que suficiente para perceber uma falha e reinicialização (dado que a pilha tcp do servidor é inteligente o suficiente para fechar a conexão quando o cliente rejeita seus pacotes keepalive após a reinicialização).

Note que isso aumenta a carga na sua rede, mas duvido que seja até perceptível mesmo com muitos clientes.