Comment empêcher Samba de maintenir un verrou de fichier après la déconnexion d'un client?


11

Ici, j'ai un serveur Samba (Debian 5.0) qui est configuré pour héberger les profils Windows XP.

Les clients se connectent à ce serveur et travaillent sur leurs profils directement sur le partage samba (le profil n'est pas copié localement).

De temps en temps, un client peut ne pas s'arrêter correctement et donc Windows ne libère pas les verrous de fichiers. En regardant la table de verrouillage de samba, nous pouvons voir que de nombreux fichiers sont toujours verrouillés même si le client n'est plus connecté. Dans notre cas, cela semble se produire avec les fichiers de verrouillage créés par Mozilla Thunderbird et Firefox. Voici un exemple de la table de verrouillage 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

Nous pouvons voir que les fichiers ont été ouverts par Windows et ont imposé un verrou DENY_ALL.

Désormais, lorsqu'un client se reconnecte à ce partage et essaie d'ouvrir ces fichiers, samba dit qu'ils sont verrouillés et refuse l'accès.

Existe-t-il un moyen de contourner cette situation ou ai-je raté quelque chose?

Edit: Nous aimerions éviter de désactiver les verrous de fichiers sur le serveur samba car il y a de bonnes raisons de les activer.

Réponses:


11

les étapes ci-dessous m'ont aidé à résoudre ce problème exact à plusieurs reprises:

  1. Connectez-vous au serveur samba.
  2. Exécutez un "smbstatus".
  3. Recherchez le pid du processus qui a le verrou sur le fichier dans la troisième section de la sortie.
  4. Vérifiez qu'il correspond à l'utilisateur et au nom d'hôte attendus dans les première et deuxième sections de la sortie smbstatus.
  5. Exécutez "ps -ef" et voyez depuis combien de temps le smbd avec ce pid fonctionne.
  6. S'il a fonctionné depuis avant le dernier redémarrage de l'ordinateur, c'est un smbd restant. Tuez JUSTE QUE UN smbd. (Et assurez-vous que vous obtenez le bon - il devrait être celui qui a un pid parent différent de 1.)

En outre, vous pouvez constater que certains pids smbd fonctionnent depuis quelques heures et que les fichiers qu'ils ont verrouillés sont ceux dont vous avez besoin. Comme ci-dessus, tuez simplement ces processus et tout ira bien. Si vous tuez par inadvertance le processus smbd principal, vous pouvez le redémarrer avec cette commande: sudo /etc/init.d/smbd restart
Socceroos

5

Jettes un coup d'oeil à:

reset on zero vc = yes / no

et voyez si cela résoudra votre problème ou non.

Depuis la smb.confpage de manuel:

Cette option booléenne contrôle si une configuration de session entrante doit tuer les autres connexions provenant de la même IP. Cela correspond au comportement par défaut de Windows 2003. La définition de ce paramètre sur oui devient nécessaire lorsque vous avez un réseau instable et que Windows décide de se reconnecter alors que l'ancienne connexion a toujours des fichiers avec des modes de partage ouverts. Ces fichiers deviennent inaccessibles sur la nouvelle connexion. Le client envoie un VC nul sur la nouvelle connexion et Windows 2003 tue toutes les autres connexions provenant de la même IP. De cette façon, les fichiers verrouillés sont à nouveau accessibles. Veuillez noter que l'activation de cette option supprimera les connexions derrière un routeur de masquage.

Edit :
je viens de réfléchir à une autre solution possible. Vous pouvez faire quelque chose comme ça sur le partage en question.

veto oplock files = /*.lock/

Cela empêcherait simplement les oplocks sur les fichiers .lock.


0

Certaines personnes très intelligentes chez Samba ont décidé de supprimer cette option et il n'y a pas de remplacement pour elle.

Jusqu'à présent pour la compatibilité SMB, car il s'agit en effet d'un comportement gagnant par défaut.

À moins qu'un utilisateur ne connaisse la ligne de commande Linux et comment tuer les fichiers / processus ouverts, vous devez redémarrer SMBD ou le serveur lui-même pour effacer cela.

Merveilleusement fait, Samba.org.


Avez-vous une citation pour cela?
BE77Y

Vous devrez en regarder quelques-uns pour y arriver, mais: lists.samba.org/archive/samba-technical/2011-July/078621.html (montrer le processus de réflexion et les chaps plaidant pour qu'il ne soit pas supprimé) listes .samba.org / archive / samba-technical / 2008-octobre /… (montre que le paramètre a été supprimé dans 4.0)
Michael

Depuis 2019, dans Debian 9 - Samba 4.5.12, l' reset on zero vcoption est toujours répertoriée dans le manuel, et également affichée par testparm. Donc, soit il est de retour, soit il n'a vraiment pas été supprimé.
mivk

0

Je rencontrais un problème similaire, un client s'est écrasé lors de la copie d'un fichier volumineux et le fichier a été verrouillé après le redémarrage. Heureusement, cela ne se produit pas très souvent, mais c'est quand même assez ennuyeux de devoir tuer le processus de samba. reset on zero vcsemblait être juste la solution, mais il est censé avoir été supprimé de Samba4, bien que la version 4.7.6 sur Fedora (27) l'ait toujours (éventuellement corrigé par RH). De toute façon, comme le dit la page de manuel, cela n'aidera pas beaucoup, car cela ne fonctionne qu'avec SMB1 (qui ne devrait plus être utilisé) et ne fait rien sur les connexions SMB2 et SMB3, la seule façon de gérer cela est mentionnée dans le fil lié par Micheal . Je ne connais pas la justification de la suppression et ce qui est si mauvaisreset on zero vc, J'envisagerais d'utiliser le délai d'attente tcp à cette fin plus comme un hack. Quoi qu'il en soit, quelque chose de raisonnable pourrait être par exemple

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

Cela tuera la connexion environ 40 secondes (30 + 3 * 3) après la dernière communication, ce qui est généralement plus que suffisant pour remarquer un crash et un redémarrage (étant donné que la pile TCP du serveur est suffisamment intelligente pour fermer la connexion lorsque le client rejette ses paquets keepalive après le redémarrage).

Notez que cela augmente la charge sur votre réseau, mais je doute que cela soit même perceptible même avec de nombreux clients.


Savez-vous si cela aide à résoudre le problème de thread zombie du client Windows10 bizarre "personne ne nogroupe"? Beaucoup de mes clients Windows10 sur plusieurs sites ont commencé à laisser des centaines (parfois des milliers) de threads zombies qui sont assignés à "personne nogroupe" jusqu'à ce que leur processus de gestionnaire soit tué / se retire. Normalement, la définition de deadtime = 10ou ainsi le supprimerait, mais avec les verrous de fichier persistants sur les connexions SMB3_11 pour toujours, cela n'a aucun effet, car le temps mort ne sera pas vérifié pendant que les verrous de fichier pour un PID existent toujours. Extrêmement frustrant.
zxq9

Je n'ai jamais entendu parler ni rencontré le problème que vous décrivez. deadtimene fait rien si vos clients ont des fichiers ouverts, alors la question serait de savoir quels fichiers ils gardent ouverts. Mais c'est probablement un tout autre problème que celui discuté ici, vous devriez donc ouvrir une nouvelle question pour cela. Ma socket optionssuggestion n'aide que pour les connexions qui ne sont pas correctement fermées (parce que les clients se bloquent, une panne de réseau, etc.), mais probablement pas si vos clients WX se connectent simplement au serveur sans autre action ou en utilisant une sorte de session anonyme (ce qui nobody.nogroupsuggère ).
Jakob

Il semble y avoir une question sur ce problème, mais sans véritable solution. Il semble que ce pourrait être un problème de samba qui pourrait être corrigé dans une version plus récente.
Jakob

Il y a pas mal de mentions à ce sujet sur la liste de diffusion, aucune vraie solution présentée nulle part, et aucune version que j'ai essayée (chaque branche actuelle sauf 4.9) ne résout le problème. Ce n'est qu'avec les clients Windows10. La chose nobody: nogroup est perplexe, car les invités sont désactivés globalement, aucun partage ne les accepte et le PID des entrées nobody est toujours le même qu'une seule entrée valide avec un nom d'utilisateur valide. Vous voyez donc 12345 someuser somegroup...une entrée, puis 800 12345 nobody nogroup ...entrées, mais seulement une poignée de verrous de fichiers (pas 800). Très étrange. Affecte maintenant 3 de mes sites clients.
zxq9

Cela ne devient une contrainte de ressources sur les sites à haute activité, c'est pourquoi je pense qu'il reçoit si peu d'attention. La plupart du temps, il n'y a pas de problème, donc les gens ne le remarquent pas et cela s'éclaircit en quelque sorte chaque fois que les clients ferment réellement leur connexion.
zxq9

0

Vous pouvez désactiver les oplocks par partage avec les éléments suivants:

[acctdata]
oplocks = False
level2 oplocks = False

Le type d'oplock par défaut est Level1. Les oplocks de niveau 2 sont activés par partage dans le fichier smb.conf. Alternativement, vous pouvez désactiver les oplocks par fichier dans le partage:

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

Si vous rencontrez des problèmes avec les oplocks, comme le montrent les entrées du journal de Samba, vous pouvez vouloir jouer en toute sécurité et désactiver les oplocks et les oplocks de niveau 2.

Désactivation des Oplocks du noyau Les oplocks du noyau sont un paramètre smb.conf qui notifie Samba (si le noyau UNIX a la capacité d'envoyer à un client Windows une pause oplock) lorsqu'un processus UNIX tente d'ouvrir le fichier mis en cache. Ce paramètre concerne le partage de fichiers entre UNIX et Windows avec les oplocks activés sur le serveur Samba: le processus UNIX peut ouvrir le fichier qui est Oplocked (mis en cache) par le client Windows et le processus smbd n'enverra pas de pause oplock, ce qui expose le fichier à le risque de corruption des données. Si le noyau UNIX a la capacité d'envoyer une interruption oplock, le paramètre oplocks du noyau permet à Samba d'envoyer l'interruption oplock. Les oplocks du noyau sont activés par serveur dans le fichier smb.conf.

kernel oplocks = yes

La valeur par défaut est non.

La source

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.