Como impedir que o samba retenha um bloqueio de arquivo depois que um cliente é desconectado?

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 samba (o perfil não é copiado localmente).

De vez em quando, um cliente pode não desligar 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 os 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 está bloqueado e nega acesso.

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

Edit: Nós gostaríamos de evitar a desativação bloqueios de arquivos no servidor samba, porque não são boas razões para ter aqueles habilitados.

as etapas abaixo me ajudaram a resolver esse problema exato em várias ocasiões:

1. Faça login no servidor samba.
2. Execute um "smbstatus".
3. Encontre o pid do processo que possui o bloqueio no arquivo na terceira seção da saída.
4. Verifique se ele corresponde ao usuário e nome do host esperados na primeira e na segunda seção da saída smbstatus.
5. Execute "ps -ef" e veja quanto tempo o smbd com esse pid está em execução.
6. Se estiver em execução desde antes da última reinicialização do computador, resta um smbd. Mate apenas aquele smbd. (E certifique-se de obter o caminho certo - ele deve ter um pid pai diferente de 1.)

Dê uma olhada em:

reset on zero vc = yes / no

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

Na smb.confpágina do manual:

Esta opção booleana controla se uma configuração de sessão recebida deve eliminar outras conexões provenientes do mesmo IP. Isso corresponde ao comportamento padrão do Windows 2003. Definir esse parâmetro como yes torna-se necessário quando você possui uma rede irregular e o Windows decide se reconectar enquanto a conexão antiga ainda possui arquivos com os modos de compartilhamento abertos. Esses arquivos se tornam inacessíveis pela nova conexão. O cliente envia um VC zero na nova conexão e o Windows 2003 mata todas as outras conexões provenientes do mesmo IP. Dessa forma, os arquivos bloqueados são acessíveis novamente. Por favor, esteja ciente de que ativar esta opção eliminará as conexões atrás de um roteador mascarado.

Edit :
Eu apenas pensei em outra solução possível. Você pode fazer algo assim no compartilhamento em questão.

veto oplock files = /*.lock/

Isso apenas impediria bloqueios em arquivos .lock.

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

Até agora, para compatibilidade com PMEs, pois esse é realmente o comportamento padrão de vitória.

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

Maravilhosamente feito, Samba.org.

Eu estava com um problema semelhante, um cliente travou 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 assim é muito chato ter que matar o processo de samba. reset on zero vcparecia ser apenas a solução, mas supostamente foi removida do Samba4, embora a Versão 4.7.6 no Fedora (27) ainda a possua (possivelmente corrigida pelo RH). De qualquer forma, não ajudará muito, como a página de manual agora diz que só funciona com SMB1 (que não deve mais ser usado) e não faz nada nas conexões SMB2 e SMB3, a única maneira de lidar com isso é mencionada em o tópico vinculado por Micheal . Eu não sei a lógica por trás da remoção e o que há de tão ruimreset on zero vc, Consideraria usar o tempo limite do tcp para esse fim 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 interromperá a conexão 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 reiniciar (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).

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

Você pode desativar os bloqueios por compartilhamento com o seguinte:

[acctdata]
oplocks = False
level2 oplocks = False

O tipo de bloqueio padrão é Nível1. Os bloqueios de nível 2 são ativados por compartilhamento no arquivo smb.conf. Como alternativa, você pode desativar os bloqueios por arquivo no compartilhamento:

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

Se você estiver enfrentando problemas com os bloqueios, como é aparente nas entradas de log do Samba, convém jogar com segurança e desativar os bloqueios e os bloqueios de nível 2.

Desativando bloqueios do kernel Os oplocks do kernel são um parâmetro smb.conf que notifica o Samba (se o kernel UNIX tiver a capacidade de enviar uma interrupção no bloqueio do cliente Windows) quando um processo UNIX estiver tentando abrir o arquivo em cache. Esse parâmetro aborda o compartilhamento de arquivos entre o UNIX e o Windows com os oplocks ativados no servidor Samba: o processo UNIX pode abrir o arquivo bloqueado (em cache) pelo cliente Windows e o processo smbd não envia uma interrupção de bloqueio, o que expõe o arquivo a o risco de corrupção de dados. Se o kernel do UNIX tiver a capacidade de enviar uma interrupção de bloqueio, o parâmetro kernel oplocks permitirá que o Samba envie a interrupção de bloqueio. Os oplocks do kernel são ativados por servidor no arquivo smb.conf.

kernel oplocks = yes

O padrão é não.

Fonte