¿Cómo evitar que samba mantenga un bloqueo de archivo después de que un cliente se desconecta?

11

Aquí tengo un servidor Samba (Debian 5.0) que está configurado para alojar perfiles de Windows XP.

Los clientes se conectan a este servidor y trabajan en sus perfiles directamente en el recurso compartido de samba (el perfil no se copia localmente).

De vez en cuando, un cliente puede no cerrarse correctamente y, por lo tanto, Windows no libera los bloqueos de archivos. Cuando miramos la tabla de bloqueo de samba, podemos ver que muchos archivos aún están bloqueados aunque el cliente ya no esté conectado. En nuestro caso, esto parece ocurrir con los archivos de bloqueo creados por Mozilla Thunderbird y Firefox. Aquí hay un ejemplo de la tabla de bloqueo de 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 Windows abrió los archivos e impuso un bloqueo DENY_ALL.

Ahora, cuando un cliente se vuelve a conectar a este recurso compartido e intenta abrir esos archivos, samba dice que están bloqueados y niega el acceso.

¿Hay alguna forma de evitar esta situación o me estoy perdiendo algo?

Editar: Nos gustaría no tener que desactivar los bloqueos de archivo en el servidor Samba, porque no son buenas razones para tener los habilitados.

linux samba server-message-block

— Jean-Francois Chevrette
fuente

11

Los siguientes pasos me han ayudado a resolver este problema exacto en varias ocasiones:

Inicie sesión en el servidor samba.
Ejecute un "smbstatus".
Encuentre el pid del proceso que tiene el bloqueo en el archivo en la tercera sección de la salida.
Verifique que coincida con el usuario esperado y el nombre de host en la primera y segunda sección de la salida smbstatus.
Ejecute "ps -ef" y vea cuánto tiempo ha estado funcionando el smbd con ese pid.
Si se ha estado ejecutando desde antes de que la computadora se reiniciara por última vez, es un smbd sobrante. Mata solo a ese smbd. (Y asegúrese de obtener el correcto, debe ser uno que tenga un padre pid no igual a 1.)

— Socceroos
fuente

Además, es posible que algunos pids de smbd se hayan ejecutado durante algunas horas y que los archivos que han bloqueado sean los que necesita. Como arriba, simplemente elimine estos procesos y debería estar bien. Si accidentalmente mata el proceso smbd principal, puede reiniciarlo con este comando: sudo /etc/init.d/smbd restart

— Socceroos

5

Mira esto:

reset on zero vc = yes / no

y vea si eso solucionará su problema o no.

Desde la smb.confpágina del manual:

Esta opción booleana controla si una configuración de sesión entrante debería eliminar otras conexiones que provienen de la misma IP. Esto coincide con el comportamiento predeterminado de Windows 2003. Establecer este parámetro en sí se hace necesario cuando tiene una red débil y Windows decide volver a conectarse mientras la conexión anterior todavía tiene archivos con modos compartidos abiertos. Estos archivos se vuelven inaccesibles a través de la nueva conexión. El cliente envía un VC cero en la nueva conexión y Windows 2003 elimina todas las demás conexiones que provienen de la misma IP. De esta manera, los archivos bloqueados son accesibles nuevamente. Tenga en cuenta que habilitar esta opción eliminará las conexiones detrás de un enrutador enmascarado.

Editar :
Acabo de pensar en otra posible solución. Podrías hacer algo así en el recurso compartido en cuestión.

veto oplock files = /*.lock/

Esto solo evitaría bloqueos en los archivos .lock.

— 3dinfluence
fuente

0

Algunas personas muy inteligentes en Samba decidieron eliminar esta opción y no hay reemplazo para ella.

Hasta ahora para la compatibilidad con SMB, ya que este es el comportamiento predeterminado de ganar.

A menos que un usuario esté versado en la línea de comandos de Linux y cómo matar archivos / procesos abiertos, debe reiniciar SMBD o el servidor para borrar esto.

Maravillosamente hecho, Samba.org.

— Miguel
fuente

¿Tienes una cita para esto?

— BE77Y

Vas a tener que mirar un poco para llegar allí, pero: lists.samba.org/archive/samba-technical/2011-July/078621.html (muestra el proceso de pensamiento y grietas que abogan para que no se eliminarán) listas .samba.org / archive / samba-technical / 2008-October / ... (muestra que el parámetro se ha eliminado en 4.0)

— Michael

A partir de 2019, en Debian 9 - Samba 4.5.12, la reset on zero vcopción todavía aparece en el manual y también se muestra en testparm. Entonces, o está de regreso, o realmente no se había eliminado.

— mivk

0

Me encontraba con un problema similar, un cliente se bloqueó al copiar un archivo grande y el archivo se bloqueó después del reinicio. Afortunadamente, esto no sucede muy a menudo, pero aún así es bastante molesto tener que matar el proceso de samba. reset on zero vcparecía ser solo la solución, pero supuestamente se eliminó de Samba4, aunque la versión 4.7.6 en Fedora (27) todavía la tiene (posiblemente parcheada por RH). De todos modos, no ayudará mucho, como dice la página del manual, que solo funciona con SMB1 (que ya no se debe usar) y no hace nada en las conexiones SMB2 y SMB3, la única forma que queda para manejar esto se menciona en El hilo vinculado por Micheal . No sé la razón detrás de la eliminación y qué tiene de maloreset on zero vc, Consideraría usar tcp timeout para este propósito más como un hack. De todos modos, algo razonable podría ser, por ejemplo

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

Esto eliminará la conexión aproximadamente 40 segundos (30 + 3 * 3) después de la última comunicación, que generalmente es más que suficiente para notar un bloqueo y reiniciar (dado que la pila tcp del servidor es lo suficientemente inteligente como para cerrar la conexión cuando el cliente rechaza sus paquetes keepalive después del reinicio).

Tenga en cuenta que esto aumenta la carga en su red, pero dudo que sea notable incluso con muchos clientes.

— Jakob
fuente

¿Sabe si esto ayuda con el extraño problema del hilo zombie del cliente Windows10 "nobody nogroup"? Muchos de mis clientes de Windows10 en varios sitios han comenzado a dejar cientos (ocasionalmente miles) de hilos de zombis que se asignan a "nadie nogroup" hasta que su proceso de controlador se cancela / se retira. La configuración normal más deadtime = 10o menos lo eliminaría, pero con los bloqueos de archivos persistentes en las conexiones SMB3_11 para siempre, no tiene ningún efecto, ya que el tiempo muerto no se verificará mientras existan bloqueos de archivos para un PID. Extremadamente frustrante.

— zxq9

Nunca escuché o experimenté el problema que usted describe. deadtimeno hace nada si sus clientes tienen archivos abiertos, por lo que la pregunta sería qué archivos mantienen abiertos. Pero ese es probablemente un tema completamente diferente al discutido aquí, por lo que debería abrir una nueva pregunta para esto. Mi socket optionssugerencia solo ayuda con conexiones que no están cerradas correctamente (porque los clientes se bloquean, una interrupción de la red, etc.), pero probablemente no si sus clientes WX simplemente se conectan al servidor sin ninguna otra acción o utilizando algún tipo de sesión anónima (lo que nobody.nogroupsugiere )

— Jakob

Parece que hay una pregunta sobre este problema, pero sin una solución real. Parece que podría ser un problema de samba que podría solucionarse en una versión más reciente.

— Jakob

Hay bastantes menciones de esto en la lista de correo, no se ha presentado ninguna solución real en ninguna parte, y ninguna versión que haya probado (cada rama actual pero 4.9) soluciona el problema. Es solo con clientes Windows10. Lo de nobody: nogroup es desconcertante, ya que los invitados están deshabilitados globalmente, ningún recurso compartido los acepta, y el PID de las entradas de nobody siempre es el mismo que una entrada válida única con un nombre de usuario válido. Entonces verá 12345 someuser somegroup...en una entrada, luego 800 12345 nobody nogroup ...entradas, pero solo un puñado de bloqueos de archivos (no 800). Muy raro. Afecta a 3 de mis sitios de clientes ahora.

— zxq9

Esto solo se convierte en una limitación de recursos en sitios de alta actividad, por lo que creo que recibe tan poca atención. La mayoría de las veces no hay un problema, por lo que las personas simplemente no lo notan y se aclara cuando los clientes realmente cierran su conexión.

— zxq9

0

Puede deshabilitar oplocks por acción con lo siguiente:

[acctdata]
oplocks = False
level2 oplocks = False

El tipo de bloqueo predeterminado es Level1. Los bloqueos de nivel 2 se habilitan por acción en el archivo smb.conf. Alternativamente, puede deshabilitar oplocks por archivo dentro del recurso compartido:

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

Si tiene problemas con los bloqueos opcionales, como se desprende de las entradas de registro de Samba, es posible que desee jugar de forma segura y deshabilitar los bloqueos oplocks y Level2.

Deshabilitar los bloqueos opcionales del núcleo Los bloqueos opcionales del núcleo es un parámetro smb.conf que notifica a Samba (si el núcleo UNIX tiene la capacidad de enviar a un cliente de Windows una interrupción de bloqueo) cuando un proceso UNIX intenta abrir el archivo que está en caché. Este parámetro aborda el intercambio de archivos entre UNIX y Windows con oplocks habilitados en el servidor Samba: el proceso UNIX puede abrir el archivo que está bloqueado (en caché) por el cliente de Windows y el proceso smbd no enviará una interrupción de bloqueo, lo que expone el archivo a El riesgo de corrupción de datos. Si el kernel de UNIX tiene la capacidad de enviar una interrupción de bloqueo, entonces el parámetro oplocks del núcleo permite que Samba envíe la interrupción de bloqueo. Los bloqueos de kernel se habilitan por servidor en el archivo smb.conf.

kernel oplocks = yes

El valor predeterminado es no.

Fuente

— ajcg
fuente